{"id":735,"date":"2014-06-25T12:00:03","date_gmt":"2014-06-25T16:00:03","guid":{"rendered":"https:\/\/reviewsignal.com\/blog\/?p=735"},"modified":"2017-02-23T04:26:22","modified_gmt":"2017-02-23T09:26:22","slug":"40-million-hits-a-day-on-wordpress-using-a-10-vps","status":"publish","type":"post","link":"https:\/\/reviewsignal.com\/blog\/2014\/06\/25\/40-million-hits-a-day-on-wordpress-using-a-10-vps\/","title":{"rendered":"40 Million hits a day on WordPress using a $10 VPS"},"content":{"rendered":"

I recently tested many\u00a0of the biggest names in managed WordPress hosting in my article Managed WordPress Hosting Performance Benchmarks<\/a>. (Update: 2016 WordPress Hosting Performance Benchmarks<\/a><\/strong>) I am\u00a0preparing to do a second round of testing with double the number of companies on board. Some of us like to setup servers ourselves (or are cheap).<\/p>\n

Given a reasonable VPS, what sort of performance can we get out of it?<\/strong><\/p>\n

10 million hits as measured by Blitz.io<\/a> was the benchmark to beat based on a previous<\/a> iteration of this question.<\/p>\n

I decided to test this from the ground up, let's start with the most basic configuration and gradually try to improve it.<\/p>\n

All tests were performed on a $10\/Month 1GB Ram Digital Ocean<\/a> VPS running Ubuntu 14.04x64. All code and documentation are also available on GitHub<\/a>.<\/p>\n

LAMP Stack<\/strong><\/p>\n

Based on my previous experience benchmarking WordPress, I didn't have high hopes for this test. Last time I crashed MySql almost instantly. This time I ran Blitz a lot slower, from 1-50 users. The performance wasn't impressive, it started slowing down almost immediately and continued to get worse. No surprises.<\/p>\n

\"default-lamp\"<\/a><\/p>\n

The LAMP stack setup script is available on GitHub<\/a>. Download full Blitz results from LAMP Stack (PDF)<\/a>.<\/i><\/p>\n

LAMP + PHP5-FPM<\/strong><\/p>\n

The next thing I tried was PHP-FPM<\/a>(FastCGI Process Manager). It got slightly better performance with just under 200ms faster response times at 50 users. But the graph looks pretty similar, we're seeing quickly increasing response times as the number of users goes up. Not a great improvement.<\/p>\n

\"lamp-php-fpm\"<\/a><\/p>\n

The LAMP+ PHP5-FPM setup script is available on GitHub.<\/a> Download full Blitz results from LAMP+PHP5-FPM (PDF)<\/a>.<\/i><\/p>\n

Nginx + PHP-FPM (aka LEMP Stack)<\/strong><\/p>\n

Maybe the problem is Apache? I tried Nginx next. What happened? I got a worse performance than the default LAMP stack (wtf?). Everyone said Nginx was faster. Turns out, it's not magically faster than Apache (and appears worse out of the box).<\/p>\n

\"lemp-php-fpm\"<\/a><\/p>\n

The LEMP + PHP-FPM setup script is available on GitHub.<\/a> Download full Blitz results from LEMP+PHP-FPM (PDF)<\/a>.<\/i><\/p>\n

Microcaching<\/strong><\/p>\n

I've written about creating a reverse proxy and cache in nginx<\/a> before. But I've already setup Nginx as my web server, I don't need to reverse proxy this time. Nginx has fastcgi_cache<\/a>\u00a0which allows us to cache results from fastcgi processes (PHP). So I applied the same technique here and the results were staggering. The response time dropped to 20ms (+\/- 2ms) and it scaled from 1 to 1000 concurrent users.<\/p>\n

\"This rush generated 28,924 successful hits in 60 seconds and we transferred\u00a0218.86 MB of data in and out of your app. The average hit rate of\u00a0482\/second translates to about 41,650,560 hits\/day.\"<\/strong><\/p><\/blockquote>\n

All that with only 2 errors (connection timeouts).<\/p>\n

\"lemp-microcache\"<\/a><\/p>\n

The LEMP + PHP-FPM + microcaching setup script is\u00a0available on GitHub.<\/a>\u00a0Download full Blitz results from\u00a0LEMP+PHP-FPM + microcaching (PDF)<\/a>.<\/i><\/p>\n

Mircocaching Config Walkthrough<\/strong><\/p>\n

We do the standard<\/p>\n\n

apt-get update<\/span>\napt-get<\/span> -y<\/span> install<\/span> nginx\nsudo<\/span> apt-get<\/span> -y<\/span> install<\/span> mysql-server mysql-client\napt-get install<\/span> -y<\/span> php5-mysql php5-fpm php5-gd php5-cli<\/pre><\/td><\/tr><\/table><\/div>\n\n
This gets us Nginx, MySql and PHP-FPM.<\/p>\n
Next we need to tweak some PHP-FPM settings. I am using some one liners to edit \/etc\/php5\/fpm\/php.ini and \/etc\/php5\/fpm\/pool.d\/www.conf to uncomment and change some settings [turning cgi.fix_pathinfo=0 and uncommenting the listen.(owner|group|mode) settings].<\/p>\n\n
sed<\/span> -i<\/span> "s\/^;cgi.fix_pathinfo=1\/cgi.fix_pathinfo=0\/"<\/span> \/<\/span>etc\/<\/span>php5\/<\/span>fpm\/<\/span>php.ini\nsed<\/span> -i<\/span> "s\/^;listen.owner = www-data\/listen.owner = www-data\/"<\/span> \/<\/span>etc\/<\/span>php5\/<\/span>fpm\/<\/span>pool.d\/<\/span>www.conf\nsed<\/span> -i<\/span> "s\/^;listen.group = www-data\/listen.group = www-data\/"<\/span> \/<\/span>etc\/<\/span>php5\/<\/span>fpm\/<\/span>pool.d\/<\/span>www.conf\nsed<\/span> -i<\/span> "s\/^;listen.mode = 0660\/listen.mode = 0660\/"<\/span> \/<\/span>etc\/<\/span>php5\/<\/span>fpm\/<\/span>pool.d\/<\/span>www.conf<\/pre><\/td><\/tr><\/table><\/div>\n\n
Now make sure we create a folder for our cache<\/p>\n\n
mkdir<\/span> \/<\/span>usr\/<\/span>share\/<\/span>nginx\/<\/span>cache<\/pre><\/td><\/tr><\/table><\/div>\n\n
Which will we need in our Nginx configs. In our \/etc\/nginx\/sites-available\/<\/span>default<\/a> config we add this into our server {} settings. We also make sure to add index.php to our index command and set our server_name to a domain or IP.<\/p>\n\n
location ~ \\.php$ {<\/span>\n\t\ttry_files $uri<\/span> =404<\/span>;\n\t\tfastcgi_split_path_info ^(<\/span>.+\\.php)<\/span>(<\/span>\/<\/span>.+)<\/span>$;\n\t\tfastcgi_cache  microcache;\n\t\tfastcgi_cache_key $scheme<\/span>$host<\/span>$request_uri<\/span>$request_method<\/span>;\n\t\tfastcgi_cache_valid 200<\/span> 301<\/span> 302<\/span> 30s;\n\t\tfastcgi_cache_use_stale updating error timeout invalid_header http_500;\n\t\tfastcgi_pass_header Set-Cookie;\n\t\tfastcgi_pass_header Cookie;\n\t\tfastcgi_ignore_headers Cache-Control Expires Set-Cookie;\n\t\tfastcgi_pass unix:\/<\/span>var\/<\/span>run\/<\/span>php5-fpm.sock;\n\t\tfastcgi_index index.php;\n\t\tinclude fastcgi_params;\n}<\/span><\/pre><\/td><\/tr><\/table><\/div>\n\n
Then we move on to our \/etc\/nginx\/<\/span>nginx.conf<\/a> and make a few changes. Like increasing our worker_connections. We also add this line in our http{} before including our other configs:<\/p>\n\n
fastcgi_cache_path \/<\/span>usr\/<\/span>share\/<\/span>nginx\/<\/span>cache\/<\/span>fcgi levels<\/span>=1<\/span>:2<\/span> keys_zone<\/span>=microcache:10m max_size<\/span>=1024m inactive<\/span>=1h;<\/pre><\/td><\/tr><\/table><\/div>\n\n
This creates our fastcgi_cache.<\/p>\n
All of these are done in somewhat ugly one-liners in the script (if someone has a cleaner way of doing this, please share!), I've cleaned them up and provided the full files for comparison.<\/p>\n
Go Big or Go Home
\n<\/strong><\/p>\n
Since Nginx didn't seem to blink when I hit it with 1000 users, I wondered how high it would really go. So I tried from 1-3000 users and guess what?<\/p>\n
\"This rush generated 95,116 successful hits in 60 seconds and we transferred\u00a0808.68 MB of data in and out of your app. The average hit rate of\u00a01,585\/second translates to about 136,967,040 hits\/day.\"<\/strong><\/p><\/blockquote>\n
The problem was I started getting errors: \"4.74% of the users during this rush\u00a0experienced timeouts or errors!<\/i>\" But it amazingly peaked at an astonishing 2,642 users per second. I watched my processes while the test was running and saw all 4 nginx workers fully maxing out the CPU (25% each) while the test was running. I think I hit the limit a 1GB, 1 Core VPS can handle. This setup was a champ though, I'm not sure what caused the big spike (perhaps a cache refresh), but if you wanted to roll your own WordPress VPS and serve a lot of static content, this template should be a pretty good starting point.
\n\"lemp-microcache-3000\"<\/a><\/p>\n
Download full results of 3000 users blitz test (PDF)<\/a><\/i><\/p>\n
Conclusion<\/strong><\/p>\n
There are definitely a lot of improvements that can be made on this config. It doesn't optimize anything that doesn't hit the cache (which will be any dynamic content, most often logged in users). It doesn't talk about security at all. It doesn't do a lot of things. If you aren't comfortable editing php, nginx and other linux configs\/settings and are running an important website, you probably should go with a managed wordpress company. If you really need performance and can't manage it yourself, you need to look at our Managed WordPress Hosting Performance Benchmarks<\/a>. If you just want a good web hosting company, take a look at our web hosting reviews\u00a0and comparison table<\/a>.<\/p>\n
All code and documentation is available on GitHub<\/a><\/p>\n
Thanks and Credits:<\/strong><\/p>\n
The title was inspired by Ewan Leith's post 10 Million hits a day on WordPress using a $15 server<\/a>.\u00a0Ewan built a server that handled 250 users\/second without issue using Varnish, Nginx, PHP-APC, and W3 Total Cache.<\/p>\n
A special thanks goes to A Small Orange <\/a>who have let me test up multiple iterations of their LEMP stack and especially Ryan MacDonald at ASO who spent a lot of time talking WordPress performance with me.<\/p>\n","protected":false},"excerpt":{"rendered":"
I recently tested many\u00a0of the biggest names in managed WordPress hosting in my article Managed WordPress Hosting Performance Benchmarks. (Update: 2016 WordPress Hosting Performance Benchmarks) I am\u00a0preparing to do a second round of testing with double the number of companies on board. Some of us like to setup servers ourselves (or are cheap). Given a […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[47],"tags":[18,25,74,27,48],"_links":{"self":[{"href":"https:\/\/reviewsignal.com\/blog\/wp-json\/wp\/v2\/posts\/735"}],"collection":[{"href":"https:\/\/reviewsignal.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/reviewsignal.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/reviewsignal.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/reviewsignal.com\/blog\/wp-json\/wp\/v2\/comments?post=735"}],"version-history":[{"count":16,"href":"https:\/\/reviewsignal.com\/blog\/wp-json\/wp\/v2\/posts\/735\/revisions"}],"predecessor-version":[{"id":1804,"href":"https:\/\/reviewsignal.com\/blog\/wp-json\/wp\/v2\/posts\/735\/revisions\/1804"}],"wp:attachment":[{"href":"https:\/\/reviewsignal.com\/blog\/wp-json\/wp\/v2\/media?parent=735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/reviewsignal.com\/blog\/wp-json\/wp\/v2\/categories?post=735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/reviewsignal.com\/blog\/wp-json\/wp\/v2\/tags?post=735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}