Closed erin-noe-payne closed 7 years ago
This is almost certainly #16512
I think vegeta is starved for flow control tokens.
/cc @tombergan
Also see #17985
@bradfitz, I think this is more than #16512. Why are there 2 conn.serve goroutines but 165212 conn.writeFrameAsync goroutines? There should be at most one writeFrameAsync goroutine per serve goroutine. There is either a bug that triggers multiple concurrent frame writes, or a goroutine leak that doesn't cleanup writeFrameAsync goroutines. The latter seems likely. Probably this should wait for "wroteFrameCh<-" or doneServing? https://github.com/golang/net/blob/45e771701b814666a7eb299e6c7a57d0b1799e91/http2/server.go#L640
Hey guys, thanks for the quick response. This discussion leads to some follow-up questions:
@autoric, yup, those are the questions this bug is about investigating. We'll probably need better (or automatic) defaults, and more knobs.
I'm always a fan of the no knob solution, but if there could be knobs only in the http2 pkg offered earlier than the auto solution it would be great for us.
CL https://golang.org/cl/35118 mentions this issue.
Maybe it's somehow related to #18309
CL https://golang.org/cl/37226 mentions this issue.
CL https://golang.org/cl/37500 mentions this issue.
@autoric, do the above two changes fix the problem? I'm a bit concerned about the number of goroutines (see prior comment) but the flow control problem should be fixed.
@tombergan Thanks for the update! I will run tests in the next couple days and get back to you.
@autoric, any updates? Please try Go master before it becomes Go 1.9beta1 soonish here.
Timeout. I assume this was fixed. Comment if not.
What version of Go are you using (
go version
)?go version go1.7.4 darwin/amd64
What operating system and processor architecture are you using (
go env
)?What did you do?
The server code:
Create a data file for testing:
$ mkfile -n 5m 5mb.txt
Using the vegeta load test client:
$ echo PUT https://localhost:3000/ | vegeta attack -insecure -duration=10s -rate=25 -body=5mb.txt | vegeta report
Run the same test against the server running in http/1.1 and http/2 mode.
What did you expect to see?
I would expect the performance (average latency / throughput) of an http/2 server to be similar or better than http/1.1.
What did you see instead?
HTTP/2 results:
HTTP/1.1 results:
Further info:
ioutil.ReadAll(req.Body)
- then requests are processed quickly (fairly obvious)Conclusion
Basically, HTTP/2 is merged into core and enabled by default on TLS servers. This leads me to expect that an HTTP/2 server should perform similarly or better than an HTTP/1.1 server under most conditions. I wish to build performant REST APIs that can sustain reasonable throughput, and HTTP/2 offers a number of features that I had assumed would improve performance.
I'm not clear if this is a bad assumption, I am misusing the APIs somehow, or this reflects an issue with the implementation. Any support, information, or recommendations would be greatly appreciated. Thanks!