{"id":5443119,"date":"2023-04-11T12:32:49","date_gmt":"2023-04-11T10:32:49","guid":{"rendered":"https:\/\/wp-rocket.me\/?post_type=caching_hub&p=5443119"},"modified":"2023-05-10T15:40:09","modified_gmt":"2023-05-10T13:40:09","slug":"redis-full-page-cache-vs-nginx-fastcgi","status":"publish","type":"caching_hub","link":"https:\/\/wp-rocket.me\/wordpress-cache\/redis-full-page-cache-vs-nginx-fastcgi\/","title":{"rendered":"Redis Full-Page Cache vs NGINX FastCGI Cache for WordPress"},"content":{"rendered":"

Caching is the backbone of website speed and performance. It\u2019s critical to your WordPress site\u2019s success<\/a>. Even if your site is hosted on a hefty server, it\u2019ll come to a crawl if you don\u2019t have any caching enabled. Serving websites to tens of thousands of users per day is possible only because of smart caching techniques.<\/p>

In this article, I\u2019ll pit two distinct WordPress page caching solutions against one another. While NGINX FastCGI Cache<\/strong> is a tried and tested page caching veteran, Redis Full-Page Cache<\/strong> is relatively obscure.<\/p>

Who will come out on top and who will crumble under the load first? As you\u2019ll soon find out, they both have their pros and cons, but there\u2019s only one winner.<\/p>

Buckle up. Let\u2019s zoom in!<\/p>

WordPress Caching 101<\/h2>

WordPress requires many moving parts to work. Every time a user requests a page from a WordPress site, the request is first parsed by the server. If the server cannot serve the requested page readily, it\u2019ll process the relevant PHP scripts and assemble the page dynamically. Sometimes, this also involves querying the database to gather additional data.<\/p>

As a general rule, the longer the request has to travel, the slower the server\u2019s response. If there are a lot of concurrent users, the server can freeze trying to process all the parallel requests. <\/p>

Caching helps to speed up server response by storing and delivering previously processed requests. A server can deploy many caching layers to store distinct types of data.<\/p>

\"\"
Page Cache layer is closer to the users (Source: SpinupWP<\/a>)<\/figcaption><\/figure>

For PHP and database based applications such as WordPress, there are four major types of server-side caching solutions: Object Caching<\/strong>, Page Caching<\/strong>, Opcode Caching<\/strong>, and CDN Caching<\/strong>. You can read more about all of them in WP Rocket\u2019s in-depth article on object caching<\/a>.<\/p>

This article focuses on comparing page caching solutions, but I suggest you get familiar with the basics of object caching too.  <\/p>

Setting Up the Test Site and Server<\/h2>

I\u2019ll use a $10 standard droplet from DigitalOcean to conduct the tests. With a decent mix of memory and compute resources, it\u2019s a perfect server to test the WordPress site. The droplet configuration includes 2 GB RAM, 1 CPU, 50 GB SSD Storage, and 2 TB transfer.<\/p>

I\u2019ve installed the test WordPress site on a Debian-based LEMP stack<\/a> (Linux, NGINX, MariaDB and PHP 7.3). To stress the test site, I\u2019ve customized it to include a decent mix of static and dynamic elements using WooCommerce and Elementor.<\/p>

\"\u00a0The
 The test WordPress site used for page cache comparison<\/figcaption><\/figure>

I tested the base site with the GTmetrix website speed testing tool. As you can see from its test report, it\u2019s not yet optimized for performance.<\/p>

\"GTmetrix
GTmetrix report for the test site<\/figcaption><\/figure>

Stress Testing the Base Site with No Cache Enabled<\/h3>

I\u2019ll use a free performance testing tool called loader.io<\/a> to stress test the website. Their free tier allows you to test two URLs of any website with up to 10000<\/strong> concurrent clients for a minute. That\u2019s more than enough for our use case. <\/p>

Note:<\/strong> If you\u2019re wondering about the domain name, it\u2019s an unused personal domain. It\u2019s essential to have the site hosted on an actual domain to install an SSL certificate from a signing authority such as Let\u2019s Encrypt. With an SSL certificate installed, the site has to perform an HTTPS handshake for every unique client request. This mimics real-world usage better during the stress test.<\/p>

\"\"
Loader.io test results for the base site<\/figcaption><\/figure>

You can check the test parameters inside the orange box on the left side. Note the 0 to 200 clients over 1 min<\/strong> test parameter. This means that loader.io will stress test the website by slowly increasing the number of active clients from 0 to 100 over a 1 minute period. <\/p>

In the graph shown, the green line represents the number of concurrent clients and the blue line represents the average server response time. You can see that the response time creeps upwards as the number of clients increases. <\/p>

Loader.io aborted the test after 36 seconds as more than 50% of the requests weren\u2019t successful (a timeout or an HTTP 400\/500 error response). Also, the 17.33 seconds<\/strong> average response time doesn\u2019t bode well for the user experience either.<\/p>

Checking the Details<\/strong> tab will give you a better understanding of when the server timeouts start. You can see that it starts at the 25-second<\/strong> mark.  <\/p>

\"That\u2019s
That\u2019s a lot of 500 Internal Server Errors<\/figcaption><\/figure>

I ran the test again, this time limiting the number of concurrent clients to 100<\/strong>. The base site struggled to perform even under this minimal load.<\/p>

\"Repeating
Repeating the test with a max of 100 active clients<\/figcaption><\/figure>

The test ran for a full minute this time around, but the average server response time is still unacceptable. Every active user stresses the server more, which makes it respond slowly to all the other users. The server timeouts still persist.<\/p>

\"Server
Server timeouts persist as the number of active clients increases<\/figcaption><\/figure>

From the above graph you will notice that server timeouts start to occur at the 38 second<\/strong> mark in the test.<\/p>

\"There
There are 68 active clients at the 38 second mark<\/figcaption><\/figure>

Now you have a fair idea of how the base site performs when there are 100 and 200 active clients. It\u2019s time to perform the same tests with Redis Page Cache<\/strong> or NGINX FastCGI Cache<\/strong> enabled on the server.<\/p>

<\/div>\n\t