You are on page 1of 74

Fast WordPress Websites

- get the most out of your WordPress hosting.

By Scott Farrell
Copyright 2017 By Scott Farrell
All rights reserved. No part of this publication may be
reproduced, distributed, or transmitted in any form or by
any means, including photocopying, recording, or other
electronic or mechanical methods, without the prior written
permission of the publisher, except in the case of brief
quotations embodied in critical reviews and certain other
noncommercial uses permitted by copyright law. For
permission requests, write to the publisher, addressed
Attention: Permissions Coordinator, at the address below.

scott@wpdone.com.au
www.wpdone.com.au

Ordering Information:
Quantity sales. Special discounts are available on quantity
purchases by corporations, associations, and others. For
details, contact the publisher at the address above.

Printed in Australia

Publishers Cataloging-in-Publication data


Farrell, Scott.
Fast WordPress Websites: get the most out of your
WordPress hosting / Scott Farrell.
p. cm.
ISBN-13: 978-1547151622

First Printing 2017

First Edition
Table of Contents
Introduction 4
Chapter 1. The Need 6
Chapter 2. Performance Analysis 12
Chapter 3. Fixing Macro Performance Issues 25
Chapter 4. Fixing Micro Performance Issues 34
Chapter 5. WooCommerce Optimization 57
Chapter 6. Scaling WordPress 58
Chapter 7. The Ultimate WordPress Hosting Stack 60
Chapter 8. Whats Next? 65
Chapter 9. Hosting Recipes 66
Chapter 10. Php-fpm Memory Usage 68
Chapter 11. Case Study 69
Introduction
I wrote this book for a number of reasons. First of all, making a WordPress
website fast is a big, complex subject. There is a lot of confusion, mixed
messages, and deception out there. I also really love working with WordPress
hosting as well as helping customers and agencies.
There is a bunch of really poor hosting out there. How do I explain why certain
hosting is poor? By going into some detail about what good hosting looks like.
Plus, you need to be able to critically analyze the hosting that you are using to
work out whether its appropriate.
I also see many people upgrading from shared hosting to VPS hosting, but for
most people, this is an out of the frying pan and into the fire situation. VPS
hosting results in more complexity, time, risk, and problems.
Some areas of complexity are what brand of hosting youre using, what type of
hosting youre using, the software, the hardware, the versions of php, which
web server you use, and how the MySql database affects the speed. There are
also plugins, themes, caching, and CDNs to consider.
The complexity also interacts with itself. Now, there are plenty of Band-Aid
approacheslike slapping on pluginsbut people often use the wrong tools to
test WordPress website performance.
Yes, another obvious reason for writing this book is to generate business. It
shows that Im serious about hosting and can lend some valuable insight to any
hosting decisions you might have.
About My Business
I run www.wpdone.com.au. It is WordPress hosting done right, done fast, and
done securely.
Wpdone works with professional agencies in Australia to provide premium
hosting without the sysadmin headaches. We use a revenue-sharing model that
helps to deliver premium services to your clients while allowing you to put
more money in your pocket than you do now. You spend less time yourself, less
staff time, and fewer support phone calls from your clientswe just send you
a direct debit each month.
We do a better job than the big names in hosting. This book will help you better
understand your needs, what your current provider is delivering, and how you
can do better.
We do our hosting here in Australia to better support your business and your
clients businesses.
We also operate a Virtual CTO program to help those with hosting scenarios
that dont exactly fit our main hosting. If youre offshore or want to stay with
your provider but want access to our leadership, deep skills, and intellectual
property, we can help: https://www.wpdone.com.au/virtual-cto/.
Chapter 1. The Need
Why should you consider the performance of your WordPress site?

Sometimes its painfully obvious that something needs to be fixed, while at


other times it might be less obvious.

PCs and Tablets Are Faster

When PCs were slow, people were used to waiting for websites.
However, PCs are getting faster every day, so users notice a slow website
when they see it. Having a slow website is the same as having old or faded
paint on your storefront.
A website that was fast enough a few years ago probably isnt fast enough by
todays standards.

The Internet Is Getting Faster


This is of particular interest to Aussies but also other countries where the
Internet has become a political pawn, and we poor citizens must take the brunt
in the form of bad Internet. #HopsOffSoapBox
When everyones Internet is slow, a slow web page can be expected.
As more and more people get onto cable or NBN, its easier for more people
to spot a slow webpage a mile away. Ever click on a search result from
Google and it didnt load fast enough? You probably just click back and try the
next result on Google like me, right?
From a tech perspective, the ping/response time of the Internet to local Aussie
sites has dropped from 30ms to 50ms with ADSL 1 & 2 to 10ms to 20ms with
cable and then down to 2ms with NBN. Yeah, thats rightIm writing using
NBN with 2ms to Google (ping 8.8.8.8).
A wise move would be to get your website NBN ready and get your
WordPress performance up to spec.

Hosting Companies Dont Upgrade You


Most people know that computers are getting faster; they bring out newer and
faster servers all the time.
What most folks dont know is that software is innovated and changes even
faster. Whereas a server from two years ago might be 30% slower, software
from two years ago is likely to be 200% slower!
On most plans, when you purchase the first site/plan/widget, youre stuck with
that tech, which includes hardware and software.
Many hosting plans sold two to five years ago havent kept pace with
technology. The hosting companies business plan is to simply drop your
WordPress site on a given server and bill you every monthforever. Theyll
do as little maintenance as possiblejust enough to keep things runningin
order to bill you. Upgrading new hardware and software isnt even on their
radar. Therefore, a good choice a few years ago turns into a poor choice (or
non-choice) today.
So if your plan is the same as it was a few years ago, your tech is likely to be
aged, which affects your performance.
What can you do about this? Read onand if youre impatient, jump to
analysis so you can better understand the tech youre using.

Google SEO
Okay, I know that some people might want to argue this one.
Google SEO is to some extent a secret and not completely knowable. Its also
difficult to understand the extent to which the performance of your website
impacts your SEO rankings.
However, few will argue that website response speed is an indicator for
Google SEO.
Some of you dont pay for SEM/AdWords or an SEO consultant (Ahhpaying
monthly for SEO magicanother pet peeve of mine). For those of you who do,
a little more attention paid to performance can sometimes save money as a
result of better SEO ranking.

A lot of SEO is guessing. This one is documented by Google:


weve decided to take site speed into account in our search
rankings. Source:
https://googlewebmastercentral.blogspot.com.au/2010/04/using-
site-speed-in-web-search-ranking.html
The faster your page, the better your search engine ranking. Id say that fact
alone is enough to pay for faster hosting
Regardless, when it comes to the customer, they wont be sticking around to
watch your website crawl slowly onto their screen. As a result, they leave
early, increasing your bounce rate. Not many people know that bounce rate is
the biggest SEO factor. Google watches if someone quickly clicks back, and
clicks on another search result, and as such Google monitors the bounce rate of
pages.
So bottom line: slow hosting is losing you sales through increased bounce rates
and reduced SEO ranking..

Conversion Rates
There are a few documents floating around about how your websites
performance relates to conversion rates.
If youre selling on your website, or even just collecting leads, the
performance on your site will have a direct impact on your conversion rate.

Reduced Web Sales


Now, if youre selling on the web, you seriously need to look into the speed of
your WordPress web hosting.
Roughly every additional one second in page load time equates to a 7%
eCommerce sales loss.

Say your website is loading in seven seconds; over a year, youll have lost
15%35% of your eCommerce sales. That is a simple business decision for an
eCommerce website to move to faster hosting.

Slow Pages Are Just Downright Frustrating


This infographic shows the whole slew of issues that can arise from poorly
performing websites.
Your bounce rates will also increase; people simple cant be bothered with
slow sites.

Delight Customers
This is a straight marketing concept. I remember hearing about it when studying
for my masters in management. I think it was Drucker, but I could be wrong.
The concept is to exceed your customers expectations. Dont merely have a
good enough website; make sure it delights everyone who uses it.
Google ZMOT (zero moment of truth) says that customers have already made
up their minds before they enter your real store. They are checking out you and
competitors online, so make sure your first impression is good. Read more
about ZMOT here: https://www.thinkwithgoogle.com/collections/zero-
moment-truth.html.

You can read more about customer delight here:


https://en.wikipedia.org/wiki/Customer_delight.
Chapter 2. Performance Analysis

Before you jump headlong into fixing your WordPress performance, take a
moment to take stock of where youre at.
I see loads of folks spending their weekends adding this or that plugin. Why a
weekend? Because adding stuff to your site causes other stuff to break, so then
you need a support call. Then you need to learn that tech a bit to get your
WordPress site working again (even if its just a plugin), but you also have to
go out to dinner with friends and see your childs play. Before you know it, you
didnt get the mowing done and its Sunday evening, but your website is a bit
fasterjust not as much as you expected.
That weekend would have been better spent with a little more analysis and
planning rather than semi-random plugins and changes.
This whole performance and analysis concept is complicated, and Ill try to
stop you from going down the rabbit hole. You need to take a broad look at
whats going onas well as at your optionsbefore you dive into the
minutiae.
Im breaking the rest of the ebook into a few sections.
- Analysis Steps 3 Major Things You Need to Review:
- Server Response
- On-page Performance
- Server Tech Level
- Macro Changes Changes Outside of WordPress and the Server
- Micro Changes Changes Within WordPress or Its Server
Basically, you need to make sure you have some idea of whats going on with
your site. Then you need to consider the bigger questions. Once you have the
basics down, we can dive into the details of the tech.
Preamble of Terms

In order to keep the conversation straight and the analysis easy to understand,
Ill define a few terms to help us move forward.
Server response: This is the time it takes the server to return the WordPress
html page. This is a measure of the technology on the server and its capability
to generate pages.

On-page performance: This concerns how many assets are on the page.
Assets can be images, javascripts, sliders, css, etc. The more assets you have,
the slower the page will load.
On-page performance can affect a few different things. Most notably, it causes
the browser to make more requests to the web server. It also causes more
thinking time on the browser, so the slower the browser/tablet/phone, the
slower the page will appear.

Server tech level: This includes things like your php version, caching design,
php handler, CPU, and memory. Basically, this concerns the hardware and
software running your site.

WordPress Hosting Performance Check Plugin


