The switch from WP Super Cache to LiteSpeed Cache

We recently introduced LiteSpeed web server on our servers; this was done due to scalability and reliability (We’ll publish a blog post about this soon!).

LiteSpeed has a great feature called LSCache; it’s a caching mechanism implemented directly in the web server. LSCache gives the ability to use full page caching on many websites and even ESI if you want fine-grained caching for private sessions.

Quite a few of our customers run with WordPress and often they’re configured with WP Super Cache or other caching plugins – we got to take a look on one of our customers that we’ve configured WP Super Cache to have a rather high cache-hit ratio.

The configuration for WP Super Cache took quite some time to get the most out of the software for the traffic that is served, and it gives about an 85% cache-hit ratio during peak traffic.

We agreed with the customer to change from WP Super Cache to LiteSpeed Cache during peak hours, to see how the number of dynamic requests would improve – and to our surprise, the cache-hit ratio became even better after switching.

We use New Relic® to Monitor applications, and after we switched out the modules shortly after 9.30am, we saw an instant drop in throughput for the dynamic requests (lower right graph).

The site went from about 180 dynamic requests per minute down to 49.7 – a decrease of 72.4% and bringing the cache hit ratio to 96.25% – more than a 10% increase!

Now, you’ll see something odd – the average response time went from 20ms to about 90ms – one would think that this actually means the site is slower after the change.

However, since the response time is based on about 200 dynamic requests per minute and then later based on 50 dynamic requests per minute, it means that the average will increase, let us see why.

When we drill down into what actually improved the cache, we see that the number of calls to /index.php to fetch content also dropped from roughly 150 dynamic requests per minute down to less than 1 dynamic request per minute, this means other things (such as admin-ajax.php) in WordPress will end up increasing the average response time for the site.

The increase in the response time on the /index.php is caused by also a low throughput, and these pages are the actual uncached ones.

The site did become quicker for an additional 11% of the visitors due to the higher cache-hit ratio. Also at the same time, we ended up decreasing the CPU usage by 33% for the same customer by switching out the caching plugins.

Overall, we think that the usage of LiteSpeed Cache for WordPress is an excellent addition to faster load times and better scalability for high traffic customers.