> Am 04.04.2017 um 16:29 schrieb William A Rowe Jr <[email protected]>: > > On Tue, Apr 4, 2017 at 9:24 AM, Stefan Eissing > <[email protected]> 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
