2007-11-21 やっぱりそうなるのか。
何がって、DB化の話。
◆ [日記][tDiary] 2.1.4ではDB化しない方が早いっぽい
DB化しない→4081回/5分 レスポンスタイム2秒くらい １ページ当たりのリファーの数を増やすと3325回くらいまで減少
DB化する→3894回/5分 １ページ当たりのリファーの数を増やすと88回くらいまで減少（;´Д`）
と、相当劣化しました。なんか明らかにおかしいので原因調べてきます（目星はついている）
→簡単なロジック変更で、2097回/5分まで回復。
→さらにロックを小さい単位で取る様に変更。3591回／５分まで回復
まぁ、DB化した際に余計な処理を入れまくっているので、それも大きいですが……。
逆に言うとtDiary 2.1.4はDB化しなくても十分に使える感じですね。
あとは、ruby 1.9待ちかなー。
ちなみにfast_cgi化したら、激しくバグりました（涙
どこが悪いんだー・゜・(ノД`)・゜・
→とりあえず、dateが空の場合と、date=年月日-数字の場合にfast_cgi側からうまく動かないので、この２つだけを例外的に直接index.rbを呼ぶように変更。それ以外はindex.fcgiなー。
で、DB化バージョンを実行してみた。……なんかsysが90%前後使うんですが（;´Д`） そして遅くなって1905回／５分、レスポンスタイムは１５秒程度。だめじゃん！
何の設定が悪いんだろうと考えて、httpd.confをこんな感じにいじる
FastCgiConfig -maxProcesses 200
FastCgiConfig -maxClassProcesses 200
これでどうじゃーい（笑）
メモリ不足でスワップへ行った（爆）
メモリ不足にならない程度に制限
FastCgiConfig -maxProcesses 80
FastCgiConfig -maxClassProcesses 80
７０個ほどプロセスが立ち上がってほとんどがlockfになる。
またおまえ(lockf)か！（爆）
というわけで、この設定だとsysが70%～80%になる。やっぱり暇なプロセスを探し回っているのがsysにカウントされていたか（笑）
つか、616 processes: 15 running, 601 sleepingとか頭悪いな。
結果、4122回／５分、レスポンスタイムは約７秒。やっと４０００超え。
とりあえずこんな感じで良しとしよう。
どうやらこの辺りがtDiary2.1.4+Ruby1.8の限界っぽいな。やっぱりruby 1.9待ち（笑）
……lockfも何とかしなきゃなぁ。
◆ [情報][メモ] Firefox 3のβ1リリース - ITmedia News
というわけで、いつのまにやら３に。早いなー
でもワシはSeamonkey
3β1を使ってみた人の感想。「まだバグだらけ」まぁβだしなー。
◆ [ネタ] 初音ミクがフィギュア「ねんどろいど」になって3月発売
あ、結構可愛い
長いツインテールは可動になるとのこと。ネギがどうなるかは分からない。
可動ツインテール(゜∀゜)
ネギは必須でしょう……でも難しいかな？
◆ [日記][tDiary] 2.1.4さらに自分の構成に特化して高速化を図ってみた
fast_cgi無し：3695回／５分、レスポンスタイムは約１０秒 load ave100超えとかありえねー（笑）
fast_cgi有り：4166回／５分、レスポンスタイムは約８秒
うふふふふー（笑）
ほとんど共有ロックしか取ってないのになんでlockfが多発するかと思ったら、counterか……。
counterはソースが長いからあんまりいじりたくないんだよなぁ（笑）