I also maintain an app that moves several Gbit/s of data, and have noticed that it bottlenecks while using http2, but handles much more throughput per instance, with lower tail latency, when running under GODEBUG=http2client=0. Possibly relevant is that it makes a large number of requests to a single upstream https host (like the PoC here does). I can't share source or any detailed data, but I'm willing to discuss further, and to test-drive any workarounds or fixes. I definitely believe there's a real performance regression here, at least under particular circumstances.
Thanks, Andrew On Monday, November 8, 2021 at 12:59:31 PM UTC-5 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3e955e54-9429-4692-82ce-5714f3870c1en%40googlegroups.com.