Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
x/net/http2: investigate Server speed regressions from more select case #20302
runtime.selectgoImpl: 13.06s of 451.69s
Compare this to the profile from go 1.7:
runtime.selectgoImpl: 4.65s of 12.69s
referenced this issue
May 9, 2017
Here is a version of BenchmarkServerGets that adds concurrency. I cannot reproduce the bug though. The benchmark has the same runtime before and after commenting out the select cases listed in this comment.
I wonder if there's something about their testbed setup that makes really long scheduling delays possible? Or maybe they're running in a VM that has a weird implementation of sys_futex?
@tombergan thanks. That benchmark patch doesn't apply cleanly for me (mail a CL next time?), but I applied it manually, and got:
and lots more errors.
Anyway, from visually inspecting the patch, it does set up a concurrent get, but not N concurrent gets, so it doesn't appear that it would really introduce contention. You want something (waves hands) like:
You can check for full concurrency using runtime tracing. Be sure to use a short benchtime to avoid overwhelming amounts of data.
You should see all procs active the whole time, not just one or two. If it is fully parallel, and there are contention effects, you should also be able to see the effect when you mess with -cpu:
Sorry the patch didn't apply cleanly, not sure why that happened.
HTTP/2 frames must be serialized onto a TCP connection. Whether or not the "gets" run concurrently on the client side is not relevant to server-side concurrency. Previously, the test forced serial execution on the server because it waited for a response immediately after sending each request. My patched test reads the responses in a background goroutine so the server can respond concurrently with the client sending new requests. The client still needs to send requests serially (the
The server will serialize response frames, but each HTTP request handler should run concurrently. That serialization is managed by the
Thanks for the tips about runtime tracing. Hopefully I have time later today to try that out.