ベンチマーカーのコネクションリーク

[methane]

https://github.com/isucon/isucon6-qualify/blob/master/bench/cli.go#L70
ここで scenario 関数を実行するたびに NewSession() していて、

https://github.com/isucon/isucon6-qualify/blob/master/bench/checker/session.go#L46
ここで Session ごとに Transport を作ってしまっているのですが、 Transport はコネクションプールに
なっているので、 Session & Transport を GC 任せに破棄すると、その Transport に
残っている http クライアントのコネクションが開放されずにベンチマーカー終了まで
残ってしまうように見えます。

そのため、アプリ側のチューニングが進むと、ベンチマーカー側が too many open files になったり、
ポートが枯渇したりして、スコアが上がらなくなります。

回避策としては、

1. 一つの大きめの Transport を用意し、全部の Session で共有する
2. どうしても Session 間で Transport を共有したくない場合は、 scenario の終了後 (Transportがもう利用されてない状態で) CloseIdleConnections を呼ぶことで、 keep-alive しているコネクションを開放してやる

Go の想定している使い方としては 1 の方がおすすめですが、それだと１つのTCPコネクションを
通して複数のユーザーのhttpリクエストが送られてくることになるので、多数のブラウザからの
（ロードバランサーなどを介さない）接続をエミュレートしたいなら 2 の方が近くなります。

[methane]

なお、「大きめのTransport」とは、 Transport の以下のメンバーを適切に設定することを意味しています。

        // MaxIdleConns controls the maximum number of idle (keep-alive)
        // connections across all hosts. Zero means no limit.
        MaxIdleConns int

        // MaxIdleConnsPerHost, if non-zero, controls the maximum idle
        // (keep-alive) connections to keep per-host. If zero,
        // DefaultMaxIdleConnsPerHost is used.
        MaxIdleConnsPerHost int

https://golang.org/pkg/net/http/#Transport

その下にある以下の文が、「Go の想定している使い方」を説明しています。

By default, Transport caches connections for future re-use. This may leave many open connections when accessing many hosts. This behavior can be managed using Transport's CloseIdleConnections method and the MaxIdleConnsPerHost and DisableKeepAlives fields.