Isucon2参戦記 (序)
#isucon2 参戦記を私と @pandax381 とで交互に書くことになりました。 今日は私の視線で前半戦についてまとめます。
課題、襲来
isucon2 の課題が発表されました。今回の課題はチケット販売サイトらしいです。 スコア算出方法が (完売までの時間[ms] - 0.001*GET数 - 0.01*完売後の処理数) と発表されましたが、 課題とスコア算出方法だけでは今回のキーポイントがどこになるのかが判りません。
事前の打ち合わせ通り、 @pandax381 には負荷試験を実行してHTTP/TCPレベルでの観察をお願いし、 私はアプリケーションを実際に使ってみながらソースコードやDBのスキーマと見比べて、 アプリケーションの仕様を把握しました。
この時点で、 "/ticket/<ticketid>" というパスのHTMLが500KB程度あるのを見つけました。 1Gbpsのイーサネットは、TCPレベルではだいたい115MB/sec程度しか出ないので、 このページに 200req/sec くらいアクセスがくるだけで帯域がいっぱいになってしまいます。
HTMLの中身は殆ど同じようなタグが並んでいるもので、圧縮が効きそうです。 まだ recaro には Accept-Encoding ヘッダによって圧縮したコンテンツを返すかどうかを 切り替える機能がなかったので、その実装を @pandax381 にお願いし、私は全てのGETアクセスで 一切DBに接続せず、キャッシュからページを返せるようにアプリの書き換えを始めました。
一方、isucon2のメインとなる購入処理に関しては、最終的にMySQLは使わないでシングルプロセスの アプリ内で完結する、できればカーネル内に持っていく予定だったので、DBのチューニングは一切 行いませんでした。
11時頃のチャットのログでは、「チケット販売をカーネル空間でやりたい。」「チケット完売まで目指せ5ms!」 「目指せマイナススコア」と威勢の良い事を言っていました。（それ以降直接会話することが多くて チャットのログは残っていません）
見知らぬ、環境
用意していただいたサバ弁当をご馳走になったりして、のんびりアプリの改修を進め、 午後2時頃には admin ページと POST リクエスト以外では一切DBに接続しない、 シングルプロセス用のアプリが出来上がりました。 (その時点でのソース)
今回は Dom0 からの支援がないということで、環境を壊さないために二人共ローカルで 開発をしていたのですが、そろそろ本番環境で動かし始めないとマズイ時間です。
とりあえず daemontools を用意しようと思ったのですが、何か様子が変です。 daemontools でよく見る errno に関するコンパイルエラーとは違うエラーが起きています。
すると、 @pandax381 から衝撃の事実が告げられました。なんと CentOS が最新安定版の 6.3 ではなくて 5 系らしく、 recaro がビルドできないそうです。 uname -a してみたらカーネルが 2.6.18 です。 2.6.24 未満のカーネルとかここ数年見たことも触ったこともありません。 recaro を使う前提でいたのに、使えるかどうか判らなくなってきました。
勝つ確率を上げるためには、すぐに別の構成に切り替えるべきでしょう。 でも、普通の構成で勝ったって、 @pandax381 とペアで参戦した意味も、 recaro を準備した意味もありません。
最悪の事態に備えてアプリをマルチプロセスで動くように改修しつつ、 @pandax381 には引き続き recaro の準備をお願いしました。 (続く)