Okay, Im giving myself a plug for my own plugin:
https://wordpress.org/plugins/wp-hosting-performance-check/.
My plugin is a great place to start when you are trying to understand your
WordPress website performance. It will help you with both an overview and
some detail. Its free and takes very little expertise to install and get going.
The plugin will give you a handle on the three major areas you need to concern
yourself with:
- Server response time
- On-page performance
- Server technology level
Youll get cute little graphs like this, which make it clear how youre doing in
each category.

The plugin will also graph the results over time so that you can observe the
consistency of your WordPress website performance.
Ever notice that your site seems to perform fine when you check but other
people later comment that its slow? As though gremlins are secretly getting in
to make it slower?

Its often difficult to know how your WordPress website is performing and
how real end users are experiencing the performance of your WordPress
website.

This plugin will display graphs of the performance of the server (so youll be
able to see what those pesky gremlins are doing). It also tracks the
performance of the webpage load speed, which includes all the assets: jpg,
png,css,js, etc.

Youll be able to view graphs for different periods of time, to see how your
server has been performing, and to see how real-world users are observing the
performance of your WordPress site.

Youll also be able to observe when the server is sluggish and when it is fast.

Many of you may be using pingdom, gmetrix, yslow, etc. These tools are good,
but I do have a few issues with them:

- Firstly, they mix up the results from server response time and on-page
performance.
- Secondly, they are an artificial test while you are sitting there looking at the
site, at a single point in time, while you know its going well. You need results
over a period of time in order to observe the site when you havent pre-clicked
and pre-cached the site.
Benchmarking
Its important to know where you are in terms of your websites current
performanceand to have some way of knowing how well your changes are
helping.
My plugin can help with that. It records the real performance of your
WordPress website for 90 days. That way, if you add Plugin X today, you can
compare its performance to last week very easily.
You can also compare your results with others and even compare to other
hosting companieswithout having to actually move your site.

Web Server Performance

We need to work out how the hosting server you have stacks up against the
competition. We can try all the tricks in the world, but if the server is slow,
with poor technology, we cant really fix it. You cant make a purse out of a
sows ear.
In some instances, you can upgrade your server, or if its a VPS, you can
upgrade some of the software stack. However, its more often than not time to
rethink your hosting needs.
If youre using my plugin, look for a few things.
First, check out the Hosting Check page, where you will want to review the
column headed Server response time. That shows how well the server is
responding to the WordPress page requests.
Ideally, you want to be under one second; thats reasonably easy with modern
hardware and software.
The second thing to look at in my plugin is to see if over the course of a day,
there isnt too much variation in the web server response. Or, when you look at
the tally area (the horizontal bars), not too many of them are orange or red.
If youd like, here is a client of ours: https://artilux.com.au. They have a great
site (and if you struggle with mosquitos, they can help you out). Here are some
of their graph results. How does that look for consistentand under one
second?
Webpagetest.org is also great. Do a test from Australia and you can look at the
overall result, but the main thing youre interested in for this analysis is the
TTFB (time to first byte). Here are my recommended settings.

Here are the results. There are other important numbers, but for now, were
just interested in the TTFB.
There are a whole bunch of factors that make up TTFB, and these will be
addressed later. For now, were just interested in the time being under one
second. Over two seconds is really, really bad. Ive seen poor hosting with as
much as 20 seconds TTFB.
Daily Process Log Report
This is a great report in WHM/Cpanel. Search for daily in the WHM menu.
The report is broken into two parts. The top part ranks the highest CPU users
of your VPS. This is great to know as it gives you some areas to focus on. It
also helps because as you speed up your server, these numbers should drop.
The lower portion of the report is about processesit is a bit more fine-
grained. However, from here, you can see individual high CPU usages. This
will sometimes show slow long-running processes. It might show up that
youre using CGI instead of fpm (more on that later). Anything over 80% is a
target for review.

New Relic Graphing of Server Performance


I really like New Relic. Its a great product, and you can visually see the
performance of your serverplus the first level is free!
You can get graphs of overall server performance broken down into php time
and mySQL time.
Additionally, you can see per site which servers are using CPU and how many
hits they are getting with something like this into .htaccess. It will even roll
up each account/server for you. I have a script that will add this to all sites
(just message me).
<IfModule php5_module>
php_value newrelic.appname "servername;account name;domain.com.au"
</IfModule>
The real benefit of New Relic is that is shows the changes in performance over
time of any tweaks that you make.

Disk Performance
This one is a little tricky. Most users should skip this section, but heavy VPS
users should really focus on this. Trust meits important to you.
Ive written a blog article on it here:
https://www.wpdone.com.au/tool-to-test-vps-disk-performance-are-you-
getting-what-you-paid-for/
Disk performance is a good overall indicator of performance and over-selling
as well as the level of tech.
Even though a good hosting config should never even touch the disk, its a clear
indicator of the strength of your server.
It is harder to test disk performance if youre on shared web hosting, so
perhaps skip this one if you are.
You should only be using hosting with SSD these days.

Database Performance

If your database is slow, your site will also be slow.


Im thinking that I should probably add a database test suite to my plugin.
In the meantime, here is a plugin you can use to evaluate database
performance:
https://wordpress.org/plugins/mywebtonet-performancestats/
Another good way to review mySQL performance is with the top command
from Linux on the consoleand see if mySQL is using more than a few percent
of CPU.
Mysqltuner.pl is also greatsee the section on database optimizing later for
more details on this tool.
Or you can use New Relic, as mentioned above.

WordPress Plugins
As part of the checkup, you need to review your plugin use.
Up to around 20 plugins is reasonable; once you get past 50 plugins, youre
dragging your own performance down. Ive seen sites with more than 100
plugins activated, and its a mess!
Sometimes youve paid someone to build your site for you, and it came with a
bunch of plugins, which means you cant do much about it.
P3-profiler
The P3-profiler plugin is great. It can give you a report on how much each
plugin is dragging your site down as well as the total of how much the plugins
are eating up in CPU usage.
https://wordpress.org/plugins/p3-profiler/
Server Technology

This is more of a list of what is or isnt on your server and how the software
stack on the server is arranged.
If you use my plugin, its incredibly easy. Simply click on the sysinfo tab.
The output is something like this (Yes, its ugly; I need to get a designer to tidy
up the pages.):

PHP version 5.6 is GOOD; below 5.6 is TERRIBLE; PHP 7.0 or


HHVM is GREAT.
PHP Version: 7.0.11

You want to have an FPM handler; everything else is rubbish.


PHP Handler: fpm-fcgi

You need version 5.6 or above here:


MySQL Version: 5.6.33-log
Keepalive is another important element. Its a bit old school now, but its
worth checking out. Its a whole complex topic area. Webpagetest.org is the
best test for keepalive IMHO. See my webpagetest results above, and notice
the green A for keepalive. :)
Now, a lot of these are impossible to change if youre on shared web hosting.
If theyre bad, you need to leave that hosting provider. No amount of fancy
plugins is going to save you. If your software stack is bad and outdated, the
hosting provider doesnt care about you, so vote with your wallet.
If youre in a VPS, you can bang your head into a wall while talking to support.
Thats what owning a VPS is all about. Fpm on a VPS with cpanel is still
difficult; it is supported, but you have to do it by hand. Contact me, and Ill dig
out our code that we use for whm/cpanel to enable php-fpm for our customers.

On-page Performance
This is related to how many assets you have on the page and how they are
managed.
Assets can be images, javascript, css, sliders, and other fancy gadgets. The
more you have, the slower everything is.
There are a few knock-on effects of on-page gadgetry:
- The browser has to request more objects from the web server.
- The browser has to spend more bandwidth and time downloading objects.
- All the requests need to be queued through only four connections (assuming
http/1.1).
- This can be exacerbated by the distance from the server (see the discussion
of country later).
- The browser then has to think about and render more images, formatting,
fonts, etc.

The best way to review this is my plugin or by using yslow, pagespeed, and
webpagetest.org reports:
Pagespeed testing can be done here:
https://developers.google.com/speed/pagespeed/insights/

