ISUCON公式Blog

WINNER'S PRIZE \1,000,000



   

参加者の皆さん、 ISUCON4 予選、お疲れ様でした。
ISUCON4 運営チームの @rosylilly です。
すでに予選問題の解説記事もあがっていますが、この記事では、ベンチマーカー実装者が予選参加者となるべく同じ状況で、出来る限り高得点を出すことを重点に置いたピーキーな解答例について解説します。
※ 別解となる、この記事ほどピーキーではない @sorah による解答記事はこちらです。

また、実装されたソースコードは GitHub にて公開しています。

前提

  1. 実装時間は皆さんとおなじ8時間程度を想定しています
  2. この実装はすべて僕一人で行います
    • 架空の想定として、運営チーム(@mirakui, @sorah, @rosylilly)で予選に参加している状況としています
    • @mirakui と @sorah がまったく別の実装を行っている設定です(去年の予選と同じ状況)
  3. 僕は出題者であり、ベンチマーカー実装者
    • 問題を把握する時間などはほぼスキップできる
    • すでにどういう解法にするかある程度検討がついている

手始めに(2分)

僕の手元で EC2 インスタンスを立ち上げて真っ先にやることは

  1. sudo service nginx stop
  2. sudo service mysqld stop
  3. sudo chkconfig nginx off
  4. sudo chkconfig mysqld off

で Nginx と MySQL を停止させます。

Nginx 及び MySQL を停止させるのは、この2つに一切依存しない実装をする、と最初から決めているためです。この2つはおそらく並行作業中の @mirakui と @sorah が触っているはずなので、僕の時間内にうまくいくかどうかわからないギャンブル実装に合わせていれた変更による手戻りや、設定のコンフリクトなど、想定されうる諸問題を最初から発生させないように、僕の実装からは完全に除外するためにサービスの停止を行います。

実装方針

まずは、実装方針を固めます。実装方針はおおまかに3点。以下のように定めました。

  1. 他のミドルウェアに依存しない
    • Redis であれ、 Memcached であれ、2人が使っていそうなので依存しません
    • これはベンチマーク対象をスイッチした時に事故を起こさないための措置です
      • 最終的な AMI 作成時に事故を起こすと失格になってしまいかねません
  2. Go 言語で実装するが、参考実装のフォークは行わず、フルスクラッチで書く
    • Martini が入っていて便利そうなのはいいのですが、最終的にどこがボトルネックになるのかわからない以上、型による制約が多く、人の手の入った状況から書き換え難い Go ではベース実装が足かせになると踏んでの判断です
  3. 後半になって完成してなかろうととにかく脇目も振らずに実装し続ける
    • 実装がパスしないことで不安になってやっぱり MySQL のチューニングで……と言いたくなっても、そこは2人のチームメンバーが必ず順当に良いスコアを出しているはずだと確信した上で気にしない
    • まずもって予選時間内に実装が間に合うかすらわからないので、とにかく作り上げることだけを考える

以上の方針ですすめていきます。

ベース実装

  • User と IP のモデルを作って、インメモリ DB として Go のアプリケーション上に展開(20分)
    • 起動時に sql/dummy_users.tsvsql/dummy_users_used.tsv を読んで初期状態を再現しておく
      • ベンチマーカーの実装を知っているため、即座に行える判断です。本来ならここだけで1〜2時間つかっておかしくないと思われます。
  • 外部のパッケージは一切使わず、net/http を使った生実装を行う(2時間)
    • HandleFunc などの組み込みルーターは使わない
      • エンドポイントのリストを並べるとわかるのですが、全部一致させる必要はなく、リクエストパスの先頭1文字を比較すればどのエンドポイントへのリクエストか識別可能です
        • i もしくは s なら静的ファイルへのリクエストなので、メモリ上に読み込んでおいた静的ファイルを返す
        • l なら login の処理
        • m なら mypage の処理
        • r なら report の処理
        • 1文字以下のパスなら top の処理
        • どれにもマッチしなければ 404
  • トップページの表示パターンは5種類しかないので、事前にテンプレートを実行して文字列化しておく(20分)
    • ついでに HTML テンプレート内の無駄な改行、空白を削っておく(5分)
  • ロック周りに注意しつつログイン処理を実装(1時間)
    • /reportでこけるとスコアが送信されず、すべてが水泡に帰すので、それだけは避けなくてはいけない
  • 再起動に耐えうる実装を追加(30分)
    • SIGINT, SIGTERM, SIGKILL を受け取ったら、現在の User, IP を json で吐き出してから終了する処理を追加
    • ベンチマーカーからの初期化処理も必要なので、 SIGHUP を受け取ったらメモリ上のデータを破棄して、上記 tsv から再度データを作る処理を追加
  • init.sh で MySQL へクエリを流している部分を消去してアプリケーションへ SIGHUP を送るように変更(5分)
    • kill は即座に返ってきてしまって、初期化が終わった保証がないので、ついでに sleep 20 も入れておく
  • Cookie 周りの処理を実装(30分)
    • 参考実装だと長い Cookie 名なので、_u に統一
    • ユーザーセッションがユーザー名を記録するようになっていて無駄なのでユーザー ID を Cookie に記録するように変更
  • GOMAXPROCS はコード中で指定しない(0分)
    • 何が最適値かわからないので環境変数で指定できるように、あえてコード内での指定を行わない

