mod_http2 v1.10.0

[Stefan Eissing <st...@greenbytes.de>]

Hi there,

a new version of mod_http2 has been backported to 2.4.x and there is also a github release, as usual: https://github.com/icing/mod_h2/releases/tag/v1.10.0

I rewrote some key parts of scheduling and slave connection handling for better performance. It shows good results. However it needs more testing than just by myself. If you have a HTTP/2 setup where you can risk it, please give it a try. The github builds against a 2.4.25 server, so you do not need to got totally into the unknown. Thanks!

-Stefan

PS. I plan to write a blog about it, but the basic store is in this picture.  This is hammering localhost with a list of 180 urls over and over with h2load. Most interesting are the changes to the green bars. The yellow shows that there is still a large gap between what HTTP/1.1 can do on 6 connections compared to HTTP/2 on a single one. But we're getting closer.

Re: mod_http2 v1.10.0

[Stefan Eissing <st...@greenbytes.de>]

> Am 04.04.2017 um 16:29 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
> 
> On Tue, Apr 4, 2017 at 9:24 AM, Stefan Eissing
> <st...@greenbytes.de> wrote:
>> 
>>> Which one is the yellow bar over 6 connections?
>> 
>> It's invisible. I extrapolated. Just ran the tests:
>> 
>> h1 (6 conn): ~28,000 req/s
>> h2 (6 conn): ~33,000 req/s
>> 
>> which is an unfair comparison. Seen from a browser's point of view, it uses 6 connections for HTTP/1.1, but only a single one for HTTP/2. With that in mind, the following is better:
>> 
>> h1 (6 conn): ~28,000 req/s
>> h2 (1 conn): ~18,000 req/s
>> 
>> which, I think, is due to:
>> - too much work on the single thread serving the main connection, e.g. polling instead of events
>> - too little reuse of slave connections and bucket beams, running the same setup code for each request
>> 
>> It can also be argued, just as with any benchmark setup, if the results are really relevant. I wanted to measure the improvements in request scheduling on which I worked the last weeks. They are visible, they will not win the war, I like them nevertheless.
> 
> Just so we are seeing apples-to-apples, in the 8 connection case, I
> presume you have
> 8 h2 connections each with 6 parallel requests?  In the http/1.1 case,
> I presume we
> would test 48 parallel requests divided between the 6 different objects?
> 
> You could argue for single, but the most representative
> of-the-real-world comparison
> is probably 2 or 4 concurrent connections, which is the pattern of
> most modern browsers.

Neither. I blast the server with GET requests using h2load. In the h2 case, this will send up to 100 requests in parallel. I want to see how mod_http2 keeps up with this extreme case and what effect scheduling improvements have.

In a real world browser setup, you need to introduce some RTT etc as you well know. I did that using Chrome for Apache Core in Budapest, using the Apache landing page as a sample. Maybe I should revisit that with the current version and examine changes.

-Stefan

Re: mod_http2 v1.10.0

[William A Rowe Jr <wr...@rowe-clan.net>]

On Tue, Apr 4, 2017 at 9:24 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
>
>> Which one is the yellow bar over 6 connections?
>
> It's invisible. I extrapolated. Just ran the tests:
>
> h1 (6 conn): ~28,000 req/s
> h2 (6 conn): ~33,000 req/s
>
> which is an unfair comparison. Seen from a browser's point of view, it uses 6 connections for HTTP/1.1, but only a single one for HTTP/2. With that in mind, the following is better:
>
> h1 (6 conn): ~28,000 req/s
> h2 (1 conn): ~18,000 req/s
>
> which, I think, is due to:
> - too much work on the single thread serving the main connection, e.g. polling instead of events
> - too little reuse of slave connections and bucket beams, running the same setup code for each request
>
> It can also be argued, just as with any benchmark setup, if the results are really relevant. I wanted to measure the improvements in request scheduling on which I worked the last weeks. They are visible, they will not win the war, I like them nevertheless.

Just so we are seeing apples-to-apples, in the 8 connection case, I
presume you have
8 h2 connections each with 6 parallel requests?  In the http/1.1 case,
I presume we
would test 48 parallel requests divided between the 6 different objects?

You could argue for single, but the most representative
of-the-real-world comparison
is probably 2 or 4 concurrent connections, which is the pattern of
most modern browsers.

Re: mod_http2 v1.10.0

[Stefan Eissing <st...@greenbytes.de>]

> Am 04.04.2017 um 16:07 schrieb Jan Ehrhardt <ph...@ehrhardt.nl>:
> 
> Stefan Eissing in gmane.comp.apache.devel (Mon, 3 Apr 2017 13:19:42
> +0200):
>> Hi there,
>> 
>> a new version of mod_http2 has been backported to 2.4.x and there is
>> also a github release, as usual:
>> https://github.com/icing/mod_h2/releases/tag/v1.10.0
>> 
>> I rewrote some key parts of scheduling and slave connection handling for
>> better performance. It shows good results. However it needs more
>> testing than just by myself. If you have a HTTP/2 setup where you can
>> risk it, please give it a try. The github builds against a 2.4.25
>> server, so you do not need to got totally into the unknown. Thanks!
>> 
>> -Stefan
>> 
>> PS. I plan to write a blog about it, but the basic store is in this
>> picture.  This is hammering localhost with a list of 180 urls over and
>> over with h2load. Most interesting are the changes to the green bars.
>> The yellow shows that there is still a large gap between what HTTP/1.1
>> can do on 6 connections compared to HTTP/2 on a single one. But we're
>> getting closer.
> 
> Which one is the yellow bar over 6 connections?

It's invisible. I extrapolated. Just ran the tests:

h1 (6 conn): ~28,000 req/s
h2 (6 conn): ~33,000 req/s

which is an unfair comparison. Seen from a browser's point of view, it uses 6 connections for HTTP/1.1, but only a single one for HTTP/2. With that in mind, the following is better:

h1 (6 conn): ~28,000 req/s
h2 (1 conn): ~18,000 req/s

which, I think, is due to:
- too much work on the single thread serving the main connection, e.g. polling instead of events
- too little reuse of slave connections and bucket beams, running the same setup code for each request

It can also be argued, just as with any benchmark setup, if the results are really relevant. I wanted to measure the improvements in request scheduling on which I worked the last weeks. They are visible, they will not win the war, I like them nevertheless.

-Stefan

Re: mod_http2 v1.10.0

[Jan Ehrhardt <ph...@ehrhardt.nl>]

Stefan Eissing in gmane.comp.apache.devel (Mon, 3 Apr 2017 13:19:42
+0200):
>Hi there,
>
>a new version of mod_http2 has been backported to 2.4.x and there is
>also a github release, as usual:
> https://github.com/icing/mod_h2/releases/tag/v1.10.0
>
>I rewrote some key parts of scheduling and slave connection handling for
>better performance. It shows good results. However it needs more
>testing than just by myself. If you have a HTTP/2 setup where you can
>risk it, please give it a try. The github builds against a 2.4.25
>server, so you do not need to got totally into the unknown. Thanks!
>
>-Stefan
>
>PS. I plan to write a blog about it, but the basic store is in this
>picture.  This is hammering localhost with a list of 180 urls over and
>over with h2load. Most interesting are the changes to the green bars.
>The yellow shows that there is still a large gap between what HTTP/1.1
>can do on 6 connections compared to HTTP/2 on a single one. But we're
>getting closer.

Which one is the yellow bar over 6 connections?
-- 
Jan