net/http: use the http2 priority scheduler by default

[tombergan]

The x/net/http2 scheduler has two implementations: a random scheduler and a priority scheduler. The random scheduler mimics the old scheduler used in go 1.7 and earlier. The priority scheduler uses the http2 priority tree to schedule writes. I have benchmarks showing that web pages load considerably faster with the priority scheduler than the random scheduler.

We opted not to change schedulers for go 1.8 to minimize churn and give the code a chance to bake. Going forward, I see no major reason why we shouldn't use the priority scheduler by default in net/http. My only concern is CPU usage. The priority scheduler has some operations that are O(n) in the worst case, where n is len(connection.openStreams). I don't believe it's possible to faithfully implement the http2 priority spec without an O(n) worst case, but I admittedly haven't given that question much thought. That said, I don't expect the worst case to occur often in practice, and even if the worst case does occur, n is capped to a small constant -- 250 by default, and we can lower this if needed. Given the measurable benefits on client-perceived page load time, I think it's worth turning on the priority scheduler by default. We can always roll back during the 1.9 beta phase if we get complaints.

We could also make the scheduler selectable via an environment variable.

Non-web servers, such as grpc, may want to continue using the random scheduler.

/cc @bradfitz, I would label this Go1.9early

[tombergan]

The priority scheduler has some operations that are O(n) in the worst case, where n is len(connection.openStreams). I don't believe it's possible to faithfully implement the http2 priority spec without an O(n) worst case, but I admittedly haven't given that question much thought.

Turns out, O(n) is actually the worst case. Some discussion in the thread below. There is some optimization opportunity to reduce the constants, but a faithful implementation cannot avoid the O(n) worst-case.
https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0107.html

[gopherbot]

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

[gopherbot]

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

[bradfitz]

Looks like https://golang.org/cl/43231 was all that was needed.