> Am 04.04.2017 um 16:07 schrieb Jan Ehrhardt <[email protected]>: > > 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