ここまで実装すると、大体動くようになっているので、ベンチマーカーを走らせながらブラウザチェックも同時に行います。

並列度を上げると ulimit やローカルポート枯渇などが発生するので、その辺を何とかして欲しいと @mirakui に頼んでおく。これはきっとまっとうな実装の方でも必要な処理なので問題ない……はずです。

肌感覚で、ここまで実装するのに5時間ほど費やしました。予選はあと3時間しか残っていないので、この辺でなるべく高いスコアを出すための計測を行います。

ということで計測したのが以下のスコアです。

$ ./benchmarker b --workload 16
12:52:22 type:info  message:launch benchmarker
12:52:22 type:warning   message:Result not sent to server because API key is not set
12:52:22 type:info  message:init environment
12:52:32 type:info  message:run benchmark workload: 16
12:53:32 type:info  message:finish benchmark workload: 16
12:53:37 type:info  message:check banned ips and locked users report
12:53:37 type:report    count:banned ips    value:1035
12:53:37 type:report    count:locked users  value:5088
12:53:38 type:info  message:Result not sent to server because API key is not set
12:53:38 type:score success:259220  fail:0  score:55999

5万点……予選通過はこの時点で問題なさそうです。

(スコアの計測は後述するピーキーモード実装後にピーキーモードをオフにして行いました)

次にどこを触るか

上記のスコアでも問題なさそうですが、できうる限り高い得点を出すために、まだまだチューニングを続行します。

今回は pprof などを利用した計測は一旦行わず、単純にエンドポイント毎のレスポンスタイムを見て、重そうな所に当たりをつけて対策を検討しました。そうすると、以下の3つが浮かび上がってきます。

(pprof を使わない理由としては、単に僕が慣れておらず、ここで新しいツールを採用すると時間をロスすると判断したためです。)

  1. /mypage : 平均で 200µs ほどかかっていて重たい。他の //login が大したことない(/ は 20µs で /login は 50µs)ことを考えると html/template のレンダリングが重そう?あとで pprof かけてもいいかも
  2. /images, /stylesheets : 平均すると大したことない気がする(60µs から 80µs 程度)けど、如何せんリクエスト数が多いし、送ってるバイト数も HTML に比べ大きいので、ベンチマーカーとの通信で時間を食っている可能性が高い
  3. /report : 30ms ほどかかっていて他エンドポイント達の 100 倍以上遅いけど、レギュレーションの1分以内を鑑みるに問題はまったくないので放置でよい

残り3時間でこのうちどれか一個を触るとして、一番怖くないのが 2 のエンドポイントをなんとかすることです。/mypage をいじるのも効きそうですが、テンプレートを壊すことなく、安全に終えられるかどうかが不明ですし、なによりテンプレートがボトルネックかはっきりしない以上、確実な対策とは呼べませんので、チャレンジしないことにしました。

ピーキーモードを作る(2時間)

前提として2つの方策があります。

  1. レスポンスの送信がボトルネックなのであれば、 CSS を全部連結して minify をかけ、不要な CSS セレクタを削除することで対応する
  2. まずもってベンチマーカーに CSS や画像へのリクエストを行わせない

CSS と画像を読み込まなくする処理はテンプレートの変更だけですみますが、もし失敗して切り戻すとなった時に、すぐに切り替えられるようにしなくてはいけません。

なので今回はシステム上で誰も使ってなさそうな AYATAKA という環境変数に 1 が入っていたら、 CSS と画像についてのチューンの入ったテンプレートで稼働させることにします。

