How to estimate how many website visitors your site can handle?

When you run campaigns or other events that may result in traffic peaks that are much higher than your site usually gets, you can prepare by estimating the impact the traffic will have on the hosting. There are a lot of variables that may impact the performance of your website, and hence the server load – and in this article we outline what you should worry about, what not to worry about, and how to make fairly precise estimates of the impact of your campaign on server resource usage.

There are always be trade-offs between performance and scalability. When you rig your website for high traffic you have to prioritise scalability before end user performance, you can often not get both. Hosting consists of many services that work together to provide the web pages to the end user, and all hosting has it’s bottlenecks. When you prepare a site for scaling, the focus is to get rid of the bottlenecks in the order that they may appear.

The magic formula we use for our estimates, that captures the essence and provides us an approximate number of how many users you can have simultaneously on your site in Google Analytics is:

(number of CPU cores / Average Page Response Time in seconds) * 60 * User Click Frequency in seconds = Maximum simultaneous users

Front-end performance like you measure with Pingdom Tools or PageSpeed Insights does not matter much when it comes to scaling. The bottleneck is not how your front-end works, but how much traffic and load your web server can handle.

How to estimate your web servers’ capacity

We have a few simple methods that are delightfully simple, but usually produce quite precise estimates of how much traffic your hosting setup can deal with. The bottlenecks that you first run into when scaling traffic are usually 1) PHP and 2) database performance. There are many techniques you can use to try to reduce the load on these, but let’s do the math first.

How to check the number of server CPU cores on the web server

A server has a certain amount of CPUs available. Let’s use a Dual 8 core CPU E5 box as an example.

bash-4.2$ grep processor /proc/cpuinfo | wc -l 32

In this example, the server has 32 cores available. The number of CPU cores sets the limit for how much PHP you can run before the server reaches it’s max capacity.  The CPU frequency (Ghz) will impact the overall performance of your website but is not relevant for the calculation of the max capacity.

You can also use a function like lscpu

bash-4.2$ lscpu  Architecture:          x86_64 CPU op-mode(s):        32-bit, 64-bit Byte Order:            Little Endian CPU(s):                32 On-line CPU(s) list:   0-31 Thread(s) per core:    2 Core(s) per socket:    8 Socket(s):             2 NUMA node(s):          2 Vendor ID:             GenuineIntel CPU family:            6 Model:                 79 Model name:            Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz Stepping:              1 CPU MHz:               1230.084 CPU max MHz:           3000.0000 CPU min MHz:           1200.0000 BogoMIPS:              4201.95 Virtualization:        VT-x L1d cache:             32K L1i cache:             32K L2 cache:              256K L3 cache:              20480K NUMA node0 CPU(s):     0-7,16-23 NUMA node1 CPU(s):     8-15,24-31 Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb invpcid_single intel_pt kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdseed adx smap xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts

This is somewhat harder to read for the untrained eye, but number of sockets * number of cores * number of threads per core will also produce 32.

How much CPU time does an average PHP request to your site consume?

The other metric we need for making the estimate is the amount of time the CPU uses to produce “the average” webpage on your site. The simplest way to do this is to check a few different pages (use the pages you expect your visitors to hit), and calculate an average.

The number we use for estimation is the sum of Time To First Byte + the Content Download time. In the example below we can read that the time spent to produce the front page is 271 ms which is 0.2 seconds.

For E-commerce stores it is important to check performance of front page, category pages, product pages, add to cart and checkout and make a realistic estimate. 

What is the relation between CPU cores and the time of PHP requests?

When a visitor hits your web page, the server is busy working with producing that web page until you have received it. For the example above, the CPU is busy for 271 milliseconds while producing this page for you. With 1 CPU core the limit of the server would be to deliver 3 pages per second.

Formula for calculating the max capacity of your web server

Number of CPU cores / Average time for a page request (in seconds) = Max number of Page Requests per second

The servers capacity is 32 CPU cores, so when every request to the website on average uses 0.323 seconds of CPU time – we might expect it to be able to deal with approximately 32 cores / 0.271 seconds CPU time = 118 requests per second.

Why is the number of page requests per second an important metric for Scalability?

The scalability of your website usually boils down to when your server hits the CPU limit. The average page request time captures both the time PHP consumes and the time the database uses for the queries.

How many users can I have on my website simultaneously?

The question is how does page views per second relate to Google Analytics? To figure out how many simultaneous users you can have on your site, you need to check your Google Analytics and calculate how often your users click on average.

If you navigate to Audience > Overview, you will find Average Session Duration and Pages per Session.

The session duration in this example is 9 minutes and 10 seconds, this is 9×60 + 10 = 550 seconds. Every user on average clicks 4.82 times. Divide the Average Session Duration / Pages per Session, and you will get 114s. This means that the average user on your website will click approximately once every 2 minutes (every 114 seconds). This number can vary a lot, but for E-commerce the rule of thumb is once per minute.

When we know that a user in Google Analytics clicks once every second minute, and we know that the servers’ capacity is 99 requests per second we can calculate a fairly precise estimate;

Number of max requests per second * 60 * Click frequency of users in seconds = Maximum Number of Simultaneous Users

99 requests per second * 60 seconds * click interval in minutes 2  = 11 880 Max Simultaneous Users in Google Analytics

There are a lot of questions you can raise regarding this way of calculating, but from our experience this way of calculating gives fairly precise estimates. You should however, always round numbers pessimistically to stay on the safe side!

How many users can I have on my JungleWP Pod?

If you run your site on a Pod with a Start Plan and with just one or a few CPU cores the capacity limit may be reached much earlier.

For example:

Average PHP request time: 650ms
CPU cores: 2
Click frequency: 45 seconds (normal for e-commerce)

2 cores / 0.65 = 3 pageviews per second * 60 * 0.75 = 135 Max simultaneous users

How to improve the scalability of your website

There are basically two things you can do to improve the scalability of your website. Either your website must consume less resources per visitor, or you have to increase the server resources.

For E-commerce server resources is crucial, because most requests are dynamic and will run PHP. Full Page Caching will help you scale a little bit, but with many sessions and carts, the server resources will usually be spent quickly anyway. Therefore, it is always a good idea to make your web application use less resources and make it faster.

The moment your site exceeds the limits of a single server setup, your costs will increase not only for your hosting plan or server. It will also increase your costs for consultancy, maintenance, development and make your setup more complex.

Our Performance dedicated hosting plans usually gives your site access to high performance CPU cores, but if you want better availability because you are targeting a large audience you will need to distribute your site across multiple dedicated servers that can automatically-scale based on volume and website's health. A healthy (fast site without bugs) E-commerce site will normally scale to many hundred, or even a few thousand users without any problems or worries!

Happy scaling!