Go http/2 ClientConn readLoop use more memory than http/1.1

[Divyanshu Rawat]

In my golang application I was using a x/net/http package with a custom TLS Config making http/1.1 connections only. I wanted to introduce the http/2 support to my application. Since I was using a custom TLS Config, which disabled http/2 support by default. So to enabled the http/2 support, I setted the ForceAttemptHTTP2 flag to true in my transport.

Expected Result:

For the server which support http/2 the request should be upgraded and http/2 call should be made. And if not supported the request should fallback to using http/1.1

Though I'm seeing the expected result but there's a 200MB more memory usage by my application. I profiled my application and found that readLoop and reading http2 frames is taking up more memory.

1. Profiling With http/2 enabled

2. Profiling without http/2 enabled:

I also tried the same with providing explicit http2 transport from x/net/http2 package, but was still seeing a higher memory usage.

Any experts with using http/2 with golang please help out with this.

Is this an expected result that with http/2, that we will be using more memory at the cost of multiplexing and streaming? Or am I missing something here?

[Eli Lindsey]

Is this an expected result that with http/2, that we will be using more memory at the cost of multiplexing and streaming? Or am I missing something here?

They’re very different protocols, so it’s often not useful to directly compare. There are aspects of http/2 (eg. hpack state) that will tend to make it use more memory per connection than http/1.1.

It’s difficult to read your profiling images in email, but my recommendation would be to tackle this as a perf/profiling exploration on the http/2 side and not as a comparison. Some specific questions that may be useful to chase down: is it using 200mb memory in steady state, or is it generating 200mb of additional garbage that’s waiting to be collected? I would also take a tcpdump and look at the request flow - do you have large requests or responses that are getting split into very small frames, and if so might it be useful to increase the max frame size (though this comes with tradeoffs)? Or are you perhaps seeing more application-level buffering due to http/2 flow control where previously that memory was either buffering or being flow controlled by the kernel tcp stack, which may necessitate tuning the per-stream or per-conn h2 flow control settings?

-eli

On Nov 16, 2023, at 7:13 AM, Divyanshu Rawat <rawatdiv...@gmail.com> wrote:

In my golang application I was using a x/net/http package with a custom TLS Config making http/1.1 connections only. I wanted to introduce the http/2 support to my application. Since I was using a custom TLS Config, which disabled http/2 support by default. So to enabled the http/2 support, I setted the ForceAttemptHTTP2 flag to true in my transport.

Expected Result:

For the server which support http/2 the request should be upgraded and http/2 call should be made. And if not supported the request should fallback to using http/1.1

Though I'm seeing the expected result but there's a 200MB more memory usage by my application. I profiled my application and found that readLoop and reading http2 frames is taking up more memory.

1. Profiling With http/2 enabled

<Screenshot 2023-11-15 at 2.52.37 PM.png>

<Screenshot 2023-11-15 at 2.53.18 PM.png>

2. Profiling without http/2 enabled:

<Screenshot 2023-11-15 at 2.56.12 PM.png>

<Screenshot 2023-11-15 at 2.56.27 PM.png>

I also tried the same with providing explicit http2 transport from x/net/http2 package, but was still seeing a higher memory usage.

Any experts with using http/2 with golang please help out with this.

Is this an expected result that with http/2, that we will be using more memory at the cost of multiplexing and streaming? Or am I missing something here?

--
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/683db9c4-f5e5-4f9e-864d-0a4b35c07021n%40googlegroups.com.
<Screenshot 2023-11-15 at 2.53.18 PM.png><Screenshot 2023-11-15 at 2.56.27 PM.png><Screenshot 2023-11-15 at 2.56.12 PM.png><Screenshot 2023-11-15 at 2.52.37 PM.png>