まず、既存のテンプレートを別フォルダにコピー、有効時はそちらのフォルダを見るようにします。CSS や画像類も同じく別フォルダに丸ごとコピーして、変更を入れても影響のないように備えます。

最初に行ったのは方策1の minify でしたが、いすこん銀行が採用している bootstrap や bootflat などの CSS フレームワークでは vendor prefix が多く使われており、また、 HTML の静的解析もエラーメッセージの表示の有無などである要素ない要素があったりと、うまく行うことができず、断念しました。これだけで1時間半のロスです。

なので方針を切り替えて、方策2のまずもって読み込みを行わない、という手段を取ります。

予選問題のベンチマーカーは、 HTML 中に出現した link, script, img の要素で src もしくは href 属性を持つもののリンクをすべて取得しようとします。これは、事前にチェック対象として定義されているファイルかどうかの判断なく、書かれていればすべてリクエストしてきます。

ですが、 JS エンジンは稼働していないので、最初の読み込み後の DOM で上記要素が定義されていなければ、静的リソースへのアクセスは発生しません。これは、予選問題解説でも少し触れられている通り、ベンチマーカーのペルソナがパスワードリスト攻撃を行っている bot として実装されているためです(ある程度ブラウザに似せたアクセスを行うが、ブラウザそのものではない)。

作業としては、まず HTML テンプレートで <link> が並んでいる箇所を丸ごと <script>document.write(" ... ");</script> でくくって、遅延読み込みに切り替えます。

<img> タグの src 属性も削除して、画像の読み込みが走らないように調整。見た目が崩れてしまうので、いすこん銀行の CSS に a 要素の背景画像としてロゴを表示し、前面の img 要素には display: none で消えてもらう、という内容を追記します。

ブラウザでの表示が問題なく行えることを確認しましょう。

ここまでの実装で30分。残り制限時間は1時間ですから、あとは GOMAXPROCSworkload の調整を行います。

$ ./benchmarker b --workload 16
12:04:45 type:info  message:launch benchmarker
12:04:45 type:warning   message:Result not sent to server because API key is not set
12:04:45 type:info  message:init environment
12:04:55 type:info  message:run benchmark workload: 16
12:05:55 type:info  message:finish benchmark workload: 16
12:06:00 type:info  message:check banned ips and locked users report
12:06:00 type:report    count:banned ips    value:4942
12:06:00 type:report    count:locked users  value:14859
12:06:09 type:info  message:Result not sent to server because API key is not set
12:06:09 type:score success:237710  fail:0  score:237710

23万点 。ここまでやれば安心ですが、何度か計測を繰り返して、タイミングで Fail するようなことがないかの確認、また、再起動に耐えうるかの検証もできれば行っておきたいところです。

まとめ

この解答は僕一人で実装しており、また Go の実装以外触る箇所もほとんどありませんから、複数人で一気に触る、というのは難しいです。チーム参加前提の ISUCON において、それはいいのかと思われる方もいらっしゃるかもしれませんが、理由があってあえてこのような実装を行っています。

前年の ISUCON3 の時に参加した僕ら白金動物園チームのメンバー構成は、ざっくりと書くと以下のようになっています(これは、今回の問題作成時も変わりありません)。

  • @mirakui : インフラ・ミドルウェア担当
  • @sorah : アプリケーション・ミドルウェア担当
  • @rosylilly : 問題特化バイナリ制作担当

この解答例のようなピーキー実装に乗り出せるのは、自分が間に合わなかったとしても、必ず @mirakui と @sorah の2人が、まっとうにチューニングを行って予選を通過してくれる。自分は最後に安全圏に飛び込むためだけに実装していればいい、という安心感あってこそです。

Go 単体で他に依存しないのも、2人が行っている作業とコンフリクトしたり、僕の実装の方で @mirakui が別ミドルウェアのチューニングを行ったりしなくていいように、という判断からきています。

実際にベンチマーカーの仕様を知っていてなお、23万点が出せた時点では残り1時間でしたし、それ以前の5万点でも残り3時間なので、これに加えて問題を一切把握しておらず、レギュレーションの読み込みや、既存コードのリーディングをする時間を含めると、今回の実装は間に合っていない可能性が高いと思われます。

限られた8時間の中でうまく作業分担を決めるのは難しく、またコンフリクトの無いようにと進めていくのは高いコミュニケーションコストがかかります。

