isucon3予選参戦の記録
isucon3の予選に参加してきた。本戦には共催の1社、LINEの選抜枠として参加が決まっているんだけど、なにしろこれまでisuconというイベントに参加したことがない！ ということで、最終結果から除外されるのはわかってたんだけど練習として参加してみよう、ということに。
ざっくりまとめ
- みんなこれまでこんな楽しいイベントに参加してたのか！ ずるい！！！！！！
- 普段やってることを普段通りやる、という感じだったけど、イベントならではというか気付いて当然のことに数時間気付かないとか割とあって社会は厳しい
- 思いきった構成変更とかできるのがisuconでしょｗｗｗｗ とかドヤ顔していたがいざとなると非常に難しい、社会は厳しい
これからisuconという名前を口にするときにドヤ顔をしないように気をつけたいと思います。
あれこれ
チームは kazeburo, sugyan という社内でいっしょに働いてるメンツ。というか、去年のisucon2の出題者のメンツそのまんま。あんまり細かい打合せとかせずに、事前に作業用リポジトリとIRCチャンネルの準備、SSH公開鍵の共有くらいだけやって当日に臨んだ。
経緯はsugyanが書いてる。だいたいこんな感じでした。
環境を見ると、おお xbuild で入れたのでは……！ とか、Perlの実装はKossyだ……！ とか、なんか見覚えのある感じの構成。普通に他の言語とか見向きもせずPerlでガッと開始したけど、Rubyの実装は後で聞いたら Sinatra と組合せて mysql2-cs-bind が使われていたそうな。おれおれ、おれだよ。作者的な意味で。1行も見なかったけど。
序盤は明らかに問題というところから手をつけていってどんどんスコアが上がるものの、桁違いというスコアの上がりかたはしない感じ。ただやったことに対して割と素直にスコアが上がるので、それに踊らされていた感じなのかなーと思う。ああいうのに踊らされるとダメだなあ。
Cache::Memory::Simple は0.9秒expireのオンメモリキャッシュとかが超お手軽に作れて非常に便利。あとはKossy上でページキャッシュの仕組みを実装しつつログイン済みユーザに対応したりとか。
ただあれをやるよりはフロントでキャッシュしたほうが良かったのは結果を見ると明らかで、いまいち効果的でない対策に終始してしまった感がある。
まあ他にもいろいろやったけど、午後になるとスコアが上がらないどころか下がっていく事件が発生してなんだなんだということに。MySQLでスキーマ変更に応じて実行計画が狂っていたらしい。コードをrevertしたりとかで右往左往してしまい時間をだいぶロスした感があった。そういうときに落ち着いて即座に explain しなおすような能力が欲しい……。
あとデータの初期化時に更にスキーマ変更して表示時のクエリを減らす変更を作ってたんだけど、それを試す前に用事で離脱しないといけない時間が来てしまったのでbranchを残したまま離脱。16時過ぎ。残念無念、最後までやりたかった。
結局そのブランチは実装がマズくて初期化が60秒以内に終わらなくなってしまったらしい。もうちょっと他にやりようがあった気はするので残念感が高い。うーん。ちゃんとやったらどのくらいのスコアになったのかな。
その後
行った先が要するに同業者大集合みたいなところだったので「あれ、isuconで来ないかと思ってた、なんでいるの？」という言葉を何度も何度も何度も聞きました。
後知恵
あとから @sechiro さんに話を聞くと、ベンチマークツールが同一ホストにいるということで特殊な考え方が割といるのでは、みたいな話を聞いた。1リクエストを捌くのに複数のプロセスが動作する状況だとコンテキストスイッチが多発して本来の処理以外のところでCPUを食い合う。だから多少のfailを覚悟でフロントで全部捌くようにした、という話。うーむ、もっともなことだなあ。*1
failについてはレギュレーションを読んだ時点で「減点ではあるが即座に失格ではない」というのは把握していた。が、やっぱり当日にあれこれやっているとfailになるようなレスポンスを返さないという大前提をつい頭の片隅に置いてしまい、最適な戦略をうまく考えられなくなっていた気はする。もっと広い視野が必要。
予選って
えーやるのー？ やらなくていいんじゃない？ 大変だなー。
みたいなことを最初思ってましたが、なんと70チーム以上が参加(200人くらいか！)ということで、ある意味本戦よりも規模の大きいイベントだった感じでしたね。これだけでもすばらしいと思います。すごい！
主催の方々は本当にお疲れさまでした。
で
本番でがんばる！
*1:だから本番ではそのあたりの戦略が違うかも、という話はしていた。
