showwin / ishocon2 Goto Github PK

showwin/ISHOCON1#10

ISHOCON1と同じIssue.
publicフォルダの中身は共通なので、どこかから環境構築時にcpする方式にすればどうだろうという提案。

ベンチマーク実行後に(任意に)自動でスコアが反映されるポータルサイトの作成

時系列のグラフではなくて、ランキングみたいなのが良さそう
benchmark --ranking showwin みたいに ranking オプションでチーム名を指定してスコア自動送信ができる。

せっかくSSL使っているんだし、http/2で爆速にしてみたい。

1. http1.1のみを使って、Clientを毎回生成(現状)
2. http2が使えるなら使うようにして、Clientを毎回生成
   #9
3. http2が使えるなら、Clientを全部使い回す
   https://qiita.com/catatsuy/items/bf3a1a5ffde1f5802d5a で述べられているように、ISUCONらしくはなくなる。全ての投票者が同じ端末からアクセスしていることになるから。
4. http2が使えるなら、Clientを一部使い回す
   Clientをあらかじめ100個ほど生成し、requestの時にこの中からランダムで選ぶ、とか。

現状の点数や、コンテストとしての方針が大幅に変わる恐れがあるので、慎重にお願いします。

TODO

課題と解決方法

• 現在の app-base および benchmarker のイメージが、アーキテクチャの違いから、apple silicon mac で動かした場合にパフォーマンスが悪化する恐れがある
• arch が amd64 だった場合に arm64v8/ubuntu をベースイメージとすることで、パフォーマンスの改善が見込まれる
  • https://hub.docker.com/r/arm64v8/ubuntu/
• その場合にはローカルで app-base と benchmarker をビルド可能にする必要がある

懸念点

• private isucon という観点から言うと、イメージを変えるのは良くない可能性がある

ライブラリや言語のバージョンの更新をしていきたいが、影響範囲を毎回調査するのはつらい。
初期実装でベンチマーカが通ればOKという条件で無条件にあげていけたら嬉しい。

2016年の記録では最大 Workload 10 にするとメモがあったが、適当な値か不明なので調査して、workload 数に上限を設ける。

benchmarker では http.Transport を作る際に TLSClientConfig のみ設定していますが、

この状態だと https://pkg.go.dev/net/http?tab=doc#Transport にあるように TLSHandshakeTimeout がゼロ値 = タイムアウトなしとなり、サーバー側が TLS handshake で詰まっているときに待ち続けてしまうようです。

高負荷のためうまく接続できないこと自体は競技者側の責任としてよいでしょうが、ベンチマーカーがそこで hang してしまうのは計測上問題があるのでなんらかのタイムアウトを設けるのが望ましいように思います。

通常の net/http のデフォルト挙動から変更する意図がなければ、 astj@8bc05ca (Transport#Clone を使ってしまったのでおそらく >= Go 1.13 でしか動かないです) のように http.DefaultTransport の設定を clone すると穏当なタイムアウトが設定できるかと思います。
もちろん、 https://github.com/golang/go/blob/go1.15.1/src/net/http/transport.go#L42-L54 と同じ値を直接指定しても良くなるだろうと思っています。

https://github.com/showwin/ISHOCON2/blob/master/README.md の,
ベンチマーカーAMI: ami-78b66107 を用意してくださっているのは大変ありがたいのですが,
ami-78b66107 のベンチマーカーは実装が古い段階のものであり,50000点くらいまでしか出ない(TLSハンドシェイクのため)ので,isuconの練習をする方が困るかもしれません.

そのため,ドキュメントのどこかに注記しておくか, ami を更新した方がisuconの練習をする方にむけては助かるかもしれません.

ubuntu14.04だとaptとか古くて色々辛いので、16.04かできれば18.04でお願いします・・・。

workload を 100 ぐらいにしてベンチマーカーを実行すると MySQL への接続をするところで Too Many Connections のエラーが発生してベンチマーカーが途中で止まってしまうバグがある。
#26 で修正したつもりだったが直っていなかった。

workload の値を小さくすると発生しづらいような気がする。

ISHOCON2のコンテスト実施前までにやる