| name | isucon-scoring-patterns |
| description | Common ISUCON scoring patterns and strategies to achieve score jumps based on historical competition data |
ISUCON Scoring Patterns — Historical Strategies
過去の ISUCON (ISUCON 9-13) で観察された、スコアジャンプにつながるパターン集。
スコア停滞と突破のパターン
| 状態 | 突破戦略 |
|---|
| 初期実装のまま | DB インデックス追加、明らかな N+1 修正 |
| 基本インデックス済み | ホットパスの N+1 解消、キャッシュ導入 |
| 単一サーバーで最適化済み | マルチサーバー分散、LB セットアップ |
| マルチサーバー + クエリ最適化 | アプリレベルキャッシュ、DNS 最適化 |
| 全最適化済み | ファインチューニング、エッジケース、並行性 |
高インパクトパターン
1. "Index Everything" パターン
全 ISUCON で意図的にインデックスが欠落している。全 FK カラムと WHERE で使われるカラムをチェック:
SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = '<dbname>' AND TABLE_NAME NOT IN (
SELECT DISTINCT TABLE_NAME FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = '<dbname>' AND INDEX_NAME != 'PRIMARY'
);
2. "Single Heavy Endpoint" パターン
通常、1 つのエンドポイントが全体の 50% 以上の時間を消費している。そのエンドポイントを修正するだけでスコアが倍になる。
- alp でプロファイルして SUM が最大のエンドポイントを見つける
3. "Serve Static from nginx" パターン
アプリが画像/ファイルをアプリケーション経由で配信している場合 → nginx の直接配信に移行。
4. "Split DB and App" パターン
単一サーバーで CPU がボトルネックの場合:
- DB 専用サーバーに全 RAM を buffer pool に割り当て
- App サーバーにリクエスト処理の全 CPU を割り当て
5. "Denormalize Statistics" パターン
重い集計を毎リクエスト計算する代わりに、事前計算・インクリメンタル更新:
UPDATE user_stats SET total_amount = total_amount + ? WHERE user_id = ?
メタ戦略
- 計測してから最適化 (alp + slow query)
- 最大のボトルネックを修正 (最も簡単なものではなく)
- 一度に一つの変更 (影響を分離)
- pretest で検証 してからフルベンチマーク
- スコア推移を追跡 (収穫逓減 → 次のティアへ)