There are two frequently asked questions about WordPress Servers:
- What size server should I use?
- How many sites can I fit on a server of x size?
These are not simple questions – there are many many variables that affect the answers.
However, that doesn’t mean that we can’t provide some sort of guidance for a STARTING POINT from which you can tweak. After all, it’s probably obvious that you wouldn’t put 100 simultaneous customers in a WooCommerce checkout process on a one core server.
To figure out a good starting point, we need to think about the factors that have the most effect on a WordPress servers’ performance.
Server Sizing – The Inputs
When you start thinking about what size server you might need, you first have to figure out exactly what you’re asking the server to do for you.
This means that you need to have a decent understanding about the type of site the server will be hosting, the type of traffic, the amount of traffic and the efficiency of the code being executed.
1. Type of site
While there are lots of types of sites, there are two main categories:
- Brochure sites with primarily read-only traffic and
- e-commerce sites with lots of dynamic activities.
In between there are membership sites, marketplaces and more.
2. Traffic Split
This means identifying how much of the traffic is read-only traffic and how much will require dynamic activity.
Read-only traffic can result in ultra-fast response times because data is being served from a pre-built cache. For this type of traffic you can serve hundreds of users with a single core.
Dynamic traffic are those requests that need to bypass the cache – such as those that are part of some sort of a checkout flow or performing other operations that require being logged into the site.
3. Amount of traffic
In particular this means the amount of SIMULTANEOUS users of each type at PEAK traffic. It’s easily orders of magnitude less efficient to serve an additional simultaneous dynamic user than it is to serve an additional simultaneous read-only user.
4. Efficiency of the site’s code
Some sites custom code everything which usually means highly efficient code, while others use tons of plugins which means inefficient code.
Efficient code can compile in less than a second while it might take two seconds or more to compile for each page load if the code is inefficient.
The WordPress Server Sizing Estimate Spreadsheet
We created a spreadsheet that allow an admin to enter some basic values for the above parameters and spit out a server sizing estimate. From there, you can run your own stress tests to decide if the server size needs to be increased or reduced.
Lets talk about what you’re looking at there.
The first section is where you enter data about the traffic you expect on your server:
- Read-only Traffic % is the percent of traffic you expect to be served from the cache.
- Dynamic Traffic % is the percent of traffic that will bypass the cache and therefore requires a dynamic compilation process before the page can be rendered. The combination of this number and the Read-only Traffic number should total 100%.
- Max Simultaneous Users is the number of users you want to be simultaneously using your site at peak times. Non-peak traffic is irrelevant – you need to be able to handle your peak traffic so everything about sizing your server requires peak-traffic data.
- Most Frequented Logged In Page Render In Seconds is the time it takes your most frequently used page to compile, assuming just one person is using the site / server. We used the word “render” in the spreadsheet because if you’re using stopwatch to figure this out, you likely will need to see the page load before you stop the clock.
In our image above, we’re looking to size a server that will have 1000 simultaneous users, of which 96% is expected to be served their data from cache and 4% (40 users) will be performing activities that bypass the cache. The page most frequented by users who are bypassing the cache takes about 1 second to compile and render.
Now, if you want ALL of your users to ALWAYS get a response time of 1 second or less, you’ll need 40 cores. Why? Because you’ll need one core for 1 second to serve the most popular non-cached page for your 40 simultaneous logged-in users who are all bypassing the cache.
If you were willing to allow for a 2 second response time, you’ll only need 20 cores because one core can then serve two users within that 2 second period.
Hopefully that all makes sense.
Underlying these calculations are certain assumptions you can play with:
The default is to assume that we can set up 4 PHP Workers per core and that each PHP Worker will use 128 MB of RAM. We’ll always start memory around 1 GB per core and assume that a server can render cached pages for 300 simultaneous users per core under in 2 seconds or less (a server core can usually handle more users than that for cached pages but we’re being conservative in our estimates here). We’re also assuming that each core is running at 2 GHZ or higher and that disk performance is on par with SSD.
Finally, we’re not taking into account any limitations on network card bandwidth or other similar misc aspects of your server. By the time you hit those limits you’re probably thinking of a different breed of servers anyway.
So, lets flex the sheet a bit by plugging some numbers in.
What if most of your traffic were brochure sites and you were the only person to log into a site. And lets assume that you want to be able to handle 1000 simultaneous users for those sites.
Since most of the traffic would be served from cache, you might not expect to need a lot of cores. And this is exactly what the spreadsheet spits out:
Efficiently Coded E-Commerce Site
Let’s assume that you have a great developer and that they’ve create an e-commerce site for you that does not pass a lot of things around in the URL string and, instead, uses AJAX and Cookies to render the cart and other non-logged-in user-specific items.
In that case, for your 1000 simultaneous users, only, maybe 2 % of them might be in a non-cached check-out flow or logged in, looking up something in their account.
Here’s what your server sizing starting point would look like:
Because you’re looking to handle 20 simultaneous users in checkout while still keeping EACH of their page response times at 2 seconds (that’s the time it takes to compile your most popular logged-in user page), you need a server with at least 20 cores.
If, however, you were willing to tolerate some logged-in users having a response time greater than than, say, 4 seconds, then your cores can drop to 10.
Or, if you can use a server with high frequency cores where the page compilation time could drop to 1 second, then you can also decrease the number of cores needed.
As you can probably start to figure out, the amount of time it takes to compile your most popular page for a logged in user is the critical metric that will affect your server size.
Lets say that again:
If your most popular page for logged in users take just a half a second to compile, then you can easily serve 2 simultaneous logged in users with a single core while still keeping response time for that page to under 1 second.
All other sizing metrics evolve from that.
The further down you can drive that time, the more simultaneous users you’ll be able to handle on a given server size.
So, if you’ve got a heavy site, it’s probably time to get a really really good developer involved who can help you remove some of the plugins you might have on your site and replace them with optimized code.
Of course, there might be other reasons a page takes a long time to render after compilation – including an inefficient database, heavy-duty JS scripts and more.
And we’re making an assumption that, for heavier sites, you’ll be using a CDN to offload those large images.
But for a server sizing STARTING point, the most important metric is the time it takes to compile the page that is most popular with your logged in users.
Which means the speed of your CPUs makes as big a difference as does the efficiency of your sites code.
If you’d like a copy of our spreadsheet to play with, we’ll be posting it in the private Facebook group so if you’re not already a member, now would be a good time to join.
Automatic Notification Of New Articles
Sign up to get automatic notifications of new articles. This is a different list than our standard list - you only get new articles once a week (usually on Mondays). No other emails will be sent unless you sign up for our general list as well.
Follow us on Twitter! We post a lot of cool things there first. Click the bird below!