1

I am using Tomcat 8.5.29 and using the respective configuration, i have enabled the HTTP2 support for the site. Below is the configuration in server.xml file.

<Connector port="443" protocol="org.apache.coyote.http11.Http11AprProtocol"
           maxThreads="150" SSLEnabled="true" 
           compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json" compression="on" compressionMinSize="1024"
           >
    <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
    <SSLHostConfig>
        <Certificate certificateKeyFile="conf/localhost-key.pem"
                     certificateFile="conf/localhost-cert.pem"
                     certificateChainFile="conf/cacert.pem"
                     type="RSA" />
    </SSLHostConfig>
</Connector>

When i tried to compare the page load time for the site which is supporting HTTPS 1.1 and HTTP2, it is not consistent. Sometime it is taking more time to load and sometime it is taking less time to load compare to HTTPS 1.1.

To measure the page load time i am using httpwatch.

I am looking for information on

A) Which are the tools can be used to measure the performance enhancement using http2 ? Our is not public website so cant use the some of the tool available online.

B) Are there any other configuration needs to be done apart from enabling the HTTP2 in tomcat to get the better result ?

Regards,

Murtuza Talwari
  • 21
  • 1

1 Answers1

2

HTTP/2 aims to address some inefficiencies of loading many resources over HTTP by changing to a binary format with multiplexing.

Under HTTP/1, requesting many resources over a high latency, long distant network (as much of the Internet is) means downloading website assets are slower than they need to be. This is because each HTTP/1.1 connection can only handle one resource at a time and cannot use that connection to handle another request while it’s waiting around for the first to be sent back.

So for your use case I am presuming this is on an intranet and the servers are probably located quite close to you with high speed links to them? If so HTTP/2 is unlikely to give you a huge performance boost to be honest, as the resources will likely be sent back quite quickly anyway. So I am not surprised that you are not seeing improvements for this scenario.

Additionally downloading multiple assets is only one part of using a website. If the website requires a lot of server side processing to produce then the downloading side (which HTTP/2 should improve) may be such a small part of the load time that it might be negligible and even drastic improvements to that might be unnoticeable. Similarly if the website is slow even after downloading (because it uses a tonne of JavaScript for example) then that’s not going to be fixed by moving to HTTP/2.

To me HTTP/2 makes more sense for serving static resources (images, CSS and JavaScript) than dynamic resources from an application server (Java based or otherwise) so I’m not convinced there is a real pressing need for HTTP/2 on Tomcat and the like. Even if you are using Tomcat to serve static resources you’re probably better sticking a faster HTTP/2 webserver (Apache, Nginx) in front of it and offloading them to that and only proxying genuinely dynamic content on to Tomcat.

So while HTTP/2 is a great improvement to the protocol (for most cases), it is not a magic fix to make your site 10 times faster. Saying that HTTP/2 is the future IMHO so there is little reason not to move to it (the primary one being lack of support of HTTP/2 in many implementations - especially if running older versions of server software, but you’ve already solved that issue).

Anyway, back to your question: The easiest way I would suggest would be to use developer tools in browser to see how long it takes to load he site with and without HTTP/2 - that’s ultimately what your users are experiencing. If you can do this programmatically (e.g. record the time taken to fully load the page with JavaScript and report that back some how) to allow for larger scale analysis then so much the better. This takes a bit more setup than running something like Apache’s ab tool or the like, but those won’t triply measure the improvements due to HTTP/2 if they are only downloading the main page and not the resources, and also won’t measure the whole load time the user experiences.

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • Barry, reading your answer I got the impression that you are suggesting to remain on HTTP/1.1, unless you hit the sweet spot of HTTP/2. I am of a different opinion: move to HTTP/2 because it is as good as HTTP/1.1 in the worst case, and way better in its sweet spot. I see no reason to stay on a 20+ years old protocol when you have an alternative that is as good or better. Stronger encryption, less resource usage, potential to scale better, potential to hit the sweet spot, consistent protocol along the whole chain, no wasteful transformations to/from HTTP/1.1. – sbordet Apr 13 '18 at 13:41
  • I didn't mean to give that impression, I just don't think for certain use cases (like this one) there is often not a huge benefit and wanted to set appropriate expectations. You are right that, on the whole, there are no downsides to moving and HTTP/2 should be as good if not better (except in some edge cases). – Barry Pollard Apr 13 '18 at 13:57
  • 1
    Saying that I disagree it gives stronger encryption (it enforces strong encryption, that can also be used under HTTP/1), less resource use is arguable (processing binary formats is easier and less error prone but HPACK for example can add complexity), scaling is arguable and using the same protocol along the whole chain and avoiding wasteful transformations is very arguable since they are usually independent connections. HTTP/2 is good, I like HTTP/2 (so much so I'm writing a book on the subject!) but it's also at risk of being over hyped IMHO. People need to realise what it will and won't do. – Barry Pollard Apr 13 '18 at 14:01
  • That HTTP/2 enforces stronger encryption is a good thing over HTTP/1.1. Less resources is not arguable: less connections per client by a factor 6/8, having implemented both HPACK and HTTP/1.1 header parsing I can tell you that the complexity of HPACK is way less than parsing and covering all the edge cases of HTTP/1.1 header parsing. Avoiding transformations to/from HTTP/1.1 is not arguable: in full HTTP/2 the proxy just have to forward the bytes, in the other case it has to de/re-HPACK and re/de-construct HTTP/1.1. We have customers that move to HTTP/2 because of less resource consumption. – sbordet Apr 13 '18 at 22:29
  • Ok I totally agree there are less resources to maintain due to less connections - sorry didn’t realise that’s what you were talking about. And we’re not ready to drop HTTP/1 so do need to implement both for now (for ever?). And it sounds like you are talking about having a level 4 load balancer/reverse proxy for your HTTP/2 setup? That is less transformations but can also be done with HTTP/1 no? Regardless of all of this I was trying to answer the OPs observations and explain what they were seeing and set up their expectations. I honestly don’t expect a huge performance gain for his scenario. – Barry Pollard Apr 14 '18 at 06:31
  • Thanks Barry/Sbordet for the details. To check further i moved site from intranet to internet and carried out the test.After that also when i check page load time with chrome developer tools, load time for http2 site was higher than http1 site. We are using the file concatenate. While reading further there was different opinions about use the file concatenate with http2. Another observation with file concatenate is, with http2 size of concatenate file is more than size of concatenate file with http1 but there is no content difference. – Murtuza Talwari May 07 '18 at 08:46
  • Not sure why size is higher with http2 and was it one of the reason of slow page download ? – Murtuza Talwari May 07 '18 at 08:46
  • If anything the size should be smaller with HTTP/2 as headers shouldn't duplicate (though the payload size will be the same). Do you have a public site I can have a look at to see if I can spot anything further? – Barry Pollard May 07 '18 at 08:50