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?!?
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 really roll off the tongue now does it? but oh well.
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 own apache configuration which it so happens we do!
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 http2
and 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
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.
Disable the mpm-prefork which was dependent on PHP7.0.
Enable PHPx.x-fpm which the FPM stands for (FastCGI Process Manager)
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 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? Hahahah! 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 login 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 address 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. Apparently it’s completely ignoring the php.ini that we setup initially for apache2. Fuck.
the FPM version of php7.0 uses the ini in /etc/php/7.0/fpm/php.ini and it gets really 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 actually upload some worth while videos to my blog again..
Crash and burn – Website lockup!
But 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 actually more serious with HTTP2 enabled. It’s basically locking up because there’s 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.
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.