参加して、優勝してきました。refineryていうRoR製CMSのブログ機能のチューニングがお題でした。やったことを時系列順で※スコアの移り変わりや、このエントリで触れていない点については相方@ijinさんのエントリが詳しいので、合わせてご参照ください。扱い易いので良いかと思います。インストール方法は巷にいっぱいあるので割愛。今回スタート時のRubyが1.8.6?とかだったけど、1.9.3にしても普通に動きました。JRubyも試そうかという話もあったのですが、Gemfileをいじってはいけないという制約があり、mysqlのコネクタ変更出来ないのでこちらは断念しております。インストールするところだけ少し注意という感じです。インストール後、多分ポイントになる設定は以下の二つ。unicornのworker数2コアサーバだったのでworker数も2に。4にしたらパフォーマンス下がったでもここの適正値っていうのはちゃんとまだ分かってない...GCをoffにするこんなコードを入れてGCをoffに。(宣伝です)MySQLにいくつかindex追加Railsのdevelopment.logを見ながら遅そうなクエリ解消の為にindex追加を行いましたが、大体が1ms前後のものばかりだったので、ここらへんは正直やらなくてもよかったなと。計測ツールを眺めてスコア算出方法を調査レギュレーションには説明が書いてあったものの、やっぱり中身を見てみないと分からないだろうということで、スコアの算出方法を調査しました(計測ごとに振れ幅がデカくてどこを直せばいいかの指針が欲しかった)レギュレーションも踏まえてポイントをまとめるとGETのレスポンスを測るhttpd_loadが走ってるそれとは別にPOSTとGETを交互で且つ反映チェックを行うアクセスがくるPOSTのあとのGETの反映チェックがしくじると著しくスコアダウンというのはコードベースでも分かってきました。2のGETとPOSTが交互ということは、後述するVarnishのキャッシュが有効に働かないのではないかとう懸念はあったのですが、1のアクセスはそれよりも高い頻度でバンバンくるんでいけるかもというのもここら辺で分かった感じ。効くんだな」と話してました。Varnishでキャッシュをかますこの時点である程度のチューニングは思いつくところが終わった感じです。2012計測ツールの内容からGETは早く返してスコアを稼ぎたいPOST後の反映チェックはなるべくしくじらないようにしたいとなりVarnishでRailsからのコンテンツをキャッシュしてGETのパフォーマンスをあげつつPOSTがあった場合はキャッシュを破棄して反映チェックを通して減点されないようにするのが良さげということになりました。tuningathon運営側の公式計測が来る前にデータベースのデータ初期化unicornの再起動を都度行い、Ruby+アプリサーバチューニングの状態で2回計測してもらってまず実績を作りました。さんのブログにあるようなbanの設定を入れて、そこからさらに運営側の計測が2回きたと思うのですが、なんとかその間にハイスコアを出せたようです。所感とかまとめとかやった内容で設定とかコードベースの記載が少ないのはちょいちょい追記していければと思います。(キャッシュ周りのチューニング)の2つがあったかと思います。チューニング時間が2時間とかだったら余裕で負けてた。環境周りの地道な取り組みも効果は出る(というかそこが勝負を分けたところ)とも思うのでその辺りのバランス含めても面白い企画だったと思います。懇親会ではお互いやったこととか、それ以外の仕事の話や悩み相談など沢山あって大変良かったです。あと見た目がチャラいと色んな人に言われて俺はいたく傷つきました。次はまたどういう形になるか未定とのことですが、また機会あればチャレンジしてみたいと思います。参加された皆様、お疲れさまでした。技術評論社さん、ゼロスタートさんの記事も楽しみー。