Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/net/http2: request-response loop is ~2-3 times slower on http2 than on https #18309

Scratch-net opened this issue Dec 14, 2016 · 4 comments


Copy link

@Scratch-net Scratch-net commented Dec 14, 2016

What version of Go are you using (go version)?

go version go1.7.4 linux/amd64

What operating system and processor architecture are you using (go env)?

GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build416699138=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I need a fastest way to securely communicate between microservices. And I tested request-responce loop with https and http2. Client starts 10 goroutines and each of them does 10k requests to server

And it turned out that https is 2 to 3 times faster when sending and receiving relatively small amounts of data(129 bytes request, 173 bytes response)

Client: (change IP on line 42)

I have 2 2xcpu servers with ~1 ms latency between them

When I run this test with http2 enabled it takes about 14 seconds for 100k requests divided in 10 goroutines
without http2 it takes about 7 seconds

Moreover, if I reuse client between goroutines it takes ~24 seconds on http2.

What did you expect to see?

A speed up between client and server when using http2

What did you see instead?

2x slowdown

@bradfitz bradfitz added this to the Unreleased milestone Dec 14, 2016
@bradfitz bradfitz changed the title x/net/http2 request-response loop is ~2-3 times slower on http2 than on https x/net/http2: request-response loop is ~2-3 times slower on http2 than on https Dec 14, 2016
Copy link

@tombergan tombergan commented Dec 14, 2016

I don't think anyone will have a chance to look at this in detail until after Go 1.8 is released. In the meantime, the following may help:

  1. Do you see the same slowdown in go 1.8 beta or in go 1.6?
  2. Do you have svg profiles of the http2 server and client?

Brad has done some optimization work for grpc-over-http2 that may help. I'm not sure if all of those optimizations have been submitted yet.

What did you expect to see?
A speed up between client and server when using http2

I wouldn't expect a speedup. The https version probably pipelines all 100k requests over just 10 TCP connections. I doubt you will see any benefits from muxing all requests onto a single TCP connection unless you're on a congested WAN or have many fewer requests-per-connection. That said, a 2x slowdown is not expected. Thanks for the report.

Copy link

@Scratch-net Scratch-net commented Dec 15, 2016

Hi and thanks for your response.

I've tested with current master go version devel +c1ada22b Thu Dec 15 05:46:20 2016 +0000 linux/amd64 and results are prety same

Here are profiles made with go 1.7.4: (http2, one client per goroutine)

I understand that 10 keepalive https connections might be faster than one http2 connection but don't understand why are they faster than 10 http2 connections.

Also I've tested this very client against nginx http2 server with the same response size and for some reason using one http2 connection in client is faster than 1 per goroutine. Have no idea why

Copy link

@tombergan tombergan commented Jul 13, 2017

@Scratch-net, can you try with Go 1.9? There are a few HTTP/2 performance improvements for the 1.9 release.

Copy link

@gopherbot gopherbot commented Aug 13, 2017

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@gopherbot gopherbot closed this Aug 13, 2017
@golang golang locked and limited conversation to collaborators Aug 13, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants