I am currently running an Apache server with HTTP/2 enabled as a reverse proxy for my web application. I have noticed a significant slowdown when requesting a large number of small thumbnails (each approximately 60KB) through this configuration. Strangely, this slowdown started to occur after switching from HTTP/1.1 to HTTP/2, even though HTTP/2 is supposed to improve performance(especially in this case, as requesting many small files is a great use case for all the fancy multiplexing stuff HTTP/2 does).
-
When requesting images sequentially I haven't noticed a slowdown, but only when the client files a lot of files at once (about 200).
-
The bakend only talks HTTP/1.1 and is accessible using the reverse proxy. The thumbnails are precached on the disk.
Here is Chromium's waterfall graph for HTTP/2:
Waterfall HTTP/2
And for HTTP/1.1:
Waterfall HTTP 1.1
As you can see in the images the HTTP/2 requests are no longer stalling, but the overall time increased.
Any pointers or Tips how to further debug this would be great
Best Answer
(This should be a comment - but space limited)
1.) The first place to look when a service is not behaving as expected is in the logs. But the default log formats do not capture useful timing information - you should add at least %D on httpd
2.) I love Apache httpd as an origin server, but it's a less than ideal as a reverse proxy
3.) When asking for help about software not working as intended it is a good idea to provide the version information and the details of how it is configured
4.) What you've shown us looks more like something conforming to HTTP/1.1's limit on concurrent requests than something slowing down (but I've not seen this behaviour from mod_proxy)