private-isuを2日で合計8h~くらい遊んだので、やったこと・学んだこと・改善点をまとめようと思います。
ISUCONの予選と比べるとアプリケーションの規模が小さめで、スコアの計算方法もシンプルなため、初心者の自分にとってちょうどいい練習の題材だったと思います。
改善する箇所の見つけ方
改善する場所は、以下のように見つけました。
- alpでSUMが大きいエンドポイントを見つける
- エンドポイントの中身とクエリの解析結果を比較して、問題を見つける
問題を見つけたら、改善策を実施し、解析結果が改善されていることを確認します。解析結果が改善していれば、スコアも一緒に伸びることが多いです。
やったこと
- 初動の練習（gitの設定、ツールのインストール、アプリケーション構成の把握、計測・分析）
- クエリの改善（インデックス、LIMIT、N+1のJOINでの解消、N+1のプリロードでの解消、プリペアドステートメントの削除、…）
- Nginxでの静的ファイル配信（CSS・JSの配信、アップロードした画像の配信）
クエリの改善がメインでした。クエリの本数を減らすとその分のDBのキャパシティが開くので、効果的だということが分かりました。
学んだこと
- 遅いクエリでRows examinedが大きい場合は、インデックスやLIMITをつけて改善する
- N+1の改善は、1:1の場合はJOIN、1:Nの場合はプリロードで改善する
- プリロードよりキャッシュしたほうがよいときがあるかも（プリロードしたのをキャッシュするのもアリかも）
- nginxの設定がムズい
- locationがマッチする優先度を練習して確認したほうがよさそう
改善点
- 初動の時間はもう少し短縮できそう（45分くらいかかった。本番は1h以内にやりたい）
- phpMyAdmin等で、DBの中身を見られるようにしたい
- 練習中は、Ubuntuにインストールする方法が分からなくて断念しました
- アプリケーションのプロファイルをとりたい
- SQLだけだと、どこから発行されたクエリが遅いのか分かりにくいときがある（特に後半）
- 強いチームはFlame Graphを見てそうだった
- ベンチ以外に確認できる手段を用意したい
- 2つのエンドポイントにリクエストを送って、レスポンスを比較したり
- 改善のサイクルを早く回せたほうがいいため（ベンチはそれなりに時間がかかる）
まとめ
スコアが伸びるのが面白いです。いい練習方法を見つけたので、また記事にできればと思います。