Hi,
we have done a bit more testing in a proper isolated perf environment using
a Java application (added to the same repo) [1]:


JDK Java HTTP/1.1: 3166.41 / 10 = 316.641 ± 64.438 ms
JDK Java HTTP/2: 3008.88 / 10 = 300.888 ± 34.369 ms
Apache HTTP/1.1: 10916.22 / 10 = 1091.622 ± 354.572 ms
Apache HTTP/2: 5612.91 / 10 = 561.291 ± 76.835 ms

JDK Java was 5.23% improvement
Apache was 94.48% improvement

$ uname -a
Linux burtha-f31 5.8.17-100.fc31.x86_64 #1 SMP Thu Oct 29 18:58:48 UTC
2020 x86_64 x86_64 x86_64 GNU/Linux
$ java -version
openjdk version "11.0.9" 2020-10-20
OpenJDK Runtime Environment 18.9 (build 11.0.9+11)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.9+11, mixed mode, sharing)
$
Intel(R) Core(TM) i7 CPU       X 990  @ 3.47GHz

For the plain queries there was a small 5% improvement, in the Apache
implementation it looks like there is much higher difference. The times
between JDK and Apache implementation cannot be compared directly as the
Apache implementation reads strings in a handler. I have no idea, why I got
so crazy numbers  when testing on my laptop, but these numbers look
reasonable (although running the same scripts on my laptop I'm getting
again much higher performance improvements with HTTP/2).

Re server push: Probably some smart logic might be implemented in a server
as already mentioned. Pushing checksums should be also easy.

Kuba


[1]: https://github.com/jbartece/http2performance/tree/main/httpMetrics

On Mon, Nov 9, 2020 at 6:30 PM Benjamin Marwell <[email protected]> wrote:

> Hi Michael,
>
> I do not think it is necessary to download ALL of them serially. H2
> Server push might become a big advantage as already mentioned.
> e.g. if requesting a pom, it might push the jar and its dependencies
> right away with it.
> THAT would probably save a lot of connections (and time).
>
> The only problem is that we would need server support for this (h2 push)
> first.
>
> Am Mo., 9. Nov. 2020 um 16:35 Uhr schrieb Michael Osipov <
> [email protected]>:
> >
> > Am 2020-11-05 um 16:49 schrieb Jakub Bartecek:
> > > Hi,
> > > I did a performance test of HTTP/2 and its comparison with HTTP/1.1
> and I
> > > would like to share my results with you.
> > >
> > > I wrote a Python script [1] to download 100 artifacts in parallel using
> > > asynchronous HTTP client supporting both HTTP/1.1 and HTTP/2. I chose
> 100
> > > artifacts [2] from Maven Central, which were downloaded when I did a
> clean
> > > build of one of my projects.
> > >
> > > All 100 artifacts were downloaded using HTTP/1.1 and also HTTP/2 and I
> > > stored the results in this file [3]. I did 10 experiments and measured
> its
> > > performance. In the middle I switch the order of HTTP/1.1 and HTTP/2
> > > requests to avoid a possible bias. I run it from my laptop connected
> to 160
> > > Mbit/s network.
> > >
> > > The experiments showed massive performance improvements when using
> HTTP/2
> > > instead of HTTP/1.1
> > > *:*
> > >
> > >     - *The average download time using HTTP/1.1 was 3753.7 ms and using
> > >     HTTP/2 971.8 ms* [4]
> > >
> > >
> > >     - *In average the artifacts were downloaded 3.86 times faster using
> > >     HTTP/2 than using HTTP/1.1* [5]
> > >
> > >
> > > Kuba
> > >
> > > [1]:
> https://github.com/jbartece/http2performance/blob/main/http2PerfTest.py
> > > [2]:
> https://github.com/jbartece/http2performance/blob/main/centralUrls.txt
> > > [3]:
> https://github.com/jbartece/http2performance/blob/main/testResults.txt
> > > [4]:
> > >
> https://github.com/jbartece/http2performance/blob/main/finalResults.txt#L26
> > > [5]:
> > >
> https://github.com/jbartece/http2performance/blob/main/finalResults.txt#L32
> >
> > This testing is logically wrong/incomplete. You have to download
> > serially maven-metadata.xml, its checksum files, POM, its checkfiles and
> > artifact itself and its checksum files. Please redo, I would to to test
> > this too then. Enable HttpClient debug logging to see that more than
> > just the JAR is downloaded.
> >
> > Michael
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to