You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Chirag Dewan <ch...@gmail.com> on 2020/05/22 10:23:25 UTC

Performance Comparison HTTP1 vs HTTP2 in Tomcat 9.0.29

Hi,

I am trying to move to HTTP2 based APR connector from my HTTP1 based
connector because of some customer requirements.

I am trying to form some sort of throughput benchmark for HTTP2 in
comparison to HTTP1. I have a simple Jersey service that accepts a JSON
request and sends 200 with some headers.

I have observed that HTTP2 is somehow stuck at 6K as compared to 15K in
HTTP1.1 with the same amount of CPU and memory consumed.
My client with HTTP1.1 is based on HTTP components and opens up to 100
connections with Tomcat. On HTTP2, I have a Jetty client that opens 2
connections with multiplexing of 1024. I tried increasing the connections
to 20 as well, but that only has adverse affects.

I am running Tomcat on a K8 pod with 3Gi CPU and 2Gi memory. With both
HTTP2 and HTTP1.1 Tomcat consumes all 3 cores and approximately 800m memory.

In the thread dumps with HTTP2, I see a lot of BLOCKED threads:
[image: image.png]
Most of the threads are blocked in *writeHeaders. *

Am I missing something here? Any help is much appreciated.

Thank you
Chirag

Re: Performance Comparison HTTP1 vs HTTP2 in Tomcat 9.0.29

Posted by Mark Thomas <ma...@apache.org>.
On 22/05/2020 16:01, Chirag Dewan wrote:
> Thanks for the quick response Mark.
> I agree 1024 concurrent streams are a bit far fetched and may cause an
> overhead. But at the same time, I have tried the same test with the Jetty
> Multiplexed connection pool with 100 concurrent streams(that is actually
> updated from the initial Settings frame).
> 
> And even in such kind of a connection strategy, we see ~6K around
> throughput. And to my surprise, even with 20 established connections, we
> could not reach the throughput in an HTTP1.1 connector.
> 
> Are there any benchmarking results for HTTP2, in comparison to HTTP1.1 I
> can refer?

Have a look at  Jean-Frederic's HTTP/2 presentations.

As with most performance tests, the results you get depend on a lot on
how you structure the test.

Mark



http://tomcat.apache.org/presentations.html
> 
> Chirag
> 
> On Fri, May 22, 2020 at 4:29 PM Mark Thomas <ma...@apache.org> wrote:
> 
>> On 22/05/2020 11:23, Chirag Dewan wrote:
>>> Hi,
>>>
>>> I am trying to move to HTTP2 based APR connector from my HTTP1 based
>>> connector because of some customer requirements.
>>>
>>> I am trying to form some sort of throughput benchmark for HTTP2 in
>>> comparison to HTTP1. I have a simple Jersey service that accepts a JSON
>>> request and sends 200 with some headers.
>>>
>>> I have observed that HTTP2 is somehow stuck at 6K as compared to 15K in
>>> HTTP1.1 with the same amount of CPU and memory consumed.
>>> My client with HTTP1.1 is based on HTTP components and opens up to 100
>>> connections with Tomcat. On HTTP2, I have a Jetty client that opens 2
>>> connections with multiplexing of 1024. I tried increasing the
>>> connections to 20 as well, but that only has adverse affects.
>>>
>>> I am running Tomcat on a K8 pod with 3Gi CPU and 2Gi memory. With both
>>> HTTP2 and HTTP1.1 Tomcat consumes all 3 cores and approximately 800m
>> memory.
>>>
>>> In the thread dumps with HTTP2, I see a lot of BLOCKED threads:
>>> image.png
>>> Most of the threads are blocked in /writeHeaders. /
>>> /
>>> /
>>> Am I missing something here? Any help is much appreciated.
>>
>> With such a simple response and high concurrency I suspect you are
>> hitting a bottleneck with 1024 (or 100 if you haven't changed the
>> defaults) threads all trying to write to a single network connection at
>> once. That is never going to perform well.
>>
>> HTTP/2 is not a magic "make things faster" protocol. It reduces overhead
>> in some areas and increases overhead in others. Whether you see a
>> benefit is going to depend on where the bottleneck is in your system.
>>
>> If you are testing on a single machine or on a local network I'd expect
>> the additional complexity of HTTP/2 multiplexiing to quickly dominate
>> the results.
>>
>> If you want an idea of what is going on, I recommend using a profiler
>> although be aware that - unless there is an obvious performance issue -
>> you can quickly get to the point where getting the level of detail
>> required to track down the next bottleneck causes the profiler to create
>> more overhead than the issue you are trying to measure thereby
>> distorting the results.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Performance Comparison HTTP1 vs HTTP2 in Tomcat 9.0.29