Some people focus heavily on these reports, but its only one part of the
overall picture.
The results from the test are a tad artificial and inaccurate.
The real answer is above the fold page completion, meaning that the first
screen the user sees completes quickly. A page being complete in under five to
seven seconds is the goal.
Measuring above the fold completion is what webpagetest.org measures. I
think webpagetest.org is even more accurate than my plugin. They record
videos of pages loading and stop the clock once the images stop changing. The
only inaccuracy they have is if you have a moving slider or something similar
that skews the results.
Here is my client (https://artilux.com.au) again and their on-page
performance. They have some orange/red bars. Youre going to have a few
slow pages, slow users with slow equipment or poor Internet, or users from
overseas. However, the graphs show that a majority of users are happy.
Chapter 3. Fixing Macro Performance Issues

The aim of this chapter is to consider the issues that are outside your current
solution. Theres no use getting under the hood of your FJ Holden if youre
trying to win a drag raceits probably cheaper and easier to just buy a new
car.

Choose Same Continent Hosting Provider

Why is this important? Back when I was talking about the Internet and
PCs/tablets getting faster, I should have mentioned that the distance between
continents isnt getting any smaller. Data takes time to traverse distance. The
more distance, the longer it takes.
If youve got your WordPress site hosted by a bunch of Americans, then its
takes about 250ms to get to the U.S. and back (a quarter of a second). Given
that were trying to get under one second, thats a big deal. However, it gets
worseyou could pay this cross-continent charge more than once!
As everything in the cloud speeds up, particularly software, the percentage of
the time were waiting for cross continent hosting is becoming a larger
percentage. Back when a reasonable time was three seconds for a page, adding
0.25 seconds (even four to five times) wasnt too big of a deal. But at todays
speeds, 0.25 seconds x4 is a whole secondwhich is how fast we want the
WordPress page delivered.
The next cross-continent issue is DNS. If your DNS is also hosted in the U.S.,
thats another one or two round trips that your customers have to take before
they even reach your site.
Now, this gets even worse if you have a .com site and your customers are in
Australia. Even if you have your hosting in Sydney, you still have to pay the
0.25-second cross-continent tax anyway. This is because the first part of the
DNS lookup is to ask where do I look up the DNS, which for .com is in the
U.S.
There are also issues with HTTPS.
You might think, My site doesnt sell stuff, so I dont need HTTPS. Google
already has a weak signal for https for SEO. More is to come; eventually all
sites will be HTTPS or not on Google.
Firstly, there is some certificate-checking that goes on. This can be solved with
OCS stapling. This is far too technical for this book, but you can see my blog
post on this subject:
https://www.wpdone.com.au/the-hidden-https-slowdown-no-one-knows-
about-adding-1-second-to-wordpress-page-load-times-and-how-to-fix-it/
Secondly, HTTPS almost always requires an extra trip to the web server
before the page request. Again, the details are too technical, but you can see it
in webpagetest.org results.
Here is https://apple.com from Sydney. Granted, this is a worst-case scenario,
with a 301 redirect to the www page, but reallywho types www anymore?
- The first line wastes 1.1 seconds just to second the redirect.
- Line 2 is the certificate check.
- Line 3 is the attempt to get the real page, which still has lots of colors
showing more delays. A total of 1.6 seconds has passed before the page even
attempts to start downloading.

Here is a zoomed-in shot of the first line. You can see time being wasted in
DNS lookup, initial connect, and then a double whammy for the SSL (https)
chat. Thats 4x the intercontinental Internet tax. Overall, the 1.6 seconds is
roughly 7x the wrong continent time tax.

My plugin can also help you with country analysis. You can see your overall
performance or just the performance of Aussie visitors.
Now, Ill address the elephant in the roomCDNs. Many people know about
CDNs, and CDNs promise to make the country problem go away. However,
thats not completely true. A CDN really only helps in everything besides the
first few lines I showed above. CDNs dont help there and sometimes actually
make it worse. A CDN can help the https issue, and cloudflare also does
sometimes. However, its a mixed bagsometimes it helps, and sometimes it
doesnt.
There is occasionally a double whammy when using a CDN (like cloudflare)
and HTTPS. Given that the CDN doesnt cache the main WordPress html page,
it cant speed it up. The CDN must request the page from the origin server
(your real WordPress server). If the CDN also uses https to fetch the page from
WordPress, then the CDN will feel the tax of https connections and certificate
checks, etc. This will show up as an increase in TTFB (time to first byte).
Therefore, youll have https slowdown for both the browser CDN and CDN
origin server, which is the double whammy.
One test you can do is to ping your website. Roughly, under 50ms means you
are in the same continent (I think Perth is roughly 50ms from Sydney). The USA
is about 200250ms away.
Having your website hosted in Australia is a big deal. Fix it now!

Oversubscribed

Okaymost folks know that shared web hosting is always oversubscribed.


When something is oversubscribed, it means that its sold more times than it
actually exists. For example, you sold 50,000 tickets to the football match but
only 40,000 fans can fit in the Sydney cricket ground. Whats worsethey can
only pour about 5,000 beers at halftime.
When a web server is oversubscribed, they sell something like 10,000
websites onto one server. There isnt a limit or specially numbered seats at a
stadium. However, the more they sell into the same server, the more money
they make.
This also happens when small developers buy a reseller web hosting
package or if you buy one account and use a lot of addon domains. They just
keep adding customers to their own account for free and end up charging
you. The oversubscribing can get horrendous on these accounts.
Why should you care about overselling? Well, it means that the server is
stretched beyond reasonable limits, and all the WordPress sites on there
become even slower. There will be periods in the day when the site will not
even work. Also, the support is similarly stretched. Youve probably
wondered how they make money on $3/month hosting? Bang 5,000 to 10,000
sites on one server and pay one support guy.
The other thing that small web developers do is buy a VPS and start selling
accounts onto there. Guess what? It gets oversubscribed! However, the VPS
story gets worse. People buying 4 cores and 8gb of RAM think thats what they
get. And when they check their console, it says 4 cores and 8gb of RAMall
good, right? Wrong. The physical server might have 16 cores and 64gb of
RAM. The hosting company will sell 16 x VPSs on there for a total of 64 cores
and whatever 16 x 8 GB of RAM is. Essentially, theyve oversold each CPU
core by selling each core four timesso four different customers think they
own that core. When they all try to use it at the same time, their performance
drops. In other words, the VPS was oversold before your website even went
on there. This is why when you purchase a VPS, it initially seems sweet. The
first few sites are extremely fast, but then more sites are added and things start
to slow down more than they should. This is because you really only have one
core (at least some of the time).
So how do you tell if you are oversubscribed? Its difficult to know or
calculate. Its more likely to reveal itself in performance results over time.
All you web developer and agency guys reading this shouldnt really be doing
this to your customers.
There are a few types of hosting you can buy that are not oversubscribed:
1. Dedicated servers. However, if youre buying space from someone that
owns the dedicated server, then youre back in the same basket.
2. Amazon AWS, Google, Azurethese guys all charge a premium and dont
oversubscribe what is purchased. But again, if youre buying from someone
that says its on Amazon, theyll likely be oversubscribing.
3. Managed WordPress hosting. In this case, youre paying for hits, so this has
the least chance of ever being oversubscribed. Thats not to say that all cloud
hosting isnt oversubscribed, but its the end of the industry thats getting
cleaned up.
My plugin can help you understand if the server is oversubscribed. The biggest
indicator of oversubscription is variation in server response times. Sometimes
its fast, and sometimes its slow. The slow periods are when you have a noisy
neighbor getting a lot of hits or doing a backup or some other administrative
task on their server.
Of course, if your server is constantly slow, it could also be oversubscription,
and it just never moves fast.
My plugin does show the variance, but its currently only in the benchmark
section. In the main hosting check, you can look at the graphs and see if the
hourly average changes wildly, or if the horizontal graphs are all over the
place. A consistent server has all the server responses in a tight range on one
score, like this:
There are a few outliers below, but they are send email lead pages, which
results in it taking longer to send and confirm emails.

Review Hosting Model


There are a million hosting companiesand even more plansto choose
from, but they generally fall under a few different models:
1. Shared / web / reseller / addon
These are generally very cheap and have the worst performance. You wont be
able to change the software stack, but thats a good thing as most people in this
category dont want to deal with installing Linux software.

2. VPS hosting, either managed or unmanaged


This is where you rent a virtual server with Linux installed.
The promise is more resources and faster websites, but there are some
problems, such as overselling, as mentioned in the previous chapter, plus more
mentioned below.
You can change almost anything you likegreat! Well, sometimes great. If you
really know what youre doing, its great; if not, its just a series of ever larger
pitfalls.
Some people think, Ill just get a managed VPS. They think that someone else
will do the work for them, but youll find out that they actually do nothing for
you. If you specifically ask, they will only do the minimum. They will give bad
advice or none at all, and you have to ask for specific changes. They wont just
come along and make suggestions to help you; that will cost them hours of
support time, which they will try to avoid. Plus they generally arent experts at
WordPressthey are selling empty VPSsand their customers use the VPSs
for all sorts of reasons. So the advice and assistance is likely to be generic in
nature and will not be in line with WordPress.
An unmanaged VPS is almost the same as a managed VPS.
As the VPS owner, you end up with much more responsibility. You can crash
all the sites on the server rather easily. Youll know the pain of late nights
trying to fix one or all of the sites on the server. Youll be responsible for
backups, security, and cleaning hacked sites. Even if you have a managed VPS,
you cant log a support call and say, Please fix hacked WordPress site,
mrcleaner.com.au.

3. Managed WordPress
These are specialist WordPress hosting providers. This is where youll get
better skills and gain focus on keeping WordPress humming along smoothly.
We have a bigger investment in skills and tools that are focused solely on
WordPress hosting.

Change Hosting Provider

Here are the situations where you need to consider changing your hosting
provider:
- If your server response is not in the green zone (under one second)
- If there is too much variation in the server response. You cant fix this with
plugins, meaning that you are likely in an oversold situation.
- If your support is poorhow can plugins help that?
- If you suspect that you might be on the wrong style of plan
- Youve reconsidered and think you have your hosting based in the wrong
country

Here are your choices:


- Upgrade your hosting plan.
- If youre using a VPS, modify your software stack.
- Change your hosting strategy and/or provider.
Now, sometimes you cant upgrade your hosting plan. If youre on shared web
hosting, upgrading the plan means that they bill you more, dont change
anything technical, and likely provide you with the same speed. You can try the
upgrade and see what happens to the response time graphs anyway.
Some cloud plans that upgrade your plan will give you more resources, but
unless the site is extremely busy, more resources wont make the single page
respond faster; it just allows more pages to be seen by more users at once.
Moving to a managed WordPress provider is generally always an option. We
all know how to run WordPress at reasonable performance levels.
If you do own a VPS, you need to start researching how to fix some of the
issues, and youll find this guidance later in this book. Or you can move to
managed WordPress hosting.
Here are some of the upgrading plan paths:
- Shared web/reseller to VPS
This is a common upgrade path, but I think its generally a flawed
strategy. You go from a supported software stack to having to learn about
software stacks. Youll likely be doing it because the perception is that youll
be getting more resources to make your sites faster (which, as youve read, is
doubtful). This is more than likely an out of the frying pan and into the fire
strategy. This isnt just a scare tactic, but almost everyone moving to VPS will
suffer poor performance before they learn more and more about their software
stack. Youll have to put up with late nights fixing sites and the server. You are
also responsible for backups, which I know people try to do via plugins or
hope the hosting provider does it. Either way, its a headache. For agencies,
this is where youll end up with a partial or full staff salary running the hosting
for you. This is a partially hidden cost if you arent recording staff time
accurately.
- Moving to managed WordPress hosting
As mentioned before, this has a higher sticker price per month, but the
hosting provider takes the task more seriously and provides staff with better
and deeper skills in WordPress. Youll definitely spend fewer nights fixing
broken sites and servers; thats someone elses job. It will definitely reduce the
staff salary from an agency point of view. A HUGE portion of the performance
steps from the next chapter become someone elses issue, so you dont even
have to learn about them.
- Moving hosting to your local country
This is becoming more important, as discussed. Its not likely that its a
huge issue on its own for performance, but coupled with any other performance
issue, its likely to tip you over the edge to change your hosting provider.
Chapter 4. Fixing Micro Performance Issues
These are issues within the server or WordPress installation. The biggest
issues with how people attack WordPress performance are below:
1. Using the wrong metrics and mixing them up
2. Using a bunch of plugins that have helped others
What you need to be doing is conducting the analysis from the second chapter
and then working on specific fixes with some sort of plan or goal.
Just installing Plugin X because it sounds like a good idea wont always get
you to where you need to go.
Ive also mentioned that if there are big issues with your hosting, focusing on
caching or some other change wont necessarily help you. Imagine youre
driving a 90s Range Rover V8, but youre not happy with the fuel efficiency
commuting into the city. As a solution, you decide to polish your car so its
more aerodynamic. Thats just not going to cut it. Go back and read those other
chapters if youre trying to skip to the good stuff.
The rest of this ebook will consist of detail, detail, and more detail. However,
its largely broken down into on-page performance and server
performance.
You will likely need a bit of help with both (from your analysis, right?), but
dont mix up what youre doing for that reason.
Most of the following information is for VPS owners. Only some is useful for
shared web hosting, and even less is applicable for managed WordPress
hosting performance. Ill try to indicate which is appropriate for what strategy.

Server Speed
You should be aiming for under one second TTFB (or server response time,
which is roughly the same measure by a different name). This does not mean
loading the whole page, just the initial php/html page.
Hosting Strategy
One of the bigger impactful factors on performance is the hosting strategy that
you are employing: shared vs. VPS vs. managed WordPress.
Shared web hosting is cheap and slow; expect that and live with it. It will be
difficult to get your pages reliably fast enough throughout the day. It can be
done, but major issues like php version often cannot be corrected under shared
hosting.

PHP Version
One of the biggest performance impacts is the version of php you are using.
You should already know your php version from the analysis steps.
Upgrading to php 5.6 or php 7.0 (or HHVM) will result in a good performance
boost.
VPS
Php 5.3/5.4 php 5.5 is about two times faster, php 5.5 5.6 is about three
times faster, and 5.6 0> 7.0 is about four times faster.
WHM / cpanel can easily get you to php 5.6. Have a look in MultiPHP
Manager. You can change one site at a time or all the sites at once. Php 5.6 is
a very safe change as everything works with it.
WHM / cpanel can use php7 under easy Apache 4. However, until WHM 60 is
released (any day now), Id suggest you stay at php 5.6. There will be more on
that later in php handlers.
Php 7 is reasonably safe for WordPress now, but its important that your core
WordPress is updated, as well as all the plugins. Some sites might still break
under php7so be careful.
HHVM was super fast and exciting, but its being knocked off its high horse by
php 7. (They deliver roughly the same performance, but php7 is more
mainstream.) I dont think people are deploying it any more, so I wont spend
much time covering that.
Shared Web Hosting
Sometimes you can log a support request and theyll upgrade you but usually
not. Ive seen people deploy a new website on netregistry, and they had php
5.3 (which is a few years old, has poor security, and is super slow).

PHP Handler
This is something not many people know about, and it is fairly complex. A php
handler works with the web server and controls how php is executed.

VPS
Older versions of php5.5 and belowwere designed to run a php program
and exit. Php 5.6 and php 7.0 are designed to run a php program and stay
running. Both these versions optimize the code the longer they run, so its a
huge advantage on php 5.6 and even more on php 7 to have the php processes
run for a long time.
Back in the good ol days, we had Apache and basic software, and simpler
security and hosting were much easier.
Then we moved to multiple users on the same serverjust a single web server
but we wanted to separate out users to keep them safe from each other.
Anyway, to cut a long story short, in order to run php (and in turn WordPress),
we had to run separate php tasks for each user.
SuPHP was the default for whm/cpanel for a long time. It is secure, but it starts
a new php process for each page request and then shuts it down after. As
youve already learned, new php versions need to stay running. So while suphp
is secure, its very slow. Plus, if a whole bunch of WordPress pages are
requested at once, more php tasks start, they consume too much memory, and
the server crashesbut Ill get into that more later.
CGI is very similar to suphpso well consider them to be the same.
The good ol days php handler is mod_php. This keeps php running for long
periods of time, so its fast. However, if you have more than one WordPress
site, it lacks the appropriate security, so this isnt really an option.
The super new and fast php handler is php-fpm. And there is php 5.6 fpm and
php 7.0 fpm, which isnt really supported by whm/cpanel. (WHM v60 is due
out any day, which will change things.) So this is mostly managed by hand if
you want the ultimate performance php handler. Isnt owning a VPS just grand?
Youll need EasyApache 4 under whm to get php7.0, but you have to run it
under CGI, which is why I am recommending php 5.6 under EasyApache 3.
EasyApache 3 has a nice php handler fcgid. This keeps php running and
manages the number of running processes. I recommend the number of
processes for fcgid to be between two and the number of cores in your VPS
server.
So under whm 58 and below, EasyApache 3, fcgid, and php 5.6 are the best
supported and fastest you can get. Staying supported by the cpanel support
team should be a priority for you for either managed or self-managed VPS.
Whm 60, when its released, will likely be the best combination with
EasyApache 4, php7, and php-fpm. Its still a little experimental, the multi-php
screens are a bit too verbose, and there is a need to do mouse clicks for each
domain hosted. Its a bit of a pain to currently manage.
Shared Web Hosting
On shared hosting, there is no way to adjust the php handler; support calls will
never help you.
Nginx
Ive seen a lot of misplaced advice about upgrading from Apache to nginx.
At the base level, the web server (Apache or nginx) is doing two basic tasks
for your WordPress site:
- Serve static assets like images, javascript, and css files
- Call the php handler to deliver the dynamic WordPress pages
For serving static assets, there isnt much thinking required by the web server,
and both Apache and nginx perform the same.
For calling php, nginx has fewer options. Given that nginx is newer, it doesnt
have as many older and lower performing options. Nginx almost always uses
php-fpm, which is an excellent option, as mentioned in the discussion above.
If you compare both Apache and nginx using php-fpm, they have the same
performance.
Ive seen horrible setups where VPS owners have requested an nginx upgrade
from their managed VPS support, but what is delivered is a software stack like
this:
nginx Apache static files and php
In this setup, nginx is doing nothing and not contributing to any increase in
speed.
In my opinion, nginx and Apache have the same performance if you use php-
fpm on Apache.

Caching

This is the biggest micro-performance topic. There are loads of options as


almost everyone has tinkered with caching on WordPress. The thought pattern
usually goes like this:
My WordPress site is slow ask opinions slap on caching module/plugin
The problem with this strategy is that you havent given much thought to its
impact on users, its content, the lifecycle of the caching, or why you are
actually deploying caching.
Most of you will think that caching is a winwin and will just install it, but in
my opinion, its not that straightforward.
Here are a few valid reasons why you might employ caching:
- to speed up TTFB
- to reduce the server load from php-consuming resources
- to fight off performance problems when a page is popular
Different sites have different profiles, so caching needs to be handled
differently:
- a popular site with 1000s of unique visitors per day and only a small number
of pages
- a popular site with 1000s of unique visitors per day with a large number of
pages and blog articles
- a small business site with under 100 unique visitors a day
- a site with dynamic pages or one that uses cookies
- sites that get comments or regularly update their content
- ecommerce sites (These have their own chapter, so Ill exclude them here.)

Some caching strategies and tools work better with some profiles than they do
with others, and some caching tools are not available if youre on shared
hosting.

WordPress Plugin Caching Disk-based


This is the most common form of caching using a WordPress plugin.
W3 total cache is the most popular caching plugin by far, but I am moving users
away from this plugin. Its not actively developed and supported. Its getting
very old, and its overly complicated and bloated. In fact, it causes more
problems than it solves in terms of shared hosting.
The best free option is WP Super cache, in my opinion. WP Super cache turns
the dynamically generated PHP pages into static html files, which are far
quicker for the web server to process. This works well when you dont have
too many pages. If you do have a lot of pages, this cache can quickly get out of
control. A lot of the recommended settings within the plugin are smart; I
suggest a low cache timeout setting and enabling the cache rebuild
function. This will keep your pages fresh while still giving a low TTFB for
most users. Even for sites with dynamic content, setting the cache timeout to
two minutes works wellpages are fresh without causing a stampede on the
server.

WP Rocket is absolutely the best caching plugin for WordPress. It is a paid


option that works with most hosing. It works similarly to WP Super cache by
turning dynamic PHP-generated content into static content. It also optimizes a
lot of on-page assets, making the page load more quickly as well.
A word of caution on paid pluginsthey arent paid forever. You need to
repurchase WP Rocket every year. Paid plugins dont automatically get updates
if they arent paid up. If you have a site where a developer has put on WP
Rocket, you should still pay for it or else youll have an outdated version that
can cause security problems.
The downside of WordPress plugins is that if you have a bunch of WordPress
sites that you manage, it means a lot of installing, managing, updating, and
changing settings. Some of this can be alleviated with a central WordPress
admin console like ManageWP, but when you decide you need a new setting on
all 150 sites in WP Rocket, thats a lot of mouse gymnastics youre going to
have to perform.

WordPress Plugin Caching Memory-based


The other form of WordPress plugin caching is memory caching. This sets
aside a certain amount of memory for caching pages. The WordPress plugin
communicates with an application that manages the memory caching;
memcached is the most common or sometimes redis. Memcached usually isnt
available on shared web hosting plans, but if you are a VPS owner, it can be
installed.
Here is a list of software that you need to install:

memcached version
- memcached (or redis) application on Linux
yum install memcached

- install php extensions in WHM Software -> Module Installers -> PHP Pecl,
then add memcached and memcache for each version of php that you are using
(Youll need whm 60 for this.)
- restart Apache (from WHM)
- configure memcached :
vi /etc/sysconfig/memcached
PORT="11211"
USER="memcached"
MAXCONN="256"
CACHESIZE="512"
OPTIONS=""
systemctl restart memcached
- I use this for WHM to monitor the memcached service.
cat /etc/chkserv.d/memcached
service[memcached]=x,x,x,/bin/systemctl restart
memcached.service,memcached,memcached

add this in alphabetical order:


/etc/chkserv.d/chkservd.conf
memcached:1

restart chksrvd
/scripts/restartsrv chkservd
You should now be able to see the memcached service in WHM in services
status
- install a WordPress plugin that uses memcached; there are a few. Remember,
I warned against w3 total cache.
https://wordpress.org/plugins/memcached/
https://wordpress.org/plugins/wp-ffpc/

Redis instructions are similar:


- memcached (or redis) application on Linux
yum install redis

- install php extensions in WHM Software -> Module Installers -> PHP Pecl,
and then add redis for each version of php that you are using. (Youll need
whm 60 for this.) Im pretty sure that redis php is only available for php7.0
and php7.1.
- restart Apache (from WHM)
- configure redis :
vi /etc/redis.conf

systemctl restart redis


- I use this for WHM to monitor the redis service
cat /etc/chkserv.d/redis
service[redis]=x,x,x,/bin/systemctl restart redis.service,redis-
server,redis,root

Add this in alphabetical order:


/etc/chkserv.d/chkservd.conf
redis:1

restart chksrvd
/scripts/restartsrv chkservd
You should now be able to see the redis service in WHM in services status.
- Install a WordPress plugin that uses redis; there are a few. Remember, I
warned against w3 total cache.
https://wordpress.org/plugins/pj-page-cache-red/
This one is an object cache, which is a slightly different animal. Well talk
more about them later: https://wordpress.org/plugins/redis-cache/

Front-end Caching
There are a few caching solutions that cache before the request gets to the web
server: WordPress and php.
Varnish is common, and so is nginx inbuilt page caching. They essentially
deliver the same performance. Dont listen to people saying nginx is faster
(read more on that in my myths section).
Nginx caches to either disk or memcached. Varnish caches by default to
memory.
Both of these solutions are extremely fast, but they are both extremely hard to
set up and manage.
The upside is, you dont have to install it into each and every WordPress
website.
Below, I talk about Varnish, but the same thing applies to nginx page caching.
Here is the problem with this solution:
1. Its awesome at caching static objects, like images/js/css, but Apache is
already so fast at delivering static objects that you dont get a lot of gains. And
werent you supposed to be using a CDN for caching static assets anyway?
2. By default, Varnish will not want to cache WordPress dynamic pages, as
they are marked as dynamic. Therefore, youll need some Varnish foo to
override those settings. Then, there are pages that you dont want to cache in
Varnish (e.g., the admin console, woocommerce shopping carts, etc.), so youll
need more Varnish knowledge to exclude those from being excluded. At that
point, when a page gets updated on your site, you need to clear the cache from
Varnishyes, perhaps a WordPress plugin and more Varnish foo. As you can
see, there is a lot of Varnish knowledge required.
3. No HTTPS support is available on the free version, although it might be
coming at some stage.
4. No HTTP/2 support is available. (It needs https, and both are experimental
in the recent release.) Even if they do release it, certificates are difficult to
manage.

Here is a guide from Varnish:


https://info.varnish-software.com/blog/step-step-speed-wordpress-varnish-
software
And this is what wordpress.org says (basically, they say its great, but look
elsewhere for the configuration):
https://codex.wordpress.org/High_Traffic_Tips_For_WordPress#Varnish_Cache
Despite the work required, we actually use Varnish everywhere. The Varnish
knowledge and code can be extreme, but thats also an advantage. You can
interrogate any request and have a load of rules, and stuff still goes super fast.
One formula that weve come up with is short-lived Varnish caching just a
few minutes combined with allowing Varnish a long grace period (where
its allowed to serve old data). It alleviates the need to purge. This aims at
only moderate CPU reduction but high cache hit rates (a fast page returned to
the user always). It is a huge help on CPU reduction when you have a popular
Facebook post being hit, for example. The long grace period serves a cache
hit, the user gets a fast page, and we update the cache from
WordPress/php/apache in the background so that the cache is fresher for the
next user. No WordPress plugins required. This solution also works well with
sites with infrequent hits the long grace period will still deliver a cached
page quickly. It is a balance between not needing to purge caching on page,
moderate CPU reduction, and fast pages returned to users from a high cache hit
rate.

CDN

A CDN is a content delivery network a fancy name for a cache in the


cloud. You can have caching inside of WordPress (plugins like supercache),
caching in front of WordPress (e.g., Varnish), and a CDN is further out in front
again in the cloud before the request even gets to the web server.
Many people think CDNs are the cure-all for caching. In reality, they only
help in certain situations.
The biggest help that CDNs offer is to bring static resources closer to the end
web user and to reduce the delay from inter-country latency. However, if your
webserver is already in the same country, then it doesnt help that case.
A popular and free CDN is cloudflare. By no means is it the best, but its
common and a good reference point, so Ill discuss it here.
Cloudflare CDN can help in a few ways:
- If you dont already have https, cloudflare can add https for you.
Make sure you take steps to fix the redirect issue:
https://support.cloudflare.com/hc/en-us/articles/203487280--How-do-I-fix-
the-infinite-redirect-loop-error-after-enabling-Flexible-SSL-with-WordPress-
https://codex.wordpress.org/Administration_Over_SSL#Using_a_Reverse_Proxy
- Cloudflare will cache the static assets of your site. By default, it wont cache
the dynamic HTML pages of WordPress. You can get around that with a page
rule in cloudflare.
This will be useful to clear the cache when changes to pages/posts are made:
https://en-au.wordpress.org/plugins/cloudflare-cache-purge/
- It can add http/2 (more on that in another chapter).
- It can reduce your bandwidth costs, which isnt a concern for most people,
but if you have a large image library or a lot of downloaded files or sound
files, it might help a lot.

Database Performance - MySQL

All your WordPress pages and comments get stored in a database called
MySQL.
You should be using mySQL version 5.6 or newer. Mariadb is basically the
same software and will eventually replace mySQL. The only difference is
ownership battles mySQL was purchased by Oracle, and in order to get
away from Oracle, mariadb was started. Mariadb version 10 or 10.1 are both
current.
The speed at which your database can respond will greatly impact how fast
your WordPress pages can respond and it can easily become a bottleneck.

Innodb
By default, mySQL and cpanel/whm use myisam for storage. Myisam is slow
and lazy, so you should upgrade to innodb.
Not only does innodb run more quickly but it doesnt crash as often, and it
recovers nicely if you do crash the server. (You dont have to repair databases
and tables after a crash; the repair is automatic.)
This will list the tables you need to review (type mySQL at the command
prompt and paste this, or put it into php_myadmin):
SELECT table_schema,table_name,engine \
FROM information_schema.tables \
WHERE 1=1 \
AND engine = 'MyISAM' \
AND table_schema NOT IN ('information_schema', 'mysql',
'performance_schema');

#!/bin/bash
MYSQLCMD=mysql

Here is my script that will upgrade all the database tables on your server. One
of the lines does a backup of each table it converts in case something gets
broken, but obviously, you should also do a proper backup.

for db in dbname1 dbname2


do
mysqldump ${db} | nice pixz >/backup/convert/$db.database.sql.xz
for table in `echo show tables | mysql $db | grep -v Tables_in_`; do

mysqldump $db $table |nice xz >/backup/convert/$db.$table.sql


echo processing $db.$table
echo "ALTER TABLE $table ENGINE = InnoDB" | mysql $db

done
done

MySQL / InnoDB tuning


There is a ton of info out there about mySQL tuning, so I wont go into all the
details. Ill just cover the main topics.
The best tool for understanding your settings and some suggestions is
mySQLTuner-perl http://mysqltuner.com they have a screenshot on their
page. It will give you some stats and suggestions.
1. Some people argue that you should disable query cache for mySQL when
using innodb. I leave it enabled as I think it helps with the transients in the
wp_options table and WordPress object caching.
2. Allocate a reasonable amount of RAM as a percent of your overall RAM
and as a percent of the databases stored. The mysqltuner will give you a good
guide to both.
3. I disable the performance schema. I think it tracks statistics, but it also
gobbles memory that can be better used for other things.
performance_schema=off

4. I run this in a weekly cron job to keep everything performing nicely:


#!/bin/bash
mysqlcheck -u root -A --auto-repair
mysqlcheck --all-databases analyze

5. Ive found that a WordFence daily scan can really work mySQL hard
sometimes. At other times, there is some site bashing mySQL, so youll have to
find out which user account and what site. Here is what I use (again, command
line or phpmyadmin). If it is WordFence, disable the daily scan.
mysql> show processlist;

6. WooCommerce really hits mySQL hard, but Ive moved my


recommendations for WooCommerce to a separate section.

DDoS Wasting Resources


The biggest problem with WordPress performance is DDoS attacks. DDoS
stands for distributed denial of service attacks. Its not a very accurate term,
so dont worry too much about the word itself.
Basically, there are various bots and hacker groups trying to take over your
website so they can add your WordPress site to their bot collective. They do
things like put adverts on your site or worse.
Anyway, there is a security implication and a performance implication, and
were talking about performance.
Its not if or when the DDoS attack will come; they are constant all the time,
on all sites. The only thing that varies is their intensity. They come in a few
forms, but what they have in common is that they send requests to your
WordPress website. Your website has to think about them and then respond
back. That takes resources. If you dont do anything about the DDoS requests,
theyll take up 80 90% or more of your resources. If the hosting company
doesnt limit the DDoS requests, youll eat up your plan limits in no time.
Your WordPress website doesnt know they arent real users but just attack
bots. It simply gives them the same priority as your real users. Eventually, your
server is spending more time talking to the bots than talking to your real users.
Have you ever been told that youre over the limit on resources and have had
your account blocked? Almost everyone has. Then they ask you to upgrade
your plan, but what they dont do is stop the DDoS attack URLs. Basically,
those attacks are making them money. They also dont tell you that they have a
lazy software stack that is also soaking up resources unnecessarily.
Stopping the DDoS Attacks
1. Probably the easiest way is with WordFence, but it isnt perfect and also
takes some resources. Furthermore, it has the problem of requiring many mouse
clicks if you have a lot of WordPress sites to manage. This is a good option for
shared hosting if you only have a few sites.

2. If you are a VPS owner, its up to you to stop the DDoS attacks. There are a
few tools that can help you do this.
Fail2ban is popular. It reads the log files, looks for repeated attacks, and bans
those users.

I really like ModSecurity and lfd working together to ban users. WHM can
install and set up. I think lfd is part of CSF, which I highly recommend for
security as it does a great job of blocking the DDoS attacks. Both tools
integrate easily into WHM. It also protects all the sites running from DDoS
attacks. Its a paid option but not overly expensive.
https://configserver.com/cp/csf.html
3. Limiting the number of Web Server threads is also important.
If a DDoS attack is occurring, it can take up 100 or more web server threads.
Each thread needs a php task, which is often 100mb. If you allow too many
web server threads, your RAM becomes exhausted and your web server stops
responding.
Basically, you need to restrict the number of threads per account and have the
excess requests queued. Php-fpm is a great solution for this, which I talked
about earlier.
I wrote in more detail here in this blog post:
https://www.wpdone.com.au/error-502-on-whmcpanel-for-wordpress-
explained-and-solutions/
If you are using php-fpm, have a low number of max children; 0.5x 1.0x of
your real CPU cores is reasonable. If you have one large site, perhaps up to
two times the number of your cores is okay.
Setting a low max children seems like you are slowing or descaling your
server. However, youre really notyoure just controlling the upper limit of
resource usage per account. When the web hits exceed the number of max
children, they get queued. The queue is in both the web server (Apache or
nginx) and the Linux operating system. By default, the queue length is 128 on
Linux, which is fine, unless you have a large number of sites on your server or
youre trying to do load testing. Heres how to raise that limit:
sysctl net.core.somaxconn=1024 (or put it /etc/sysctl.conf for next reboot)

Here are my recommended settings for a 4 core VPS:


pm.max_children = 2
pm.max_requests = 500
pm.max_spare_servers = 2
pm.min_spare_servers = 0
pm.process_idle_timeout = 10m (this will kill off a child if its not busy after
10 minutes)
pm.start_servers = 0
listen.backlog = 1024 (only if youve increased it in sysctl)
We run haproxy in front of Apache for security and failover. It does an
awesome job of queuing and distributing the requests. With such a solution, it
is even more important to clamp the php processes down so that the queuing
and distributing can occur upstream.

4. Use a firewall to limit requests.


This is only a partially useful solution for a large number of requests from a
single IP address.
If you have a hardware firewall, simply limit the number of requests by source.
You can use csf to limit the connections with WHM:
CONNLIMIT = "53;5,80;15,443;15" (chuck this in /etc/csf/csf.conf)

This says to only allow 15 connections from a single IP for both http and https.
Each web user should only be opening four connections, and the requests get
multiplexed (each request from the same webpage gets queued and distributed
over the four connections by the web browser). The only difficulty youll have
with such a low setting is load testing or a large corporation where everyone
surfs the site at once.

5. Use haproxy.
We have some very advanced settings in haproxytoo many to include in this
ebook, but here is a snippet. If the first URL a user requests looks like rubbish,
slow them down for a few seconds. This is generally enough to sour your
server for the attacker. This also relies on keepalive being active on the
webserver.
I wrote more details and some code in my blog post:
https://www.wpdone.com.au/even-more-ddos-defence-against-xmlrpc-and-
login-attempts-for-your-vps/

On-page Speed Optimizations


Image Optimizing
Large images take time to download, so they make your webpage take longer to
load.
You can often reduce the quality of an image; it will become much smaller, but
the reduction in image quality is either unnoticeable or only slightly noticeable.
However, being quicker may outweigh the need for a perfect image. Sometimes
a reduced image quality is not what you want, for example, if you have a
photography business.
It can take a lot of effort to manage images by hand. Its easier to do it in an
automated fashion.
- Autoptimize is a popular WordPress plugin for images:
https://en-au.wordpress.org/plugins/autoptimize/
- mod_pagespeed is what I use. Its a general purpose webpage speeder-upper.
Its fairly similar to autoptimize but sits in front of the web server and
optimizes all the sites on the VPS as well as all the images and pages. Its
written by Google (so I reckon its a ripper with Google page rankings). It also
works great with cloudflare CDN.
- WP rocket does image optimizing as well.
All of these tools also do minification, which means reducing the number and
size of the javascript and style sheets. I was going to write a separate section
about minification, but if you use any of the tools above, youll already have
access to minification.
Reducing Elements
One of the biggest performance killers on a website is the number of elements
on the page combined with the number of http requests it takes to download all
the assets required.
Huge, fancy, premium WordPress themes, WordPress plugins, and sliders are
the biggest culprits.
As you add plugins to a WordPress site, they each add their own pieces of
code. This makes the page harder for the WordPress web server to calculate
(in php), but it also often adds a few more javascript/css elements onto the
page. These elements might not even be used on the page! One trick is to
disable plugins on certain pages. Plugin-organizer is a good tool for that:
https://wordpress.org/plugins/plugin-organizer/

HTTP Keep Alive


This used to be a fairly big deal, but its enabled most of the time now.
Without keep-alive, each asset on the page needs a new tcp connectionwhich
takes timeso without keep-alive, your page is basically much slower to load.
If you turn on keep-alive for too long, however, it can fill up slots on your web
server. I think just enough time for the webpage to load is finetwo to five
seconds is good.
Not only will your page loads be much slower but it also descales your web
server. It ends up spending half its life trying to reconnect for each web
request.
We use haproxy, so it does the keep-alive and can hold the web browser
connections open longer as its not absorbing Apache resources.
Its sort of a no-brainer on this one; you MUST have keep-alive enabled.
HTTP/2
Most sites are still using HTTP/1.1.
HTTP/2 is super new (this year) and is also great! Youve used it and didnt
even know it.
HTTP/2 does lots of neat tricks, but mostly it gains speed with a few key
strategies:
- Compressing headerseven though this sounds exciting, apparently it does
very little in practical terms.
- Multiplexing multiple requests over the one connectionthis is the biggest
boost. Web browsers using HTTP/1.1 generally open four different
connections to the web server and queued URL requests across those four
connections. A web browser using HTTP/2 opens one connection and sends all
the requests at once on the same connection, no queueing. The biggest gains are
pages with a larger number of assets to be loaded.
- Server pushso the server can send assets before you even knew you needed
them.
HTTP/2 does give quite a nice boost to performance. If you are serious, this is
the cutting edge and will help any WordPress site run faster.
HTTP/2 only really works if you have an https WordPress site, so the first
thing you want to do is upgrade to https.
Then you need the base web server to support it. Both nginx and Apache can
achieve HTTP/2. Currently, it seems like its still missing in whm.
The easiest way to get HTTP/2 is currently via cloudflare. You obviously have
to use their https as well. HTTP/2 is automatically enabled.
You can run something like nghttp2but its a bit difficult to handle certificate
management integration with whm.
Im eagerly waiting for whm/cpanel support or support from haproxy. Tap, tap,
tapbut for now, I just put people on cloudflare. Its easier and free.
However, I dont think it works via the cloudflare partner cpanel plugin,
because that doesnt allow https for free, so I think you need to move the whole
domain/dns to cloudflare to get https and HTTP/2.
In summary, HTTP/2 is great, but support for it is patchy at best. Its like php7
was a year ago, but eventually, whm/cpanel and everyone else catches up.
Myths
This section is about stuff that doesnt matter. Either its been outdated, its
overhyped, or its just plain wrong.

TTL on Assets
This usually arises from a page speed test saying that some of the assets on
your site need longer expiration times.
The expiration times dont affect the first pages loading speed, when youre
initially trying to impress your new visitor. It does affect subsequent pages or
subsequent visits. The default on most web servers is approximately 10
minutes, which is fine. Just ignore the stupid warning on your page speed test.
If youre still not convinced, I wrote a more comprehensive argument here, and
I included the code to fix the warning:
https://www.wpdone.com.au/why-you-should-not-be-adjusting-expires-and-
cache-control-headers-for-pagespeed-insights-on-your-wordpress-website/

Nginx Is Faster Than Apache


What a load of garbage! They are roughly the same speed. Nginx is newer and
therefore never had poor performing options like suPHP and php cgi, which
are the worst performance killers of all time. Nginx was developed more
recently, so it only came with the php-fpm option, which is crazy fast.
However, you can use the same php-fpm with Apache.
Ive actually seen a VPS server in a managed VPS environment where the
VPS owner requested to be upgraded to nginx. The managed VPS staff
deployed nginx in front of Apacheso when a web hit came, it hit nginx first
and then Apache. Obviously, this is just a waste of energy that makes things
slower.

Cookie-less Domains for Static Files


This falls into the category of it used to be a marginal optimization, but now
its not needed.
The idea is that the cookie makes the request bigger and therefore slower. If
you load 100 assets on a page, you send the same stupid cookie 100 times.
Cookies on assets like images/js/css dont even achieve anything!
Plus, with fewer cookies, caching and CDNs work better. However, I think the
CDNs mostly just ignore cookies on most assets now anywayor at least have
an option for that.
With the advent of HTTP/2 (see another chapter for more info), the http request
headers are all compressed. The first cookie that gets sent will get reasonable
compression (depending on its contents); subsequent requests containing the
same cookie will just reference the previously sent cookie, saving 99%. (This
is the way a compression dictionary works. Once it has seen something once, it
can refer to it again almost for free.) So if the problem is 99% compressed, its
a problem that has essentially gone away. Plus, with HTTP/2, you dont want
to open another connection to the separate cookie-less domain hostyou want
to output all the requests over the existing connection as its super fast that
way.
Multiple Hostnames for Static Assets
There used to be an optimization for putting images/js/css on a different URL
or a few different URLs. Browsers make up to four connections back to a web
server and can request four assets at a time. If you put them on different URLs,
you can open, say,16 connections and download 16 assets at once.
This has gone the way of the dodo as well with HTTP/2. The HTTP/2 spec
allows multiple downloads at the same time.

Maintenance
There are a few maintenance tasks you should schedule to maintain top
performance.
First, there are a few tasks mentioned above for mySQL. I even schedule the
convert to innodb daily (see an earlier chapter for that) to catch any new
WordPress installs.
Deleting Transients
These are a bit like zombiesbits of data left over, lurking dangerously, and
eventually slowing things down. There is a plugin you can run, which is a lot
of clicking. Or you can clear them from wp-cli. Here is part of my script;
youll need to loop all accounts:
#!/bin/bash
cd /var/cpanel/users
for account in *
do
cd /home/${account}/www
sudo -u ${account} /opt/cpanel/ea-php56/root/usr/bin/php
/usr/local/bin/wp --skip-themes --skip-plugins transient delete-expired
done

Deleting Revisions of Posts/Pages


Each time you save a post/page, or it autosaves, it creates different versions.
Sometimes these are useful if you screw things up. However, on large sites
with lots of posts, this can really add up in the database.
Use a plugin for this (This plugin will handle the transients as well and some
database maintenance too.):
https://en-au.wordpress.org/plugins/rvg-optimize-database/
Wp-cli doesnt seem to manage post revisions. I havent used it, but here is a
third-party tool: https://github.com/trepmal/wp-revisions-cli.
Better still, define your WordPress to save just five revisionsshove this into
wp-config.php:
define( 'WP_POST_REVISIONS', 5 );

Orphaned Data
After a few years of upgrades, moving your install, plugins being added and
removed, custom fields added and removed, etc., junk can get left around (like
in my garage at homeit needs a good tidy).
Something like this plugin can help clean things up:
https://wordpress.org/plugins/wp-cleanfix/
Chapter 5. WooCommerce Optimization
WooCommerce is a very flexible and common shopping solution. However, it
comes with some performance drawbacks.

Wp_options Optimizations
When you add a lot of products and skews/variations, WooCommerce puts a
lot of data in the wp_options table.
Putting an index on the wp_options table really helps large WooCommerce
installs. For more details, see my blog post:
https://www.wpdone.com.au/optimizing-wordpress-and-woocommerce-for-
thousands-of-products/

Page Caching
The other struggle with WooCommerce is page caching. You cant cache all the
pages, as there is shopping cart info on the pages.
One solution to that is using ajax to display the shopping cart. Ajax helps in
moving the shopping cart to a separate request after the initial WordPress page
has loaded. This allows normal page caching to be effective. Here are some
further details:
https://docs.woocommerce.com/document/show-cart-contents-total/
Chapter 6. Scaling WordPress
Sometimes there are only so many optimizations that you can do. At that point,
you need to get your wallet out and buy more resources. Moving to better
hosting might also help.
Eventually, you will hit a wall. You need either to go deeper into reviewing
your software stack (for example, Varnish) or start using more than one server.

Scaling mySQL
If mySQL is becoming a bottleneck, move it to another server that is more
suited to mySQL. Make sure it has SSD storage, a high number of cores, and a
large amount of RAM.
Occasionally, you might also need to scale beyond a single mySQL server, but
thats starting to get beyond the scope of this book.

Scaling Apache
The scale of Apache is rarely an issue these days. However, you might need to
up some kernel parameters for the number of connections and open files.
Haproxy in front of Apache can really help; its awesome at managing all the
connections.
Scaling Php
Php will eventually be your sinkhole of resources.
Once you have vertically scaled as much as you can (youve ordered the
largest server your hosting guys can sell you), you have a few options:
- Change to hosting that already has a cluster
- Start building your own cluster
Again, haproxy is a great tool on which to build your WordPress cluster.
Slowing Down Robots
You need Bing (Microsoft) and Google indexing your sites. However, they can
cause performance issues, especially Bingit can really hammer a site.
If left unchecked, a few sites being scanned by Bing can seriously impact
performance and resources.
Mj12bot is also a concernsome sort of social indexing spider. Mj12bot says
they will slow down from the fix below.
Baidu spider also impacts VPS servers heavily. It is a Chinese search engine
that doesnt respond to the polite request to slow down (shown below). I
generally just block the Baidu spider.
Something like this in robots.txt really helps, which just asks the crawling bot
to crawl one page per five seconds:
User-agent: *
Crawl-delay: 5
Chapter 7. The Ultimate WordPress Hosting
Stack

The Goal
What were really after is something that is super fast, all the time. We also
want something that doesnt increase support. Finally, we want to make
maintenance easier and not harder. If you have more than a few WordPress
instances, changing settings on plugins is a lot more work.
It would be icing on the cake if all the software were open source (as in, we
didnt have to pay a ton).
As you step through our stack, you can see all the principles abovefast, low
support, low maintenance, able to scale to loads of WordPress instances, and
open source. Weve built a stack that is fast and autonomouskeeping up
performance, stopping DDoS attacks, and increasing uptime availability.

A Word on Mod_PageSpeed
I cant say enough good things about mod_pagespeed. Its by Google, and its
whole goal in life is to accelerate above the fold display of a web page.
It does all the simple things, such as image shrinking, but then goes on to shrink
for each screen size and browser type differently.
Then it sticks all the modified images and metadata into memory (in
memcached). It puts a year expiration on all assets, which makes them nicely
cachable by browsers and cloudflare. It can get away with a year expiration as
it adds a checksum of the data to the URLso if the image changes, the URL
will change. No need to clear any cache.
Then it goes off and minifies all the javascripts and css files.
Mod_PageSpeed then decides to inline some images and css where it has
calculated those assets are usually above the fold. How does it know this? It
watches how each web visitor displays the web page and then sends back data
about what images/css were above the fold. Over time, it will know what is
likely to be above the fold.
Once you have mod_pagespeed up and running, its virtually maintenance- and
support-free. You arent adding plugins to WordPress, updating them, or
changing settings. If you have more than a few WordPress instances, changing
settings on plugins is a lot of work.

Okay, here is our stack.


Ill definitely need some diagrams. Here is each piece of our stack in order.
Cloudflare and Railgun
We use cloudflare as our CDN of choice.
It does a few things for us, like HTTP/2 and static asset caching.
Railgun mostly saves a bit of Internet traffic and is slightly faster, but our
servers are so physically close to cloudflare in Sydney that Railgun makes
very little difference.
Not all of our clients use a CDN. Weve found that our caching layers are as
good as a CDN and cloudflare. Therefore, if they mostly have Aussie
customers, using a CDN to cache the assets doesnt gain a lot.
Hardware Firewalls
These limit some of the worst Internet viruses and malware and have some
DDoS defense.
Software Firewalls
As discussed about the use csf/iptables, they perform some limiting on the
number of open connections. This helps with DDoS defense.

Haproxy
Haproxy is our second line of defense and does the lions share of our DDoS
defense. We have quite a few DDoS defense rules in haproxy, so we can stop
things like repeated login attacks well before the hits get to
Apache/PHP/WordPress.
Haproxy also does all of our HTTPS termination and certificates.
It is able to spread the hits over not just servers in one data center but across
our entire multi-datacenter cluster.
Haproxy is also the nerve center of our smart failover. Its monitoring the
health and load of all the web servers below it while also managing the load
and hits.
I cant say enough good things about haproxy. It keeps more sites running, hides
small failures, increases performance, and helps security. I love it.
An interesting feature of haproxy is the ability to queue requests. Instead of
allowing a thundering herd of elephants to trample your web server, it can
better manage this onslaught of traffic. Allowing a reasonable number of
concurrent requests to the web server actually makes it faster. Its partially a
mathematics trick. Ever thought about microwaving two meals at once? Say
they each need one minute of microwaving. If you put both in at once (enter the
thundering herd), the microwave will need two minutes. So the average
response time is two minutes. If you queue them, the first takes one minute, and
the second takes two minutes (one minute in the queue, one minute to heat),
with an average of 1.5 minutes/request. You were able to drop the average
response time from two minutes to 1.5 minutes by queuing. Sure, if you have
two microwaves (like two CPU cores), then you can handle two at onceso
you should adjust the queue depth in relation to your CPU cores.
See two references below for more details on how queuing makes web
response faster:
http://blog.haproxy.com/2011/06/28/play_with_maxconn_avoid_server_slowness_or_crash
http://www.slideshare.net/haproxytech/haproxy-web-performance-55536394
We also are able to do things like make separate queues for different URLs. We
allow more requests and a different queue for requests that we know are going
to be fast, like modpagespeed URLs, which will come from memcache. Images
and static content are also fast (and cached my modpagespeed), but slow
WordPress URLs are queued separately and with a smaller concurrent limit.
By marginally slowing some requests that look like hackers, the queue works
much better for real users. Then, if you imagine how smart it is, when a queue
is starting to get longer, haproxy can start to spread the traffic to different
servers or datacenters. Now that is just brilliant!
Haproxy really deserves its own chapter or an entire book.

Mod_Security and Mod_PageSpeed


Weve deployed both of these tools togetheras they are both Apache only
so Apache is in the stack as well.
While mod_security isnt for performance, its worth a mention here. It fully
automates security and does a good job of stopping DDoS attacks before they
reach WordPress. This not only keeps things safer but also helps performance.
We love mod_PageSpeed. It makes pages load faster and does a bunch of
caching in memcache. Its awesome and super fast.
Varnish
We use Varnish to cache WordPress. By default, Varnish only caches static
assets and doesnt cache the dynamic HTML web pages of WordPress.
So we have some secret source for WordPress and Varnish so that the dynamic
pages do get cached.
We set Varnish to cache for two minutes only but give it a long grace period.
This gives a super-fast response to the user and then refreshes the cache data in
the background. Its focus is on a fast response for the user, not necessarily a
huge reduction on CPU resource usage.
Weve been able to optimize Varnish for most cases of WordPress and
WooCommerce usage.
Weve had to engineer Varnish lower in the stack, so its after mod_pagespeed,
as mod_pagespeed optimizes a lot of assets per browser.
We use a cluster of Varnish servers and haproxy servers and keep-alive to
manage instant failover. You can find more details in this blog post:
https://www.wpdone.com.au/wpdone-cache-keeps-your-wordpress-website-
running-no-matter-what/
Nginx
Our webserver is actually nginx, but youll see that Apache is higher in the
stack so yes, we use both.
We could have used Apache, but there were a few pieces of automation foo we
liked in nginx.
We use HHVM for php. HHVM is incredibly fast. Having
said that, its very similar to php7 using php-fpm. We have
had HHVM in our stack for a while, and we are likely to
move this to php7 at some stage.
HHVM was developed by Facebook to run PHP faster and more efficiently.
Its been extremely fast and reliable for us. When we deployed it, it was about
three times faster than php 5.6 at the time, but php7 has closed the gap.
Plus, if we move to php7, we can replace some nice things, such as newrelic
support.
Perconna Extradb Cluster
We use a cluster of mySQL database servers running this amazing piece of kit
called perconna. Its an active/active cluster for mySQL databases, where all
nodes can accept reads/writes all the time.
We cluster our database servers across our three data centers. In this way, the
database load can be spread out, plus it helps increase uptime availability. It
also helps with things like maintenance.
Newrelic
We use newrelic on each piece of our stack. While it doesnt actually speed
anything up, its good at showing what is going slow and why.
WordPress Plugins
None. Were not using any caching plugins, image plugins, security plugins
not a single thing. Plugins are just too much trouble to manage over time.
We do use a redis plugin (and redis, obviously) for larger WooCommerce
installs.
Chapter 8. Whats Next?
You should review your current hosting. Perhaps you have some ideas for
upgrading your existing hosting services, such as moving to php7 and php-fpm,
which would boost almost everyone hosting out there.
Using my plugin is a great start and an excellent way to keep an eye on your
hosting performance. See https://wordpress.org/plugins/wp-hosting-
performance-check/

How You Can Work With Us


Smaller clients might want to consider moving their hosting to our managed
WordPress platform. Our focus here is to do the hosting right, keep your clients
happy, and still share the revenue.
If you have a VPS and have experienced the pain and cost of keeping it
running, you might want to consider giving up the management of the VPSbut
not giving up the revenue. Dont worrywell share that with you. With our
managed WordPress hosting, we do a 50/50 revenue split with the agency.
Larger clients may want to keep their VPS or dedicated servers. You might be
really happy with the hosting guys youre using. However, youve realized that
the salary costs you currently have managing the VPS arent well placed. Or
perhaps you generally want to up your game in terms of hosting delivery. For
these clients, we have a virtual CTO program. We not only review your
technical specs but also work with you on a structured plan to move along your
technology in order to better fit your business goals:
https://www.wpdone.com.au/virtual-cto/
Chapter 9. Hosting Recipes
Here are a few hosting recipes I have for common scenarios:

Small shared web hosting < 10 sites, small budget


Sometimes you just want to stay on shared hosting.
If the php version is below 5.6, or if MySQL is below 5.6, you really need to
move (your analysis above with my plugin should tell you what version you
have). These are long-term issues that youre unlikely to be able to solve with
your current provider. Even if you can get reasonable performance from your
hosting choice, that older technology is likely to lead to other issues, such as
lack of security and support. If they cant keep reasonable levels of technology
on the server, your shared web hosting company is probably doing a dodgy job
on other fronts too!
If your sites are important or make money, use our hosting at
https://www.wpdone.com.au.
If your php and mySQL versions are 5.6 or above, adding on WP Rocket is
likely your best option.

Larger Shared Web Hosting > 10 Sites, Small Budget


Youve probably already experienced accounts being closed, excess
CPU/resources emails, and sites being hacked. You probably also have no
backups, or youre spending time trying to keep Dropbox backups from
backupbuddy working.
If the php version is below 5.6 or if MySQL is below 5.6, you should be
changing providers. If you dont have php-fpm, you should consider switching
your provider as well.
Eventually, youll see that spending time mending problems in basically broken
web hosting accounts simply isnt the way you want to spend your life. Give us
a call when you want to consider our revenue-sharing modelyoull probably
make more money from it, with less effort.

VPS with Under 250 Accounts


You need to move to either:
- Php-fpm and php7. Make sure you have enough memory (see the chapter on
memory usage). Youll need to budget for roughly four cores and 16gb of RAM
per 100 WordPress installs.
- Managed WordPress hosting. Especially at the smaller end of this scale, its
harder to justify running your own VPS and spending the time when you might
be able to more easily shift the work and responsibility.
You might want to look into our revenue-sharing model. Well both make more
money, your clients will be happier, and youll spend less time managing your
servers.

VPS with 250+ Accounts


Youll start to find that you are struggling to get enough resources into one
VPS; although not impossible, it starts to become challenging.
Youll also notice increased time and supports costs. Sometimes an agency
ends up with a full or partial head count just to manage the hosting.
You might want to keep your current hosting arrangements as youre either
contracted, its working well for you, or your boss has fallen in love with the
provider. This is where our virtual CTO program can work with your
business leaders to drive the revenue and hosting even harder:
https://www.wpdone.com.au/virtual-cto/
Or you might take a harder look and, considering the head count and support
issues, move to a more partnered arrangement with wpDone. Move to a
revenue-sharing model, where we take over the hosting and you focus more on
client work, which frees up your head count.
Chapter 10. Php-fpm Memory Usage
Php-fpm is really fastespecially under php7.
Php-fpm php7 uses about 10% of the CPU resources that php 5.5 did or that
php 5.6 used under suPHP or CGI.
So it seems like a real winnerten times faster for free!
The downside is the memory constraints for php-fpm.
One word of caution on using php-fpm is that it starts long-running php
processes (up to days at a time). If youre currently using cgi or suPHP, the php
tasks are short-lived (about one second). The long-running nature of php-fpm
processes increases the memory pressure, so you need to budget resources for
that. Its roughly 64mb times the max_children times account. If there is a large
number of plugins or theme elements, it can be as high as 200mb, but 64mb is a
reasonable average to calculate from. That is roughly 12Gb of RAM for 100
accounts using max_children=2, plus mySQL and a few other things = 16Gb for
100 accounts on a VPS with php-fpm. If you use a higher max_children
number, or allow it to be more dynamic, youll need much more memory. I
think we can get away with a lower max_children as were using haproxy to
help manage the queue.
The good news about php-fpm and memory budgeting is that you have now put
upper bounds on how much memory your server will require. By using suPHP
or cgi as the php handler when the server became busier with more hits, it used
more memory (as more php processes were in flight at the same time and each
one required memory). Then there was a flow on effect. As more memory was
used, the server became slower, which in turn used more memory, etc. Before
long, you had a Chernobyl-sized meltdown going on. However, with php-fpm,
all your memory is committed up front and budgeted, and if your server does
get busy, there is no cycle that causes a meltdown. Sure, php-fpm processes
will spin and use CPU, but the server wont end up in a spiral.
My guess is that most VPSs arent ready for php-fpm considering that they are
CPU heavy and lacking in memory. Were running a trim max_children=2 and
16gb of RAM per 100 accounts, whereas I think most VPSs are running with
much less RAM than that.

Chapter 11. Case Study


Background
Ive worked closely with Dallas for the past six months. He has a web-
consulting business based in Cairns, Queensland, Australia. Previously, he had
a managed VPS at another Australian hosting provider. He also had a
number of previous hosting providers and had around 80 or so WordPress
sites.

The Challenges
He was struggling with unreliable software and late nights and lost weekends
fixing things, running low on disk space, and associated outages. He was also
struggling with poor uptime and poor performance. He was already paying a
premium for Australian managed hosting, and while his hosts probably meant
well, they simply werent focused on WordPress . Simple problems took a
long time to fix or were never resolved.
One of the spirals he was in was low disk space, which led to mySQL going
down. Then he had to find old backups to delete, and restart mySQL, and then
repair the mySQL databases. Have you ever had to find out what was eating
your 100gb of VPS disk space? There arent many tools that can show you disk
usage in a web environment. WHM/cpanel will give you a list of who is using
what disk space, but thats at an account/website level. After that, you end up
picking through folders in FTP.
Its a sad state of affairs when youre a business owner who charges high
hourly rates for consulting yet you know how to restart mySQL and repair
mySQL databases to prevent them from being crashed. Youre spending your
time doing basic admin work that you dont enjoy and shouldnt need doing: -
your time is better spent on your next project and customer.Surely your time
could be better spent doing anything else than managing a VPS.
The Upgrade to VPS
Dallas knows that shared hosting is mired with poor performance, poor
support, no backups, and a bunch of challenges. Therefore, some time ago he
upgraded to a VPS, which is where his bigger problems started.
He had to learn about how to run a VPS. He just thought, Its cPanelhow
hard can it be? It will be managedso I dont need to know much.
There was a lot more learning about Linux, whm/cpanel, ftp, security, Linux
software, backups, mySQL, fixing white screens of death on WordPress, and
fixing more error 500s than he ever wanted to know about.
The Messes
Weve had to slowly untangle Dallas messy DNS setups.
When you first get a VPS, youll find that you have one DNS server, but you
really need two or three separate DNS servers. Therefore, he kept his older
VPS to run a DNS.
However, there were also name servers pointing everywhere, and loads of his
Aussie clients were using U.S. name servers, only adding to the poor
performance.
Plus, when something went awry with DNS, it was a pain to pick through and
fix.
He struggled to keep his WordPress site updated, and he had occasional
hacked WordPress sites that needed to be recovered.
Poor Performance
None of his sites had even reasonable performance.
He had php 5.6 running under suPHP, a very common strategy (which, as you
recall, negates the advantages of php 5.6).
He had four cores and 4gb of RAM. Everything was squeezed in and only just
worked on a good day. On a bad day, error 500s popped up everywhere.
The Plugin Dance
Dallas had plugins for caching, plugins for security, and plugins for image
optimizing.
Then, if you wanted to change settings, there were 80 or more /wp-admin/
logins to change settings. Sure, you can use ManageWP or similar programs to
install/update plugins, but they dont fix settings.

Why Didnt His Managed VPS Support Help?


Because you have to ask them for specific tasks, and you have to know exactly
what to ask.
When you run out of disk space, theyll most likely respond with a VPS
upgrade request.
If you suffer from slow performance, youll be presented with an option of an
upgraded plan with more CPU cores.
It was managed at the VPS level, so they werent about to give him advice at
the WordPress level.
Calls From Clients About Their WordPress Site Being
Down
Now, this is as bad as it getsphone calls at odd hours, when youre either
trying to do something else or spending time with your family.
Website down support calls are the absolute pits. They suck up your time, they
are embarrassing, and each one is damaging to the relationship between your
client and your brand. Worst of all, you dont get paid for them. Even if you
charge for maintenance or support, you dont get paid extra from actually
giving the support!
Overall
Dallas was spending a huge amount of time learning and fixing through
countless late nights. None of this energy was being spent on his main business,
which is consulting with new clients.
Obviously, Dallas also has a personal lifeand managing the VPS directly
competes for his time and attention with his family.
Working with wpDone
Dallas now has all of the following:
- Reliable WordPress sites and happy clients
- No hacks to clean up
- No calls from clients about sites being down
- Fast WordPress sites
- Managed backups, including offsite backups to his Amazon S3 account.No
mucking with backupbuddy and DropBox
- No checking mySQL databases after a crashno crashes for that matter
- Dallas is saving about 20-30 hours a month in hosting-related time. He can
spend this time on new business, hanging out with his family, or even
watching a bit of televisionalmost anything else in life is time better spent
than support calls or fixing/learning hosting.
- No plugin dance with caching and security plugins
- Weve unraveled some messy DNS issues for him.
- Plus, he uses our WordPress support concierge, so he knows about site issues
before the clients even ring him! https://www.wpdone.com.au/announcing-
your-wordpress-website-support-concierge/
- More recently, weve been able to provide no error 500 protection to some
of his customers WordPress sites during failed changes and upgrades. So far
as the general public was concerned, the web sites were still working. At the
same time, WordPress was broken with error 500and Dallas and our support
were working on fixing WordPress database access.
https://www.wpdone.com.au/wpdone-cache-keeps-your-wordpress-website-
running-no-matter-what/