Nicole of Bitten By the Travel Bug has reported some issues with her WordPress install but is unsure as to what is breaking. The only message she sees is;
Error establishing a database connection
So into the terminal I dive, ssh-ing into the server it's time to probe logs and run diagnostics.
This takes a while as I soon find out from htop
that 100% CPU being used up by Apache, all RAM and swap is being used too. How is this server even functioning at this point?
Apache
Got to stop Apache from taking over
/etc/init.d/apache2 stop
Once that's done I check out /var/log/error.log
for any recurring themes. I find mostly timeouts, a few mysql database connection errors and horribly coded WordPress plugins breaking. Those will be the first to go when the purge comes along.
Just to be careful, I run last
and cat /var/log/auth.log | grep "invalid user" | wc -l
to see if there has been anyone logging in. (Only 1302 attempts today, not bad)
Since this is a small Digital Ocean droplet I'm going to aggressively limit Apache to allow the site to function but not overload the server.
<IfModule mpm_prefork_module>
StartServers 1
MinSpareServers 2
MaxSpareServers 5
MaxRequestWorkers 50
MaxConnectionsPerChild 1000
</IfModule>
And install fail2ban even though the only enabled method of ssh authentication is keys.
apt-get install fail2ban
Plugins
WordPress is known for being extensible via plugins, unfortunately these plugins had no peer review or standards to be held to. I have found many plugins which use file_get_contents
on a long expired domain for whatever reason, leading to an extra 30 seconds of load time.
Plugins can cause trouble, but not all of them are bad. tail
-ing error logs to find troublesome plugins makes it easy to identify some, while others need to be disabled through trial and error.
Originally Bitten By the Travel Bug had 33 active plugins, I was able to bring it down to 20, at least 5 of which I believe should not be plugins and should be part of the theme, but that's a job for another day.
Images
Uploading 5mb images and letting WordPress create thumbnails is a good idea in theory, but the WP core doesn't optimise the files for slow connections.
Here is where jpegoptim
saves the day. Optimising jpeg files through the command line saves hard drive space and gives the end user less to download for an imperceptible loss of quality.
1 command and the uploads directory has been reduced by over half. And more can be saved by tweaking the output quality.
$ cd /wp-content/uploads/
$ du -s
754492 .
$ find . -regextype sed -regex ".*/*.jp[e]\?g$" -exec jpegoptim --all-progressive -o -m90 --strip-all {} \;
$ du -s
361112 .