ふ連載3の真面目な対処法をやっても、あまり効果がありませなんでしたので、いくつか追加で思い当たる対応策を実施しました。TCPIPのオーバーヘッドってセッション数が200-300程度じゃ誤差にもならなかったです。$refreshIntervalを死ぬほど短くするこれまでの対応でやはりnginxとfastcgi間を散々弄ってみましたが、nginxのreq/secがほぼfastcgiのプロセス数上限で頭打ちになるということから、buffering云々ではなくDodontoFServer.rbのどっかでCPUやDiskIOに関係なく待っている箇所があると疑い、調べてみたらありました。endめっちゃsleepしてます、しかもデフォルトのCommet方式をそのまま使っているので、$refreshTimeout秒もしくは、$refreshInterval秒×saveDataが空になるまでのループ回数分もここでsleepで待っています。refreshという一番使用頻度の高いリクエストがsleepなんかしちゃってるせいで、fastcgiのサーバープロセスが他のリクエストを処理できない待ち時間が発生してしまっていたわけです。待っているだけのsleepですからCPUもDiskIOも食うわけありません。こんなに待たされちゃたまりませんので、refreshIntervalをとりあえず0.1秒にして$refreshTimeoutも0.1秒にしてみました。結果:リクエスト数が3倍になりました。平日に第壱、第弐だけで試したのが幸いでした。週末に全鯖に設定入れてたら3倍どころの騒ぎじゃなく、1日で2億リクエストぐらいになってしまいログがパンクしていたでしょう。nginxのreq/secは1400req/secまで一気に改善していました。設定値に問題はあったもののボトルネックはここで間違いなさそうです。疑似Commet方式を辞めて、sleepそのものをコメントアウトそもそも、この処理ってレンタルサーバーなどでrubyプロセスを1つのリクエストがなるべく再利用するためにという思想で作られた擬似Commet方式のためにあるのですが、公式鯖はやたら大量にリクエストが来るので、リクエストはrubyプロセスをさっさと開放して次のリクエストを処理させたほうが良いのでCommet方式をまず辞めちゃいましょう。この設定に関する箇所は、src_ruby/config.rbにあるこの部分で設定することになります。