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 <kirthal...@gmail.com> wrote: > > 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 Tuesday, November 9, 2021 at 6:28:16 PM UTC+1 ren...@ix.netcom.com wrote: >> 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 requires the use of >> locks to coordinate. By managing the window size, the connection reader >> should never block writing to a steam buffer - but a stream reader may stall >> waiting for data to arrive - get descheduled - only to be quickly >> rescheduled when reader places more data in the buffer - which is >> inefficient. >> >> Out of the box on my machine, http1 is about 37 Gbps, and http2 is about 7 >> Gbps on my system. >> >> Some things that jump out: >> >> 1. The chunk size is too small. Using 1MB pushed http1 from 37 Gbs to 50 >> Gbps, and http2 to 8 Gbps. >> >> 2. The default buffer in io.Copy() is too small. Use io.CopyBuffer() with a >> larger buffer - I changed to 4MB. This pushed http1 to 55 Gbs, and http2 to >> 8.2. Not a big difference but needed for later. >> >> 3. The http2 receiver frame size of 16k is way too small. There is overhead >> on every frame - the most costly is updating the window. >> >> I made some local mods to the net library, increasing the frame size to >> 256k, and the http2 performance went from 8Gbps to 38Gbps. >> >> 4. I haven’t tracked it down yet, but I don’t think the window size update >> code is not working as intended - it seems to be sending window updates >> (which are expensive due to locks) far too frequently. I think this is the >> area that could use the most improvement - using some heuristics there is >> the possibility to detect the sender rate, and adjust the refresh rate >> (using high/low water marks). >> >> 5. The implementation might need improvements using lock-free structures, >> atomic counters, and busy-waits in order to achieve maximum performance. >> >> So 38Gbps for http2 vs 55 Gbps for http1. Better but still not great. Still, >> with some minor changes, the net package could allow setting of a large >> frame size on a per stream basis - which would enable much higher >> throughput. The gRPC library allows this. >> >>>> On Nov 8, 2021, at 10:58 AM, Kirth Gersen <kirth...@gmail.com> wrote: >>>> >>> 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 buried (they're probably just swamped with too >>> many open issues (5k+...)). >>> >>> Everything using Golang net/http is impacted, the Caddy web server for >>> instance. >>> >>> I know it probably doesn't matter for most use cases because it's only >>> noticeable with high throughput transfers (>1 Gbps). >>> Most http benchmarks focus on "requests per second" and not "bits per >>> seconds" but this performance matters too sometimes. >>> >>> If anyone with expertise in profiling Go code and good knowledge of the >>> net/http lib internal could take a look. It would be nice to optimize it or >>> at least have an explanation. >>> >>> thx (sorry if wrong group to post this). >>> >> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to golang-nuts...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/89926c2f-ec73-43ad-be49-a8bc76a18345n%40googlegroups.com. >> > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/7332f727-6716-4c4d-85c5-a86cacd0c89fn%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/A0BB9048-CB82-4144-AECC-93FEC115E585%40ix.netcom.com.
