valid,invalid

関心を持てる事柄について

ISUCON14 ソロで参加して19131点 (50位) だった

ISUCON

ISUCON14 ソロで参加して50位 (19131点) でした。

はじめに、開催してくださった運営の皆さんありがとうございました。解きがいのある素晴らしい作問、当日までの案内・サポート、ベンチマーカーのスムーズな実行など全てを通じて一切の不満なく楽しめました。

結果

  • 最終スコア: 19131 (50位)
  • 最高スコア: 21394
  • 使用言語: Ruby (言語別ランキングでは4位)
    • ソロ参加だと何位ぐらいなんだろう

ISUCON11ぶり、3回目のソロ参加。まだまだ伸びしろはあるものの最もまともに戦えた回だった。

ohbarye.hatenablog.jp

使用したツール

  • Vim
    • サーバで直接編集するとき
  • RubyMine
    • コード編集するとき
  • DataGrip
    • データ見たりSQL書いたり
  • alp
    • 今回初めて使ってみた
  • mysqldumpslow
  • top
  • git / GitHub

テーブルやカラムにコメントがちゃんと付いていてありがたい。DataGripマジで良くて、Copilot等がスキーマから補完を効かせてくれたり、Copilot Chatでクエリ相談を投げたりしていた。

戦略

1人なので時間は絶対に足りない、という前提のもとフォーカスするポイントは決めておいた。

  • 1台構成でできるところまでやり、行き詰まったら複数台構成に挑戦
  • アプリケーションのすべての仕様を理解しようとしない

前回は素振りしてないツールや技術は使わない方針でやったが、失敗しても誰に迷惑かけるわけでもなし、好きにチャレンジしても良いだろうということにした。

振り返り

Good

  • top, mysqldumpslow, alpを見ながらやるべきことの優先度をつけられた
  • ベンチマーカー走行結果のユーザーの不満を見ながら改善のアイデアを検討できた
  • 午前中の早い時間にスコアが伸びなくても焦らずに進められた
  • 15:00ぐらいまでは順調に伸びて10位以内につけた

More

  • 1台構成でスコアが伸び悩んだ後、複数台構成への切り替えが最後までできなかった
    • isucon_matcher.serivceの停止忘れでベンチマーカーが落ちるようになっていた
    • 感想戦でアプリ1台、DB 1台に切り替えただけで34556まで伸びた。これは悔しい
  • テーブル構造をまったく変えずにやったが、非正規化で頑張っても良かった
  • よく使うコマンドをsnippets登録しながら実行したがMakefileにすればよかった

[おまけ] 競技時間内にやったこと

github.com

[10:00-11:00] 環境構築: 999

[11:00-11:50] 状況把握

アプリを触って仕様を把握したり、ボトルネックがDBぽいなとか、notifications APIへのリクエスト数やばいなとか

コードの構成をざっくり把握

[12:18] インデックス追加: 2193

テーブルの関係が把握できたので、mysqldumpslowから判断して明らかにインデックスが足りてないところに追加

一般に外部キーがあるべきところとか

[12:43] retryを1000msに: 5811

変更箇所が漏れていてretryが30msのままだった。ちゃんと1000msにした

2000とか1500とかいろいろ試したが1000がこの時点では妥当と判断。27位

[13:24] owner/chairのクエリを微改善: 7660

一番重いクエリの改善。キャッシュしてもよかったな

[13:29] マッチングのポーリングを500msから100msへ変更: 10679

マッチングに不満があるという走行結果に着目し、設定を変更

ここからしばらくマッチング改善

[14:00] マッチングアルゴリズムを改善したはずがdown: 4502

[14:49] いろいろマッチング改善: 15810

  • speedも考慮して最短でピックアップできるisuを優先してマッチング
  • マッチングAPIコール時に1件だけ処理するのではなく、待っているrides全てを処理するようにした

[14:55] いろいろマッチング改善: 15810

目的地までの到着が最も速いisuをマッチングするようにしたがあまり変わらず。ボトルネックがここじゃない感がでてきた

[15:13] /api/app/nearby-chairs を改善: 14582

API内のN+1やクエリ性能を改善したがあまり変化なし

このあたりでDBを別の台にしようとしたりアプリの複数台構成を試したが、ベンチマーカーが通らずダメだったので諦める

[16:28] マッチングのクエリがちょい重いのを改善するためindex追加: 16178

[16:43] nearbyのN+1を潰したがマイナス。revertする: 13763

2時間近くスコアが動かず手詰まり感が出てくる

[17:32] pumaの設定を5:5スレッドにした: 18248

曖昧に試して回る

  • 0:8だと16000
  • 3:3だと11688

[17:49] mysql log, nginx log, sinatra logをオフ: 19251

[17:52] notificationsのretryを1000ms -> 500ms: 19950 -> 19131

250msにしたら17000ぐらいにさがったので500msが最適と判断

このときのベンチ結果が採用されてたらRuby 3位だったので悔しい

Note