Some http2 headaches.

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 (Hyper Text Transport Protocol) was sitting at version 1.1 since the late 90’s for a reason. It worked. It served data in a simple and secure fashion. Full stop and done! In fact 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 javascripts and other third party resources. Just look at all of the data YouTube is pushing around and you can see why Google really 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 really 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 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

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 isntall the FPM version of PHP 7.0

apt-get update
apt-get install php7.0-fpm

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 PHP7.0-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 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? 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 = 8
pm.min_spare_servers = 1
pm.max_spare_servers = 12

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.

Related Blogs:

SSL for bloggers and why it’s so important.

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.

Leave a Comment to the Void