だからこそ、あくまで最後に結果がついてくるはずだと信じて、自分の不得意な分野は完全に他メンバーに任せ、自分の得意な事を徹底して行い、チームに貢献する。もし失敗しても、その時はきっとメンバーがうまくやってくれる。メンバーが失敗したら、自分がなんとか間に合わせれば良い。という思想のもと、完全に分割した領域での作業を行っています。

ISUCON において、スコアの高い解答を出すためには、各自のスキルや能力だけでなく、いいチームとして8時間を動き続けることが必須だと、僕は考えており、また、それを実現することこそが、 ISUCON おける最難関の問題と言っても過言ではありません。

このようなピーキーな解答を作成できる裏に、こんなチーム構成がありますよ、ということで、参考にしていただければ幸いです(本戦でのメンバー変更は認められておりません。来年の参考にしてください)。

では、本選出場者のみなさん、本戦でお会いしましょう。

Read more...

ISUCON4 予選お疲れさまでした! 予選問題の Ruby 初期実装などを担当した @sora_h です。

予選はたのしんでいただけましたでしょうか? 本記事では、ざっくりとそこそこのスコアを出す解き方を紹介しようと思います。
※@rosylillyによる、高得点を出すことを重点に置いたピーキーな解答例はこちらです

前提

  • 一人でやる
  • 一応8時間経過時点でスコアをとる
    • ただし出題者であるので問題の把握などの時間は短縮されていることに注意。
  • Ruby の実装を利用する
  • ある程度、現実味のあるチューニングが主
    • ベンチマーカーの実装を利用したりしない

また、この記事で出来た実装は GitHub に掲載しています: https://github.com/sorah/isucon4-qualifier-sorah

初期スコア

とりあえず立ち上げて動かした時のスコアは success:6030 fail:0 score:1303 でした (workload=1)

チューニング

ここからチューニングしていきます。

失敗数のカウンタを Redis にのせかえる (2 時間経過)

問題を読むとログを残す必要は一切ない事がわかるので、とりあえず mysql でログを取るのをとめて、Redis をカウンターとして利用するように変更します。

ただし、MySQL でも適切な index を張ればスコアが出せます。この辺は好みだと思われます。

  • isu4:user:<id>, isu4:ip:<ip> をカウンタとして連続失敗数を記録 (INCR)
  • isu4:last:<id>, isu4:nextlast:<id> を最終ログイン記録に利用

スコアはこの時点で "success:29430 fail:0 score:6357" (workload=1)

これはあまりスコアに影響はなかったのですが、少し後で users テーブルも redis にのせることにより、
完全に mysql をとりのぞいています。

nginx で静的ファイルを配り、app process との接続を UNIX ドメインソケットに

見出しのまま。この時点でのスコアは workload=1 で "success:52550 fail:0 score:11351".
workload=16 にしたら 23994 点を記録しました。

erb が遅いのでレンダラーを erubis に入れ替える

erb を高速にレンダリングできる erubis を導入しました。

Sinatra を捨てる (4 時間経過)

ここで Sinatra の実装を見てみたら、意外に重そうだった事を思い出したので、捨てて、Rack アプリケーションとして実装しなおしました。

workload=16 で success:158590 fail:0 score:34265 を記録。

アプリケーションの細かいチューニング (6 時間経過)

引き続きボトルネックはアプリケーション側にあるので、気になったところをどうにかしていきます。
プロファイリングには stackprof.gem を利用しました。

この前後でスコアは 37228 点。

トップページのほぼ静的ページ化 (7 時間経過)

5 種類しかないので起動時にレンダリングしておいてクッキーの値を見て切り替えるようにしました。
実際予選上位ではこれ以外にも、URL のクエリストリングを利用しているチームもあったようです。

この時点でスコアは 39144 点でした。

ルーティングの改善 (およそ 8 時間経過)

自前で書いたルーティング処理が遅いので高速化しました。

この時点で、予選当日の競技での 8 時間が経過しました。8 時間経過時点でのスコアは workload=16, score=40324 点でした。

そして、ここからさらに粘ります。

アプリケーションの細かいチューニング (2)

この辺からはわりと試行錯誤しています。本当に効果あるかどうか微妙な変更もある気がする。

その他

パフォーマンスには影響ありませんが、Can't assign local address と Too many open files 対策で以下を追加しています。

# /etc/sysctl.conf
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1

# /etc/security/limits.conf
* hard nofile 65535
* soft nofile 65535

(net.ipv4.tcp_fastopen = 2055 も追加していたんですが、スコアに大した影響はありませんでした)

