一键导入
isucon-scoring-patterns
Common ISUCON scoring patterns and strategies to achieve score jumps based on historical competition data
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Common ISUCON scoring patterns and strategies to achieve score jumps based on historical competition data
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
MCP tool reference — exec, benchmark_start, benchmark_status, note_write, etc. Use when: executing commands on VMs, running benchmarks, or recording findings
ISUCON13 contest manual — server topology, service management, benchmark execution, and rules. Use when: checking environment setup, running benchmarks, or understanding contest constraints
ISUPipe application manual — features, terms, constraints, and API specs. Use when: understanding the app domain, checking API behavior or MUST/MAY requirements
General strategy for identifying and adding missing database indexes in ISUCON web applications
General techniques for optimizing user icon/avatar image serving in ISUCON web applications
General techniques for identifying and fixing N+1 query problems in ISUCON web applications
| name | isucon-scoring-patterns |
| description | Common ISUCON scoring patterns and strategies to achieve score jumps based on historical competition data |
過去の ISUCON (ISUCON 9-13) で観察された、スコアジャンプにつながるパターン集。
| 状態 | 突破戦略 |
|---|---|
| 初期実装のまま | DB インデックス追加、明らかな N+1 修正 |
| 基本インデックス済み | ホットパスの N+1 解消、キャッシュ導入 |
| 単一サーバーで最適化済み | マルチサーバー分散、LB セットアップ |
| マルチサーバー + クエリ最適化 | アプリレベルキャッシュ、DNS 最適化 |
| 全最適化済み | ファインチューニング、エッジケース、並行性 |
全 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'
);
通常、1 つのエンドポイントが全体の 50% 以上の時間を消費している。そのエンドポイントを修正するだけでスコアが倍になる。
アプリが画像/ファイルをアプリケーション経由で配信している場合 → nginx の直接配信に移行。
単一サーバーで CPU がボトルネックの場合:
重い集計を毎リクエスト計算する代わりに、事前計算・インクリメンタル更新:
-- 毎回: SELECT SUM(amount) FROM transactions WHERE user_id = ?
-- 代わりに: INSERT/UPDATE 時にカウンターを更新
UPDATE user_stats SET total_amount = total_amount + ? WHERE user_id = ?