(At d286399, on linux/amd64)

Might be related to #18753 with BenchmarkClientServerParallel64 on mac os - which is the same test just with more parallelism. I've see a similar problems on mac os with BenchmarkClientServerParallel4 and variants. The first 3 runs are fine, second time it is run thrice it dies with the error: can't assign requested address. Waiting a minute and trying again results in the same pattern - fine for first run, fails afterward, as opposed to trying again straight away which fails repeatedly, so it does seem to be exhausting resources by tying them up for too long.

netstat -a after the test shows thousands of connections in state TIME_WAIT for a minute or two, but I guess that's normal?

kenny$ cd src/net/http
kenny$ go test -benchtime=1s -bench=BenchmarkClientServerParallel4 -count=3 -run=XXXX | tee before
goos: darwin
goarch: amd64
pkg: net/http
BenchmarkClientServerParallel4-4   	   30000	     51827 ns/op	    7677 B/op	      75 allocs/op
BenchmarkClientServerParallel4-4   	   10000	    156941 ns/op	    7948 B/op	      76 allocs/op
BenchmarkClientServerParallel4-4   	   10000	    149905 ns/op	    7936 B/op	      76 allocs/op
PASS
ok  	net/http	5.105s
kenny$ go test -benchtime=1s -bench=BenchmarkClientServerParallel4 -count=3 -run=XXXX | tee before
goos: darwin
goarch: amd64
pkg: net/http
BenchmarkClientServerParallel4-4   	   10000	    284811 ns/op	    7809 B/op	      76 allocs/op
--- BENCH: BenchmarkClientServerParallel4-4
	serve_test.go:4756: Get: Get http://127.0.0.1:58703: dial tcp 127.0.0.1:58703: connect: can't assign requested address
	serve_test.go:4756: Get: Get http://127.0.0.1:58703: dial tcp 127.0.0.1:58703: connect: can't assign requested address
	serve_test.go:4756: Get: Get http://127.0.0.1:58703: dial tcp 127.0.0.1:58703: connect: can't assign requested address

CL https://golang.org/cl/49031 mentions this issue.

I think this problem is caused by how are we using ts.Client().

httptest.Server has a Client function that returns the same client every time it's called.

When we use ts.Client() inside a parallel test without calling CloseIdleConnections() on the transport, a lot of idle connections start to pile up and the OS may decide not to grant any one else more.

httpserver.Server does close the transport's idle connections, but only does so when the server itself is closed.

I submitted a solution that I think fits with the httptest.Server's design, but this could also be fixed by using something like:

tr := &Transport{}
defer tr.CloseIdleConnections()
c := &Client{Transport: tr}

instead of c = ts.Client()

Thank you for the investigation @xiam and for sending the CL. So for an updated, since Go1.12, we now have Client.CloseIdleConnections() https://golang.org/pkg/net/http/#Client.CloseIdleConnections -- committed on August 20th 2018 and in CL https://go-review.googlesource.com/130115.

Following up with your suggestion, perhaps in that defer, we could invoke defer client.CloseIdleConnections()?

If so, and if you have the time, a CL from you following up your previous one https://go-review.googlesource.com/c/go/+/49031/, would be great for Go1.15. @bradfitz would also be happy to see more folks involved with net/http.

Thank you!

To disable the automatic connection cache (if that's what you need) you can configure the Transport:

tr := &Transport{DisableKeepAlives: true}
c := &Client{Transport: tr}

Depending on the timing, closing idle connections may not work as reliably or have no effect at all (because a connection may not be considered "idle", yet). You can also configure a maximum number of idle connections on the Transport.