Skip to content

Latest commit

 

History

History
129 lines (78 loc) · 8.25 KB

regulation.md

File metadata and controls

129 lines (78 loc) · 8.25 KB
Raw

ISUCON5 決勝レギュレーション

更新日時: 2015-10-31 10:30:00

(変更があった場合は変更内容をここに記す)

スケジュール

  • 11:00 競技開始
  • 18:00 作業終了
  • 18:00〜19:00 計測作業、発表・表彰、懇親会等

ISUCON5 決勝ポータルサイト

決勝進行は以下のポータルサイトからベンチマーク走行のリクエスト・結果チェックを行い進行します。 配布資料にあるアカウント名(teamXX)とパスワードを用いてログインしてください。(なお参加者以外の人は guest:guest で参照専用ログインできます。)

http://isucon5f.tagomor.is/

このページは18時を過ぎると即座に閲覧不可能になります。また自チーム以外の得点は 17:45 を過ぎると更新されなくなります。

チーム情報編集ページではデフォルトのベンチマーク実行先IPアドレスをひとつ登録できます。これが未登録の場合、ベンチマーク実行リクエスト時には自チームのIPアドレスを入力して送信しなければなりません。登録済みであれば省略できます。なお、ベンチマーク実行先IPアドレスはひとつしか指定できません。

このページではベンチマーク走行の処理状況も確認できます。赤もしくはオレンジが走行中のベンチマークを示し、青もしくは水色が待機中のものを示します。 ベンチマークが待機中もしくは実行中の間はリクエストは追加できません。

Getting Started

サーバは各参加者に3ノードずつ割り当てられています。開始時点で3ノードは全て同じようにセットアップされています。

1. ログイン

配布された紙に書いてある情報を使ってSSHログインします。会場のWiFi環境以外からの接続はできないよう設定されているので注意してください。

  • ユーザ名: isucon
  • パスワード: 配布された紙に記載のパスワード

isuconユーザからパスワード無しでsudo可能です。

2. アプリケーション動作確認

アプリケーションは各サーバの port 80 を経由してアクセスできます。 データベースの users テーブルにあるユーザ情報でログインできます。パスワードはメールアドレスのローカルパートと同じです。例えば、以下のペアが使えます。

  • email: あとでかく
  • password: あとでかく

3. ベンチマーク走行

決勝ポータルからベンチマーク実行を要求するとキューイングが行われ、基本的には先にキューイングされたものから実行されます。実行内容の概要は以下の通りです。

  1. 初期化処理の実行 /initialize (30秒以内)
  2. アプリケーション互換性チェックの走行 (適宜: 数秒〜数十秒、固定リクエスト数)
  3. 負荷走行 (60秒)

これらが順次実行されます。どこかのステップで失敗した場合はそこで即座に終了します。

なおキューからのベンチマーク実行は完全にキューイング順ではありません。開催側の都合で参加者をいくつかのグループに分け、その中で先にキューイングされたものから実行します。このため全体では実行順序が前後する場合があります。

また何らかの問題によりベンチマークが失敗するなどした場合、走りきらなかったベンチマーク要求は3分後に自動的にキューイングし直され、最優先で再実行されます。

参考実装の切り替え

各言語の参考実装は supervisord で管理されています。おおまかに以下の手順で切り替えます。

  1. 動作中の実装の停止(デフォルトはruby) supervisorctl stop ruby
  2. デフォルト起動・停止の設定変更 /etc/supervisor/conf.d/ruby.conf
  3. 設定の再読み込み supervisorctl reread
  4. 別言語実装の起動 supervisorctl start ruby

PHPの場合

PHPの場合は nginx の設定変更も必要です。nginx.php.conf が置いてあるので設定をそちらに差し替え、nginxを再起動してください。

ルール詳細

基本スコアは以下のルールで算出されます。またPOSTリクエストについてはレスポンスが返った瞬間からそのリクエストの要求する更新内容が反映されている必要があります。

成功レスポンス数(status 2xx) + 成功リダイレクト数(status 3xx) x 0.1 - ( サーバエラー(error)レスポンス数 x 10 + リクエスト失敗(exception)数 x 20 )

より高いスコアを記録したチームが高成績と判定されます。ただし最終的な順位には採点作業(後述)において記録した一度のスコアのみを用います。

レギュレーション

以下の事項を守ってください。違反した場合は失格とします。

  • 参加者の作業対象サーバは主催者に与えられた3台のみとし、ベンチマーク負荷の処理の目的ではその他のいかなる計算機資源の使用も禁止する
  • データ変換等の目的についても、主催者から与えられた計算機以外のものを使用してはならない
  • 外部のメトリクス計測サービスの使用のみ特例として許可するが、スコアを向上させるいかなる効果も持つものであってはならない

以上の条項に抵触しない範囲の作業は全てを認めます。ベンチマークが失敗を検出しない限りはスコアが認定されます。 しかし参加者の環境の破壊については主催者はいかなる救済も行いませんので、参加者の責任においてサーバ環境およびソフトウェアの変更を行ってください。

制約事項

以下の事項に抵触すると失格(fail)となり、点数は無効となります。

  • 初期化処理において GET /initialize へのレスポンスが30秒以内に返らない
  • スコアが0点
  • リクエスト失敗(通信エラー等)が全リクエストの 1% 以上存在する
  • サーバエラー(Status 5xx)が全リクエストの 1% 以上存在する
  • クライアントエラー(Status 4xx)が全リクエストの 5% 以上存在する
  • データ更新を行うPOSTリクエストの内容が即座に反映されていない
  • チェック対象のHTML内要素が存在しない、あるいは内容が誤っている
  • 存在するべきファイルへのアクセスが失敗する、あるいは内容が間違っている
  • その他、アプリケーションが返すコンテンツについて、期待されるヘッダ、Content Bodyの内容などが異なっている

最初に呼ばれる初期化処理 /initialize は用意された環境内で、チェッカツールが要求する範囲の整合性を担保します。サーバサイドで処理の変更・データ構造の変更などを行う場合、この処理が行っている内容を漏れなく提供してください。またこの処理が30秒以上レスポンスを返さない場合、失格とします。

再起動条項

アプリケーションはサーバ再起動後、自動的に正常動作するようになっている必要があります。これは採点作業(後述)時のチェック対象となります。

採点作業

18時に作業を打ち切ったのち、主催者は参加者用サーバを順次再起動し、そののち作業時間内と同様のベンチマークを一度走行してスコアを計測します。 このスコアが最終的な順位の決定に用いられ、最も高いスコアを記録したチームを優勝とし、以下順位を決定します。Failと判定されたチームは順位から除外されます。

特別賞

作業時間中に計測したスコアを用いて、以下の条件を最も早く満たした1チームに特別賞を与えます。

  • Failせず あとでかく 点を最も早く記録すること

禁止事項

他チームへの妨害など、競技の円滑かつ健全な運営を妨げる全ての行為を禁止します。 特に椅子を投擲した場合、即刻失格とします。