Nginx FastCGI-Cache -vs- Redis Object Cache – speed & Hits p/s

VersionPress – this a WOW plugin!
April 29, 2016
Show all

Nginx FastCGI-Cache -vs- Redis Object Cache – speed & Hits p/s

In the world of WordPress, speed is KING. Why? because Google will love you if your website is fast! A fast site is a good user experience (UX), and a satisfying UX leads to higher conversions. How fast your website loads is a critical – but often completely ignored – element in any online business – and that includes search marketing and search engine optimization. Very slow sites are a bad user experience – and Google is all about good UX these days.

loading

a 2-second delay in load time during a transaction resulted in abandonment rates of up to 87%. This is significantly higher than the baseline abandonment rate of 67%.

Web Performance is always measured by performance goals and the opportunity to meet certain business metrics such as increased conversions and revenue.

This is why we test everything we can think of from caching plugins to various nginx setups and configurations. Because your sites loading time is essential to your online businesses success.

Recently, we’ve been running several different tests using Redis Object Cache and Nginx FastCGI Cache.

Redis is an open-source key value store that can operate as both an in-memory store and as cache. Redis is a data structure server that can be used as a database server on its own, or paired with a relational database like MySQL to speed things up, as we’re doing in this tutorial. Redis was configured as a cache for WordPress to alleviate the redundant and time-consuming database queries used to render a WordPress page. The result is a WordPress site which is much faster, uses less database resources, and provides a tunable persistent cache.

Nginx FastCGI module has a Nginx directive for caching dynamic content that are served through PHP backend. When a web page is cached, repeated requests for the same page by web clients is quickly returned by the webserver because the page is coming from a cached location.

Instead of the webserver compiling all the dynamic data the makes up the page before returning it to the web clients on each request, a page is cached as a whole (all the data the makes up the page are stored together) and that the webserver doesn’t have to fetch dynamic data before returning that page to web clients.

Both caching methods are very good but which is actually better? There really isn’t a “better” or “faster” solution. There’s only what works best for you, your sites and in your environment. In our testing environment, we are utilizing 2 separate virtual private servers each with 768MB ram and 1 CPU core ( don’t need much for testing purposes ) with Nginx, PHP7, Opcache and Memcached.

The first test, we loaded up a brand new WordPress site with only the required plugins to do the job for each test

  • VPS 1 includes Redis Object Cache + Nginx Helper plugin installed
  • VPS 2 includes just Nginx Helper plugin

We’ll use Pingdom to run the page speed tests through.

VPS 1: Redis Cache testing…

Screenshot_4

 

VPS 2 with Nginx FastCGI Cache..

Screenshot_5

Not a huge difference in speed but ever millisecond counts! However, keep in mind that Redis Cache uses your RAM and FastCGI cache does not:

Redis Object Cache Ram usage

Screenshot_6

Nginx FastCGI Cache Ram usage

Screenshot_7

Lets test both systems on a loaded up WordPress install with a very popular theme – Avada with the required plugin, Fusion Core.

VPS 1: Redis Cache testing…

Screenshot_8

VPS 2 with Nginx FastCGI Cache..

Screenshot_9

The first test above, ( test run 1 ), we ran the page speed test on a vanilla WordPress with the basic theme. Between both page speed tests in test 1 there was a 6ms  load time difference with Nginx FastCGI Cache as the winner. However, as you can see in test run 2, there is quite a difference with a 92ms page speed load time and yet again with Nginx FastCGI Cache as the winner.

Now we will use Seige Load testing tool to see how well each configuration does against concurrent active users per second or HITS/Pageviews. Seige allows for a more real-world simulation of how a user would use the system.

VPS 1: Redis Object Cache test with Seige:

The first testing formula we used for Seige is an easy one: siege -c50 -d10 -t3M which means -c50 sets the concurrent number of simulated users, -d10 that each “user” will sleep/pause for between requests ( reading )  and -t3M is how long the test will last. In our case, 3 minutes.

Test 1: siege -c50 -d10 -t3M – 50 concurrent users/hits per second

Screenshot_10

Test 1 Breakdown: 1,749 total hits/visits within a 3 minute duration with 100% availability and no lost connections.  Response time for each hit/visit was 0.04 seconds. VPS withstood 9.75 hits/visits per second.

Test 2: siege -c100 -d10 -t3M – 100 concurrent users/hits per second

Screenshot_11

Test 2 Breakdown: 3,515 total hits/visits within a 3 minute duration with 100% availability and no lost connections.  Response time for each hit/visit was 0.04 seconds. VPS withstood 19.63 hits/visits per second.

Test 3: siege -c255 -d10 -t3M – 255 concurrent users/hits per second

Screenshot_12

Test 3 Breakdown:8,988 total hits/visits within a 3 minute duration with 100% availability and no lost connections.  Response time for each hit/visit was 0.05 seconds. VPS withstood 49.99 hits/visits per second.

VPS 2: Nginx FastCGI Cache Test with Seige:

Test 1: siege -c50 -d10 -t3M – 50 concurrent users/hits per second

Screenshot_13

Test 1 Breakdown: 1,745 total hits/visits within a 3 minute duration with 100% availability and no lost connections.  Response time for each hit/visit was 0.04 seconds. VPS withstood 9.71 hits/visits per second.

Test 2: siege -c100 -d10 -t3M – 100 concurrent users/hits per second

Screenshot_14

Test 2 Breakdown: 3,450 total hits/visits within a 3 minute duration with 100% availability and no lost connections.  Response time for each hit/visit was 0.05 seconds. VPS withstood 27.70 hits/visits per second.

Test 3: siege -c255 -d10 -t3M – 255 concurrent users/hits per second

Screenshot_15

Test 3 Breakdown: 8,940 total hits/visits within a 3 minute duration with 100% availability and no lost connections.  Response time for each hit/visit was 0.05 seconds. VPS withstood 49.77 hits/visits per second.

Seige Test Comparisons

Test 1: Redis Object Cache

  • 50 concurrent users = 1749
  • 100 concurrent users = 3515
  • 255 concurrent users = 8988

Test 2: Nginx FastCGI Cache

  • 50 concurrent users = 1745
  • 100 concurrent users = 3450
  • 255 concurrent users = 8940

Differences between the 2 tests:

  • 50 concurrent users = 4
  • 100 concurrent users = 65
  • 255 concurrent users = 48

Leave a Reply