Sitting on the bleeding edge with HTTP2 protocols.
HTTP2 has been enabled shortly after we purchased an SSL connection. Since we were already running encryption on our blog then why not take advantage of another method that will speed up the site? This blog will continue to be enabled until a better transport protocol comes out or until the entire internet drops out of existence and will just be remembered as an uncomfortable fad throughout human history. For those who care about some of the nerdier side of what this blogger does then please continue reading.
What is this HTTP2 insanity?!?
For the longest time, the HTTP (HyperText Transport Protocol) was sitting at version 1.1 since the late 90's for a reason. It worked. It served data simply and securely. Full stop and done! If your browser cannot support the latest standards then our Apache server will serve this very page to you with http/1.1. This new protocol was developed by Google using its first incarnation of "Speedy" or "SPDY" where if it kept that name then you would be coming to this site via "spdy://www.s-config.com." The reason why Google developed this is because the current model of how the web is being displayed to you is getting cumbersome in a world where each site loads at least 10 javascript and other third party resources. Just look at all of the data YouTube is pushing around and you can see why Google needed this to be a thing. You know what? Perhaps they should have kept the name and here is why. The way http2 or http/2.0 works is it takes all of the data it can on the initial page, compresses it and burst packet sends it over to your browser. Any images or additional resources the website would need would be multiplexed over to the client instead of synchronous transfer. Waiting for the call to load and the acknowledge for completion like http/1.1. But here's the problem with calling it HTTP. It's not text anymore. Not really! It's a website that has been compressed into a binary and fired over to you the client. So, in reality, it should be called HBTP or (Hyper Binary Transport Protocol). Doesn't roll off the tongue now does it? but oh well.
Initial setup.
First off, most shared hosting packages don't like playing with this protocol. The reason being is HTTP2 is extremely unstable and bleeding-edge despite being released almost five years ago and a lot of mainstream sites began using it about two years ago. So this means that the only people who can get away with it are people with virtual servers that govern over their apache configuration which it so happens we do! The first thing you're going to want to do is legit HAVE apache 2.4.18 or better. After you've installed apache onto your distro you'll need to activate the module.
sudo a2enmod http2and then going into each of your sites which are vhost'ed like what we do. Go into /etc/apache2/sites-available and nano into your vhost'ed site.such as default.conf. Right after the Server Alias statement we like to add in the following line:
Protocols h2 http/1.1
then
systemctl restart apache2
And that USED to be all you needed. Simply launch chrome and clear out your cache and cookies and the H2 protocol started to load like mad!
Segmentation of PHP.
But then this happened:
apache2 (2.4.25-3+deb9u5) stretch; urgency=medium
* This package upgrades mod_http2 to the version from apache2 2.4.33. This
fixes a lot of bugs and some security issues, but it also removes the
support for using HTTP/2 when running with mpm_prefork. HTTP/2 support
is only provided when running with mpm_event or mpm_worker.In the name of security, Apache kicks HTTP/2 to the curb. Awesome! It took a little bit of doing to bring it back for Debian but we eventually did. first, we stop Apache.
systemctl stop apache2
next, we install whatever version of PHP you are running with, in this example, it's 7.0.
apt-get update apt-get install php7.0-fpm
While we're at it it's probably a damned good idea to update the dependency libraries in case you are upgrading to a newer version of PHP like 7.1, 7.2, etc.
apt-get install php7.0-mysql libapache2-mod-php7.0 php7.0-cli php7.0-cgi php7.0-gd php7.0-zip php7.0-intl php7.0-mbstring
enable a proxy mod that will help us with HTTP/2
a2enmod proxy_fcgi setenvif
disable the old PHP7.0.
a2dismod php7.0
Disable the MPM-prefork which was dependent on PHP7.0.
a2dismod mpm_prefork
Enable PHP.x-fpm which the FPM stands for (FastCGI Process Manager)
a2enconf php7.0-fpm
Enable MPM-Event which is a different style of multi-processing apache and http2 will use. you can also try MPM-worker too but I stuck with the event.
a2enmod mpm_event
Finally, you can startup Apache to get http2 back up and running.
systemctl restart apache2
And you'd think that all of your troubles are solved at that point right? Hahaha! Nope!
Website lock up!
Initially, when I enabled http2 on my apache box I would have momentary points where it would take 3 minutes to log in to the WordPress site but all of the other browsers that weren't logged in were fine. I just thought it was a bug and didn't think much of it. However, with php7.0-fpm the problem escalated quickly to where if someone accesses the page and fills up all of the threads the entire site shuts down like it's in the middle of being DDOS'ed to death. However, we know that our Apache was still running because default websites by resolving IP addresses come up perfectly fine because those sites do not refer to any PHP action. Also, my WordPress site wouldn't allow the uploading of images past 2Mb in size. It's completely ignoring the php.ini that we set up initially for apache2. Fuck. the FPM version of php7.0 uses the ini in /etc/php/7.0/fpm/php.ini and it gets annoying. Because once you define a parameter in php.ini you cannot override it by simply stating a new value at the bottom. you got to hunt for each of these lines and replace them.
upload_max_filesize = 300M post_max_size = 300M memory_limit = 256M max_execution_time = 600 max_input_vars = 10000 max_input_time = 400
Sweet, we've given PHP more ram to play with and now we can upload some worthwhile videos to my blog again.
Crash and burn - Website lockup!
But in the last few days, my site has been locking up in under five minutes. Well checking the /var/log/php-7.0-fpm.log revealed this:
[30-Jul-2018 01:55:22] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
That warning was more serious with HTTP2 enabled. It's locking up because there are simply no more threads left to process my site. To fix this mess I had to go into /etc/php/7.0/fpm/pool.d/www.conf and change the following:
pm.max_children = 50 pm.start_servers = 5 pm.min_spare_servers = 5 pm.max_spare_servers = 10 pm.process_idle_timeout = 10s pm.max_requests = 500
Now did I go a little overkill? Perhaps. But now my box can ramp up 50 threads if required to process things. The lock-ups and website timeouts are gone. I should note that http1.1 hardly used any processing power at all on my VPS versus the HTTP/2 protocol which is eating anywhere from 5 to 10 percent of one of our 2.8Ghz Xeon Cores. Still not bad! But almost a cautionary tale for people who do get a lot of readers onto their site. We also activated the process time-out so that if the website is not doing anything then it will slowly kill off some of the extra PHP processes.
Final thoughts.
I should probably keep this as a running blog at HTTP/2 or http2 however you label it still has a lot of issues it needs to work out. It's understandable as to why data-providers do not even want to touch this protocol which is because of events like the ones described above. Where all it takes is a distro branch split and next thing you know you're http2 is disabled in the best-case scenario. Or your site is completely broken in the worst-case scenario. We hope you have found this information useful. and until next time. +++END OF LINE.