最終スコア (8時間+)

12:19:44 type:info      message:launch benchmarker
12:19:44 type:warning   message:Result not sent to server because API key is not set
12:19:44 type:info      message:init environment
12:19:58 type:info      message:run benchmark workload: 10
12:20:58 type:fail      reason:Request cancelled because benchmark finished (1min)      method:GET      uri:/stylesheets/isucon-bank.css
12:20:58 type:fail      reason:Request cancelled because benchmark finished (1min)      method:GET      uri:/images/isucon-bank.png
12:20:58 type:fail      reason:Request cancelled because benchmark finished (1min)      method:GET      uri:/stylesheets/bootflat.min.css
12:20:58 type:info      message:finish benchmark workload: 10
12:21:03 type:info      message:check banned ips and locked users report
12:21:06 type:report    count:banned ips        value:654
12:21:06 type:report    count:locked users      value:4650
12:21:06 type:info      message:Result not sent to server because API key is not set
12:21:06 type:score     success:209927  fail:3  score:45350

workload=10 でこのようなスコアになりました。Ruby レベルではほぼ限界にチューニングしてあると思います。
(これでも上位チームはおろか Ruby を利用したチームのトップにすら勝てていなくて、皆さんすごいなあと思っています)

MySQL の場合

Redis を採用したのは筆者の趣味なので、同じ実装で MySQL に戻し少し手を加えたところ、 workload=10 で success:191040 fail:0 score:41270 を記録しました。

オリジナルの MySQL 関係から変更した点:

  • すべてにおいて users.id を利用しなくして、users.login を利用するようにした
  • index 追加と my.cnf に数行追加

MySQL 版はこちら: https://github.com/sorah/isucon4-qualifier-sorah/tree/mysql

まとめ

Ruby 実装を利用した解き方の一つを紹介しました。

運営チームは ISUCON4 本選も楽しんでいただけるような問題を準備中です。お楽しみに!

Read more...

こんにちは、ISUCON4 運営チームの @mirakui です。 @rosylilly @sora_h とともに ISUCON4 の問題作成と運営を担当しています。

さて、予選に参加していただけたみなさんは楽しんでいただけたでしょうか。今回は、予選問題の振り返りをしたいと思います。

予選問題「いすこん銀行」

今回の予選問題は、「いすこん銀行」という架空の銀行の Web サービスがテーマでした。
01

銀行とはいっても、実は銀行としての機能は一切ないハリボテで、今回用意したのは ログイン機能 のみです。ログインって機能なの? と思うかもしれませんが、実際のウェブサービスを作る上で、ログイン部分の設計は単純では済みません。

それは、近年増加している「パスワードリスト攻撃」のような、不正ログインの対策を行わなければならないからです。

「いすこん銀行」には、ログイン画面と、ログインに成功した時に表示されるマイページの2画面しかありません。
ログイン画面でユーザ名とパスワードを入力し、ログインに成功するとマイページに遷移することができますが、失敗した場合、エラーメッセージを表示してログイン画面に戻ります。

このとき「いすこん銀行」は次のような条件で不正なログインとみなし、それ以降はログイン禁止にします。

  • 一つのユーザIDに対して試みたログインで、連続3回以上パスワードを間違えた場合、それ以降そのユーザIDはログイン不可能になる
  • 同一IPアドレスから試みたログインで、連続で合計10回以上パスワードを間違えた場合、それ以降そのIPアドレスからはログイン不可能になる


  • 今回の予選問題は、とにかくシンプルな問題にすることを意識して設計されました。最初は、銀行アプリケーションなので暗証番号表を用意しようとか、他アカウントへの振込み機能を作ろうとか言っていたのですが、工数の都合シンプルさを重視して、最終的にログイン機能のみを残しました。

    ログインを題材にしたのは、「パスワードリスト攻撃」を念頭に置いた、時事問題といったところです。

    ログインの記録と判定の実装

    「いすこん銀行」の参考実装では、全てのログイン試行において、リモートIPアドレス、ユーザID、ログイン成功可否をログとして MySQL に保存しています。

    そして、ログインが試みられたときに、そのユーザもしくはIPアドレスがアクセス禁止になっているかどうかを、このログから計算して判定しています。

    レポート機能

    不正なログインが来ているのかどうかはサイト管理者にとって心配の種です。ましてや銀行ならなおさらですよね。

    「いすこん銀行」では、/report にアクセスすると、ログイン禁止になったIPアドレスやユーザIDのリストを JSON で出力する機能があります。これは管理者用の機能を想定しています。

    そして、この /report は、この問題において最も重要なものです。

    レポートをどう作るか

    今回のアプリケーションには「ログイン試行のたびにログイン失敗数の判定をログインログから計算している」という無駄があります。

    ログイン失敗数は、インメモリであったり、Redis や Memcached などでカウンタキャッシュを持てば用意すれば高速に処理する事ができると思います。

    /report の内容を作るのにもログインログは使わずに、カウンタキャッシュだけあれば問題なかったりしますが、これを揮発性のデータストアに入れていると、サーバ再起動後に /report の内容が異なってしまい、レギュレーション違反となってしまうため、ここに関しては工夫が必要でした。

    ところで、 benchmarker の /report のチェックに関しては、以下のようなルールがありました。

    > 負荷走行の最後に、 benchmarker は5秒の待ち時間をおいた後、 /report にリクエストを行う。この /report は1分以内にレスポンスを返さなければならない。

    「5秒の待ち時間をおいた後」というのは、負荷走行の後にログインログをメモリから MySQL に書き出せばよいというのを意識して設定しました。

    また「/report は1分以内にレスポンスを返さなければならない」というルールで、タイムアウトが「1分」と比較的長めに設定してあるのは、集計をそれほど高速化しなくてもよいというメッセージでもありました。

    高rpsの戦い

    今回の本選出場のボーダーラインとなったスコアは「Team Ku's」チームの 37,808 でした。

    逆算すると、本選出場のためには1分間の負荷走行において平均約1.6ms、630 request/sec でレスポンスを返さなければならないということになります。

    これほどの低レイテンシを初期状態の LL + MySQL 構成のまま実現するのは簡単ではないでしょう。結果として、

  • 今回、ログインページ(トップページ)は4パターンしかないため、キャッシュする
  • ログインログへの書き込みをインメモリ、もしくは高速なミドルウェアに置き換える
  • Golang, C++ (!?) などの高速なコンパイル言語ですべて処理できるようにする

    というのが基本的な戦略になったようです。

    このように、コンパイル言語と比べて LL が不利になりがちな、低レイテンシ・高rpsの勝負となった予選ですが、予選を勝ち抜いたチームの多くが LL を利用しており、これも ISUCON の面白いところだと思います。

    本戦出場チームの利用言語割合:

    > Ruby 9組 31.0%
    > Go  7組 24.1%
    > PHP  6組 20.6%
    > Perl  6組 20.6%
    > C++  1組  3.4%


    参考実装の初期スコア

    ちなみにですが、各言語の初期スコアは以下のとおりでした。これは参考実装を何も変更せずに、 workload=1 で benchmarker を実行した結果です。

    02


    これが言語の有利不利を表現しているわけではありませんが、初期スコアには差があったことが分かります。

    なお、実装の都合上、 PHP だけは最初から CSS などの静的ファイルを Nginx で返す設定にしてあったことも補足しておきます。

    AMIの審査

    今回は /report のチェックが失敗したときのみ Fail するようにしていて、それ以外のレスポンスが間違っていても、スコアが伸びないだけです。その代わりに AMI 審査のチェックを運営がしっかり行い、レギュレーションに基いて表示崩れなどを失格にしています。

    賛否両論あると思いますが、機械的なチェックには限界があったり、厳密なチェックをしようとすると benchmarker の負荷が高くなったり、実装が大変だったりしてしまうので、benchmarker によるレギュレーションのチェックはそこそこにして、運営によるチェックをしっかりやるというのが今回の予選でした。

    レギュレーションの変更

    今回は以前公開したとおり、予選1日目に使った benchmarker に高スコアを出せてしまうバグがあり、2日目ではそのバグを修正しています。

    ISUCON4 本選出場の一部基準変更についての詳細 : ISUCON公式Blog

    この問題に関して、ご迷惑をおかけして申し訳ありませんでした。

    予選問題とAMIの公開

    以下のとおり予選問題を公開しますので、復習などにご利用ください。

  • レギュレーション: ISUCON4(2014) オンライン予選レギュレーション : ISUCON公式Blog
  • 当日マニュアル: ISUCON4 予選当日マニュアル
  • 予選問題のソースコード:isucon4/qualifier at master · isucon/isucon4
  • 予選で使われたAMI: ami-e3577fe2


  • それでは、ISUCON4 本選をお楽しみに!

    Read more...

    ↑このページのトップヘ