Posted by Chirag Dewan <ch...@gmail.com>.
Thanks for the quick response Mark.
I agree 1024 concurrent streams are a bit far fetched and may cause an
overhead. But at the same time, I have tried the same test with the Jetty
Multiplexed connection pool with 100 concurrent streams(that is actually
updated from the initial Settings frame).

And even in such kind of a connection strategy, we see ~6K around
throughput. And to my surprise, even with 20 established connections, we
could not reach the throughput in an HTTP1.1 connector.

Are there any benchmarking results for HTTP2, in comparison to HTTP1.1 I
can refer?

Chirag

On Fri, May 22, 2020 at 4:29 PM Mark Thomas <ma...@apache.org> wrote:

> On 22/05/2020 11:23, Chirag Dewan wrote:
> > Hi,
> >
> > I am trying to move to HTTP2 based APR connector from my HTTP1 based
> > connector because of some customer requirements.
> >
> > I am trying to form some sort of throughput benchmark for HTTP2 in
> > comparison to HTTP1. I have a simple Jersey service that accepts a JSON
> > request and sends 200 with some headers.
> >
> > I have observed that HTTP2 is somehow stuck at 6K as compared to 15K in
> > HTTP1.1 with the same amount of CPU and memory consumed.
> > My client with HTTP1.1 is based on HTTP components and opens up to 100
> > connections with Tomcat. On HTTP2, I have a Jetty client that opens 2
> > connections with multiplexing of 1024. I tried increasing the
> > connections to 20 as well, but that only has adverse affects.
> >
> > I am running Tomcat on a K8 pod with 3Gi CPU and 2Gi memory. With both
> > HTTP2 and HTTP1.1 Tomcat consumes all 3 cores and approximately 800m
> memory.
> >
> > In the thread dumps with HTTP2, I see a lot of BLOCKED threads:
> > image.png
> > Most of the threads are blocked in /writeHeaders. /
> > /
> > /
> > Am I missing something here? Any help is much appreciated.
>
> With such a simple response and high concurrency I suspect you are
> hitting a bottleneck with 1024 (or 100 if you haven't changed the
> defaults) threads all trying to write to a single network connection at
> once. That is never going to perform well.
>
> HTTP/2 is not a magic "make things faster" protocol. It reduces overhead
> in some areas and increases overhead in others. Whether you see a
> benefit is going to depend on where the bottleneck is in your system.
>
> If you are testing on a single machine or on a local network I'd expect
> the additional complexity of HTTP/2 multiplexiing to quickly dominate
> the results.
>
> If you want an idea of what is going on, I recommend using a profiler
> although be aware that - unless there is an obvious performance issue -
> you can quickly get to the point where getting the level of detail
> required to track down the next bottleneck causes the profiler to create
> more overhead than the issue you are trying to measure thereby
> distorting the results.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: Performance Comparison HTTP1 vs HTTP2 in Tomcat 9.0.29

Posted by Mark Thomas <ma...@apache.org>.
On 22/05/2020 11:23, Chirag Dewan wrote:
> Hi,
> 
> I am trying to move to HTTP2 based APR connector from my HTTP1 based
> connector because of some customer requirements.
> 
> I am trying to form some sort of throughput benchmark for HTTP2 in
> comparison to HTTP1. I have a simple Jersey service that accepts a JSON
> request and sends 200 with some headers.
> 
> I have observed that HTTP2 is somehow stuck at 6K as compared to 15K in
> HTTP1.1 with the same amount of CPU and memory consumed. 
> My client with HTTP1.1 is based on HTTP components and opens up to 100
> connections with Tomcat. On HTTP2, I have a Jetty client that opens 2
> connections with multiplexing of 1024. I tried increasing the
> connections to 20 as well, but that only has adverse affects.
> 
> I am running Tomcat on a K8 pod with 3Gi CPU and 2Gi memory. With both
> HTTP2 and HTTP1.1 Tomcat consumes all 3 cores and approximately 800m memory.
> 
> In the thread dumps with HTTP2, I see a lot of BLOCKED threads:
> image.png
> Most of the threads are blocked in /writeHeaders. /
> /
> /
> Am I missing something here? Any help is much appreciated.

With such a simple response and high concurrency I suspect you are
hitting a bottleneck with 1024 (or 100 if you haven't changed the
defaults) threads all trying to write to a single network connection at
once. That is never going to perform well.

HTTP/2 is not a magic "make things faster" protocol. It reduces overhead
in some areas and increases overhead in others. Whether you see a
benefit is going to depend on where the bottleneck is in your system.

If you are testing on a single machine or on a local network I'd expect
the additional complexity of HTTP/2 multiplexiing to quickly dominate
the results.

If you want an idea of what is going on, I recommend using a profiler
although be aware that - unless there is an obvious performance issue -
you can quickly get to the point where getting the level of detail
required to track down the next bottleneck causes the profiler to create
more overhead than the issue you are trying to measure thereby
distorting the results.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org