Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

Correct. If you refer to the code in the OP you will see that different transports are created in order to test http1 vs http2. If you wish to use the default behavior to use http2 you need to rebuild the stdlib (at least as far as I understand the issue with h2_bundle). My patches only affect

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

I already use the replace directive for but this doesn't for the net/http h2_bundle thing. see https://www.youtube.com/watch?v=FARQMJndUn0=814s Le ven. 19 nov. 2021 à 18:33, Robert Engels a écrit : > > Use the replace directive to point the net package to your local copy. > > Much easier to

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

(sorry for the previous reply, wrong account) and sorry I wasn't clear enough: I already use the replace directive for x/net. this works fine for the POC but only when explicitly using a http2 transport. But this doesn't for the net/http because of the h2_bundle thing. see

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

Use the replace directive to point the net package to your local copy. Much easier to test X changes than stdlib changes. > On Nov 19, 2021, at 10:58 AM, Kirth Gersen wrote: > > Your CL works well with the POC. > > Side question not specific to this issue: how to test changes to >

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

Your CL works well with the POC. Side question not specific to this issue: how to test changes to golang.org/x/net with net/http ? The 'h2_bundle' trick with go generate & bundle requires to fork the std lib too ? I have a hard time figuring how to do this. I tried with gotip but I get an

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

Since http2 multiplexes streams it will delicately affect latency on other streams. This is why I suggested using multiple transports - one for high throughput transfers and another for lower latency “interactive” sessions. > On Nov 15, 2021, at 9:23 AM, Kevin Chowski wrote: > > These are

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

These are interesting results, thanks for investigating and sharing results! I see that you have mostly been focusing on throughput in your posts, have you done testing for latency differences too? On Saturday, November 13, 2021 at 6:11:40 PM UTC-7 ren...@ix.netcom.com wrote: > As another

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

As another data point, I decided to test a few implementations of http2 downloads on OSX. Using a Go server with default frame size (16k): Go client: 900 MB/s Java client: 1300 MB/s curl: 1500 MB/s Using a Java server with default frame size (16k): Go client: 670 MB/s Java client: 720 MB/s

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

No worries. I updated the issue and the CL. I will comment in the CL with a few more details. > On Nov 10, 2021, at 2:30 PM, Andrey T. wrote: > > Thank you Robert, > I somehow missed the reference to the ticket in the first message, sorry > about that. > > As for the CL - I think adding

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

Thank you Robert, I somehow missed the reference to the ticket in the first message, sorry about that. As for the CL - I think adding link to the github issue, and add a bit of explanation in a commit message would help. I added link to your CL to the github issue's discussion, hopefully it

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

As reported in the OP, the issue was filed long ago https://github.com/golang/go/issues/47840 My CL https://go-review.googlesource.com/c/net/+/362834 is a viable fix (and should of been supported

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

Fellas, I would say the 5x throughput difference is a serious problem.Would you be kind and open an issue on github about it? Also, the PR that you have might benefit from explanation about what you are trying to solve (and probably link to an issue on github), so it would get more attention.

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

Well, I figured out a way to do it simply. The CL is here https://go-review.googlesource.com/c/net/+/362834 The frame size will be used for all connections using that transport, so it is probably better to create a transport specifically for

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

To be clear, I have no plans to submit a Cl to improve this at this time. It would require some api changes to implement properly. > On Nov 9, 2021, at 12:19 PM, Kirth Gersen wrote: > > Great ! > > > I made some local mods to the net library, increasing the frame size to > > 256k, and the

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

Great ! > *I made some local mods to the net library, increasing the frame size to 256k, and the http2 performance went from 8Gbps to 38Gbps.* That is already enormous for us. thx for finding this. 4 -> Indeed a lot of WINDOW_UPDATE messages are visible when using GODEBUG=http2debug=1 On

Re: [go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

I did a review of the codebase. Http2 is a multiplexed protocol with independent streams. The Go implementation uses a common reader thread/routine to read all of the connection content, and then demuxes the streams and passes the data via pipes to the stream readers. This multithreaded nature

[go-nuts] Go http/2 implementation is x5 less per performant than http/1.1

http/2 implementation seems ~5x slower in bytes per seconds (when transfer is cpu capped). POC: https://github.com/nspeed-app/http2issue I submitted an issue about this 3 months ago in the Go Github ( https://github.com/golang/go/issues/47840 ) but first commenter misunderstood it and it got