bench/

Details

マニュアルに書いてあるのだが、言い換えるとこういうこと。

初期化処理の実行 GET /initialize (10秒以内)
アプリケーション互換性チェックの走行 (適宜: 数秒〜数十秒)
- 500、タイムアウト、互換性チェック、その他なんでもエラーになったら fail
負荷走行 (60秒 - 2.の互換性チェックにかかった時間)
- 負荷スレッド(goroutines)で負荷をかけ続ける。
  - 負荷スレッドは、負荷をかけることだけを目的としており、全てのエラーは無視される。
  - 自動負荷レベルアップには影響がある。
- メインスレッドで互換性チェックをランダムで走らせ続ける。
  - 負荷をかけている最中なので、タイムアウトは当然起こりうるため、500 およびタイムアウトエラーは許している。互換性チェックに引っかかった場合だけ fail
負荷走行後の確認 (適宜: 数秒〜数十秒)
- 500、タイムアウト、互換性チェック、その他なんでもエラーになったら fail
- 負荷走行中のリクエストがサーバに溜まっているので、適切に backlog を絞るなどしないと本来軽いはずのログインリクエストでタイムアウトが起こりうる。

今回のベンチマーカには isucon6-final、isucon7-qualify でも使われていた自動負荷レベルアップ機構が採用された。

こちらもマニュアルに書いてあるのだが、補足するとこういうこと。

負荷走行中は、毎秒負荷レベルが増えていきます。
ただし、過去5秒以内に何らかのエラーが発生していた場合は負荷レベルが上昇しません。
- /api/users/:id、/admin/api/sales/reports など遅いエンドポイントが１つでもあると、負荷レベルが5秒上がらないということ

なお、負荷レベルが 1 あがると、goroutines の数が 1.5 倍に増える(合宿での事前回答時に、10 goroutines ずつ増やす程度では負荷が足りないというフィードバックがあった)。

あえて即座に500エラーを返すことにより、スコアブーストを狙うという戦法を防ぐために、エラーが起きた場合は500ミリ秒 sleep するという隠れ仕様があった。

portal に polling で問い合わせて起動。portal から benchmarker を叩く必要がない。
benchmarker を外部コマンドとして起動しているので、benchmarker のメモリが太ったり panic を起こしても対処可能。ファイルを atomic に置き換えれば競技中に benchmarker の更新が可能。
benchmarker が固まった場合、300 sec で殺すようにしてある (土曜はここが 100 sec になっていて仕様上足りていなかった）。
benchmarker が不意に死んだ場合、is_aborted を portal に投げて abort させる (土曜はここがバグってた)。
TODO: graceful restart 未対応 (このため、土曜は #announce に投げて再起動させてもらった）。

速くなるほどfailしやすくなる、という感想があった件についてこの仕様からの解説。

今回は適切にロックを取らないと race conditions が起きる問題になっている。速くなるほど互換性チェックをより多く回すことができるようになるため「たまたま pass していた確率」が減り、fail しやすくなる。

ベンチを走らせると、大きく点数が変わることがあったようだ。この件についてこの仕様からの解説。

負荷走行中、遅い or エラーの出るエンドポイントに最初の方でたまたま当たるかどうかで影響がある。負荷レベルは5秒あがらないため、最初の方で負荷レベルが上がらないと、5秒間負荷レベルが低い状態が続き、得点に影響が出る。
WaitOnError の仕様により、エラーが出るエンドポイントに当たると sleep が入り、得点が伸び悩む。
負荷走行がランダムがあるが故の得点のブレ

おそらく一番大きな要因となってしまったのが自動負荷レベルアップの仕様。

来年の出題者へ

自動負荷レベルアップ方式については再考の余地あり
- 5秒上がらない設定にしていたが、1秒で良かったかも
- 遅いエンドポイントが１つでもあるとレベルアップしづらくなるのは、マニュアルに書いてあるとは言え、ベンチマーカの気持ちを忖度できる競技参加者しか見抜けない
- 限界まで負荷をあげるのでタイムアウトが起こることを前提にせざるをえず、ベンチマーカの実装が非常に面倒
workermode は graceful restart できるようにしておこう