Skip to content

Benchmark and Rules

Jump to bottom
k-kawasaki edited this page Oct 10, 2026 · 1 revision

ベンチと改善時の制約

← 練習ガイド · アプリの仕組み

速さを比較する前に、初期化・互換性・エラーを確認する。 以下は2022年当時の条件です。ポータルやAWSの構築手順が現在の練習環境でも使えることは保証していません。

ベンチは3段階

順番 処理 時間・失敗条件
1 POST /initialize 30秒でタイムアウト。失敗すれば即fail
2 アプリケーション互換性チェック 数秒〜数十秒。失敗すれば即fail
3 負荷走行 60秒。終了時に未完了リクエストを切断

/initialize は期待される初期状態を復元し、実装言語を {"lang":"go"} のように返します。lang が空なら初期化失敗です。データ構造を変えても初期化の整合性を保つ必要があります。

スコアは成功点からエラー率分を引く

項目 扱い
参加者の3つの閲覧API 成功1回につき1点
採点対象の管理者API 成功1回につき10点
通常エラー 1件につき負荷走行スコアの1%減点
Criticalエラー 1件につき負荷走行スコアの10%減点

減点率は 通常エラー数 × 1% + Criticalエラー数 × 10%。0点が確定すると走行を打ち切り、failになります。例：成功点3,000点、通常5件、Critical 2件なら25%減点で2,250点です。

Criticalになるのは、下記の処理でエラーになった場合。 正常な失格者への403応答そのものがエラーという意味ではありません。

  • テナントの追加
  • 大会の追加・スコア入稿・終了
  • 参加者の失格処理
  • 失格済み参加者による GET /api/player/* の検証
採点対象APIの一覧を開く
点数 メソッド パス エラー時
1 GET /api/player/player/:player_id 通常。ただし失格済み参加者の検証はCritical
1 GET /api/player/competition/:competition_id/ranking 同上
1 GET /api/player/competitions 同上
10 POST /api/admin/tenants/add Critical
10 GET /api/admin/tenants/billing 通常
10 GET /api/organizer/players 通常
10 POST /api/organizer/players/add 通常
10 POST /api/organizer/player/:player_id/disqualified Critical
10 POST /api/organizer/competitions/add Critical
10 POST /api/organizer/competition/:competition_id/finish Critical
10 POST /api/organizer/competition/:competition_id/score Critical
10 GET /api/organizer/billing 通常
10 GET /api/organizer/competitions 通常

予期しないステータスコードや正常でないレスポンスはエラーです。

反映の猶予は指定された組み合わせだけ

更新操作 反映先 許容される猶予
大会終了 POST /api/organizer/competition/:competition_id/finish GET /api/organizer/billing、GET /api/admin/tenants/billing 更新レスポンスを返してから3秒
参加者失格 POST /api/organizer/player/:player_id/disqualified GET /api/player/player/:player_id、GET /api/player/competition/:competition_id/ranking、GET /api/player/competitions 更新レスポンスを返してから3秒

全APIに一律3秒の遅延が認められるわけではありません。

429 Too Many Requests を返せるのは次の2つです。Retry-After が必要で、ベンチは指定秒数待って再試行します。その429応答には得点が付きません。

  • POST /api/admin/tenants/add
  • POST /api/organizer/competitions/add

初期化・実装変更で確認すること

対象 原文での扱い
DB初期化 POST /initialize または ~isucon/webapp/sql/init.sh。実行するとDBの内容が変更される
MySQLの初期dump /home/isucon/webapp/sql/admin/。原文では /initialize・init.sh からは使わない
SQLite3の初期DB /home/isucon/initial_data。原文では初期化に使う
実装言語 初期はGo。ほかにNode.js・Perl・PHP・Python・Ruby・Rust・Java
接続 ホスト名とHTTPSを維持。ベンチの接続先は isuports-1.t.isucon.dev 〜 isuports-3.t.isucon.dev
認証 ベンチはJWTを自前発行。ブラウザ用のblackauthは維持

この練習リポジトリとの差分： 原文はDocker Composeをsystemdから起動する構成ですが、現在のREADMEではGoバイナリを起動する構成として記録されています。言語切り替えや復旧は、現環境のサービス定義を確認してから行ってください。

練習の区切りに確認するチェックリスト

当時の追試条件を、練習用の確認項目に並べ替えています。

  • 再起動後にベンチが通る。
  • 再現スコアが最終計測の 85%を超える。原文では85%以下がfail。
  • ベンチで書き込まれたデータを再起動後も取得できる。
  • ブラウザの挙動を維持している。blackauthも動く。

当時の最終スコアは最高値ではなく競技中の最後の計測値です。後半2項目は、当時は上位チームへの追試項目でした。

2022年当時の環境・運営規則（必要なときだけ読む）

環境

  • チーム固有のCloudFormationテンプレートを東京リージョンで使用。主な資源は c5.large 3台、gp3 20GB 3個。
  • GitHub登録のSSH鍵で isucon ユーザーとして接続。SSM接続時は ssm-user から切り替える。
  • /usr/local/bin/isucon-env-checker で環境確認とポータルへの情報送信を行う。
  • テンプレートに沿わない資源変更や外部資源への処理委譲は禁止。監視・テスト・開発への外部資源利用は許可されるが、スコアを向上させる効果を持ってはいけない。
  • 終了時に環境チェックに失敗したり、ポータルのサーバー情報が複数スタックで混在していたりすると失格。

変更禁止・終了後の扱い

  • isucon-env-checker.service 本体と有効化リンク、/opt/isucon-env-checker 配下、/usr/local/bin/isucon-env-checker は変更禁止。
  • /etc/systemd/system/blackauth.service は変更禁止。運営の追試用ユーザー・公開鍵などを削除して追試を妨げない。
  • 終了後は3台を起動したまま維持し、運営の案内まで操作・停止・削除しない。
  • 競技中の問題内容の公開、チーム外との情報交換、結託、不正アクセスや妨害は禁止。

当日の流れ

時刻・窓口 内容
10:00 競技開始
17:00 他チームのリーダーボード更新停止。自チームは更新継続
18:00 競技終了
翌14:00 結果発表予定
ポータル ベンチの投入・結果確認、質問・サポート。PENDING／RUNNING中は追加投入不可
Discord 運営の告知と呼びかけを確認。競技中の質問はポータルへ

CloudFormationの画面操作や詳細な禁止事項は、下記の原文を参照してください。

出典：ISUCON12 予選当日マニュアル。現環境との差分のみリポジトリREADMEを参照。

ISUCON12 練習ガイド

Clone this wiki locally