げげげ、ruby-lang.org もか。 ここまでオープンソース関連が狙われてるところを見ると、 意図的にやってるんだろうなあ。しかも日本のサーバばっかりとは。
レポジトリ……独立してるのは去年の 12 月のしかないや。 あとは全部 cvsup で上書きされちゃってる。
(18:33)
再起動直後、tDiary に 10 発くらい同時アクセスを食らって load average が 1720 まで上がっていた。さすがにこれはきつい。 本気で負荷削減策を考えるべきか。
(20:41)
disp_referer2.rb の負担が大きいのは以前からわかっているので、 もっと単純なリファラ解析プラグインを書いてみた。 あんまり変わらない。CPU パワーよりも I/O が問題なのか?
FastCGI にしてみた。 微妙に速くなったような気がするがそれほどでもない。 スタートアップよりも処理自体が重いってことだな。
(01:13)
あとは tDiary の設計を変えるくらいしか思いつきません。
などと言いつつ、さらにあがいてみた。 月ごとのとき (mode=month) にはリファラを表示しないようにして、 かなり速くなった。
残るは latest だ。 リファラを表示しなきゃ速いけど、 毎日リファラを見るために日単位のページを見るのも面倒だな。
……む、(自作の) リファラ整形プラグインを外すと異様に速い。 かなり処理をシンプルにしたはずなんだけど、これでもまだ重いのか。 重くなるとしたら検索エンジンからのリンクを排除してるところしか ありえないから、検索エンジンの数が多すぎるってことか。 ということは、自分のところに来る検索エンジンだけを 厳選して列挙すればずいぶん計算量を減らせるのではなかろうか。
減らすまでもなかった。 検索エンジンかどうか判断する正規表現を一つに統合し、 手動で共通パターンをくくりだすことで劇的に高速化できた。
ちなみにこんなの。
def search_engine?(url) %r[\Ahttp:// (?:(?>[^.]+)\. (?: google | yahoo | netscape | msn | metacrawler | webcrawler | altavista | odn | lycos | fresheye | goo\.ne\.jp | eniro\.se | excite | naver\.co\.jp | euroseek\.com | aol | allthweb\.com )[\./] | (?:[^/.]+\.)*search | (?>[^/]+)/search | bach\.\w+\.kobe-u\.ac\.jp/cgi-bin/metcha.cgi | brisbane\.t-online\.de/ | dir\.dion\.ne\.jp | find\.walla\.co\.il | i\.yappo\.jp | infoseek\.co\.jp | infobee\.ne\.jp | odin\.ingrid\.org | srchnavi\.nifty\.com | www\. (?: infoseek\.co\.jp | ceek\.jp | eniro\.se | redbox\.cz | kensaku\. | hotbot\. | planet\.nl ) )]xi =~ url
(03:12)
Copyright (c) 2002-2007 青木峰郎 / Minero Aoki. All rights reserved.
どっちの対策なのかなぁ? 同時要求絞る方向か、マシンのパワーアップか。(多分、1/10なのは間違いないのでid)
接続数はすこし絞りました。ただ、元が緩すぎたので、
今回の変更でハードウェア相応の設定になっただけとも言えます。
いまハードウェアを買う金はないので、あとは tDiary の設計を
変えるくらいしか思いつきません。