WordPress Scaling & Performance - A Picture Which Speaks Thousand Words and More

Everyone and their dog talks about WordPress performance these days and also tells you how to scale WordPress (Read: How to really scale WordPress). When I grew up in Kharagpur (yes, the same Kharagpur which has the top IIT and yes I did my B.Tech there) everyone knew how to cure diabetes - you have to walk a lot, stop eating sweets, eat / drink varying concoction of Neem leaves and / or Nayantara leaves and / or Jamun fruit or seed and presto you are cured of diabetes. It works to some extent in uncomplicated cases and so does the various remedies for WordPress performance. Let’s see what are the often repeated “expert” advice for making WordPress perform (because by default WordPress performance is really really crappy; pardon my French):

1. Use wp-cache 2 or wp-super cache. Most people who swear by wp super cache haven’t done rigorous performance test for either. They just like the idea that it generates static pages. In real life tests both perform very closely. Super cache doesn’t give you the boost that you would expect from a plain file cache. We preferred wp-cache 2 because 1. it is simpler and easier to install 2. in our tests it performed better in real load simulations.

2. Use php code accelerators like eAccelerator, APC, Zend or Xcache. In our tests as also around the web it has been found that eAccelerator performs best. It is also extremely stable despite what you may hear. Choose your poison but choose one. We use eAccelerator. However note that with caching the value of php code caching drastically diminishes in live load situation. You will find the bottleneck will more often be MySQL.

3. MySQL optimization Tons of tips have been written around the web about mysql performance and we too have contributed some in the past.Use them judiciously. Just remember not to use MySQL cache when you are using the WordPress caching plugin or other page caching software (for reasons explained later).

In the end you have to think about using multiple MySQL instances in a master-slave ( as WordPress.con does ) or master-master replication (notes). Interestingly, despite our heavy and ever increasing traffic, we managed to avoid it.

4. Use lighter & faster web server like nginx or lighttpd. In our tests and also others have found out that nginx and lighttpd consume much less resources and overall are faster than standard Apache installations. nginx is preferred these days because it doesn’t have a memory leak problem as lighttpd. Both run php using the fastcgi protocol which effectively isolate the web server from the vagaries of php code. Configuring nginx for WordPressto be equivalent with baseline Apache installation is much harder than Googling would lead you to believe. It has a steep learning curve and if not done thoroughly can affect your site in ways that you would never realize and may take months, if not more, to figure out and solve.

Now that we have most of the common tips behind us let’s look at their limitations. In heavy site load cached pages are served fine but even the limited amount of pages that are served in real-time is enough to bring your server to a crawl. With CPU at 0% idle (and MySQL can do it in tbe twinkle of an eye), all your site will be really slow, even when cached pages are being served. All the above techniques work well when there is some cpu and memory to spare.

MySQL can serve only about 40-50 WordPress pages even on a pretty high end server (2 processor quad core 2ghz cpu with 4gb of RAM) even with tuning. That is what you have to begin with.

MySQL caching, recommended by many experts, is a bad idea when you are using a caching plugin, examples given above, because most of the requests you are then serving is dynamic or unique (otherwise it is cached). So MySQL cache end up affecting performance and unnecessarily consuming resources.

The biggest problem with all these techniques described above is that you cannot ensure that your site will always serve pages to its available maximum bandwidth for any mix of static and dynamic requests.

Remember fail-whale in twitter. It is actually a good thing. Twitter knows when to deny requests when it can take no more. But we should strive for better, be able to take any amount (read very very large amount) of load you can throw at it.

You are always trying to compensate your server’s lack of reliability by throwing bigger and more hardware at it, without getting the full value for your money. You end up not only spending more but contributing to global pollution.

Previously I talked about how we achieved to serve over 10, 000 WordPress pages (from this blog so we are talking real data baby) per second at 1.6 Gbps and handle over 20, 000 connections per second without throwing a single error, all from a single server. How did we do it?

The key features of our architecture are:

1. Ability to scale without limit
2. Reliability under any amount and mix of load. No more server restarting in the middle of night.
3. Ability to use the full CPU hardware & resources or less, under your full control
4. Ability to provide similar performance even on low-end dedicated or VPS servers.

One thing that will probably make many LAMP aficionados cringe is that all the magic is done by a Java server in the middle. Our WordPress blogs (and now MODx sites) are all powered by Java too.

All talk aside, the proof of pudding is in eating. So how are we doing now? Take a look at the Google crawler stats at the top of this page which shows the time spent in downloading a page. Before February 6th not only it took a huge amount of time to serve a page but more importantly imho the time varied wildly depending on server load which indicates low reliability. After we switched to the new setup not only the time went down dramatically but also the wild fluctuations are gone. That indicates the reliability of our new setup. Also the traffic increased after the switch as we are not suffering from frequent overloading anymore and we are able to serve pages much faster.