読者です 読者をやめる 読者になる 読者になる

ISUCON4 予選参加しました

ISUCON4の予選二日目に参加してきました。

結果は惨敗です。最終スコアは12,500くらい。 ランキング上位陣と同じようにインメモリなデータの持ち方でスコアを稼ごうとしましたが、 バグが取りきれず、最終的にはDBにインデックスを張ったりSQL最適化をしたりで終わってしまいました。

以下反省点

問題の切り分けができなかった

Redisを使ったコードへの書き換えを行いましたが、一発でベンチマークが通るわけもなく、デバッグをすることに。しかし、そもそもオリジナルのコードの仕様把握で間違えているのか、書き換えたコードにバグあるのか、その辺の切り分けができていなく、無駄に時間が過ぎていく一方でした。

改善案としては、

  1. クエリ最適化などを手始めに行い堅実にスコアを伸ばしつつ、仕様を正しく把握していく
  2. 全てを一気に書き換えるのではなく、インクリメンタルに書き換えて検証を行う

例えばDBの書き込みはそのまま残しつつ、少しずつ参照部分をRedisの方に向けていく、なんてやり方がよかったのかもしれません。

推測ではなく計測

今回計測方法としてはdstatでCPUやI/O使用率を見るということくらいしかしていなく、あとはほとんど「ここが重そうだよね」程度の推測で動いてしまいました。上位陣は適切にリクエスト時間やDBアクセス時間を計測し、地道に最適化していたみたいです。やはり推測ではなく計測大事ですね。

地味な最適化を怠らない

2日目暫定トップのfujiwara組のブログエントリーを読みましたが、こんな所まで最適化していたのか(base.txの削除やCSS参照削減など)と驚かずにはいられませんでした。特に印象に残ったのは、

100msかかっていたモノを99msにしてもスコアは1%しかあがらないですが、 2msかかっていたモノを1msにすると同じ1msの短縮でもスコア自体は2倍になる

という言葉です。考えてみれば当たり前のことですが、確かにその通りだなぁと。 今回はそういうマイクロチューニング的なことをする以前の段階で終わってしまいましたが、 日々の業務や、来年のISUCON(あるかな?)出場時には意識したいポイントです。

最後に

結果としては何も残せませんでしたが、参加して得られたものは大きいです。 後日公開されるであろう本選のISUCON問題、今回の反省点を生かして取り組むのが今から楽しみです!