ISUCON4 予選参加しました
ISUCON4の予選二日目に参加してきました。
結果は惨敗です。最終スコアは12,500くらい。 ランキング上位陣と同じようにインメモリなデータの持ち方でスコアを稼ごうとしましたが、 バグが取りきれず、最終的にはDBにインデックスを張ったりSQL最適化をしたりで終わってしまいました。
以下反省点
問題の切り分けができなかった
Redisを使ったコードへの書き換えを行いましたが、一発でベンチマークが通るわけもなく、デバッグをすることに。しかし、そもそもオリジナルのコードの仕様把握で間違えているのか、書き換えたコードにバグあるのか、その辺の切り分けができていなく、無駄に時間が過ぎていく一方でした。
改善案としては、
- クエリ最適化などを手始めに行い堅実にスコアを伸ばしつつ、仕様を正しく把握していく
- 全てを一気に書き換えるのではなく、インクリメンタルに書き換えて検証を行う
例えばDBの書き込みはそのまま残しつつ、少しずつ参照部分をRedisの方に向けていく、なんてやり方がよかったのかもしれません。
推測ではなく計測
今回計測方法としてはdstatでCPUやI/O使用率を見るということくらいしかしていなく、あとはほとんど「ここが重そうだよね」程度の推測で動いてしまいました。上位陣は適切にリクエスト時間やDBアクセス時間を計測し、地道に最適化していたみたいです。やはり推測ではなく計測大事ですね。
地味な最適化を怠らない
2日目暫定トップのfujiwara組のブログエントリーを読みましたが、こんな所まで最適化していたのか(base.txの削除やCSS参照削減など)と驚かずにはいられませんでした。特に印象に残ったのは、
100msかかっていたモノを99msにしてもスコアは1%しかあがらないですが、 2msかかっていたモノを1msにすると同じ1msの短縮でもスコア自体は2倍になる
という言葉です。考えてみれば当たり前のことですが、確かにその通りだなぁと。 今回はそういうマイクロチューニング的なことをする以前の段階で終わってしまいましたが、 日々の業務や、来年のISUCON(あるかな?)出場時には意識したいポイントです。
最後に
結果としては何も残せませんでしたが、参加して得られたものは大きいです。 後日公開されるであろう本選のISUCON問題、今回の反省点を生かして取り組むのが今から楽しみです!