Symptoms
After enabling cPanel's NGINX Caching feature on your server, you have found the results to be disappointing, or you cannot see any difference in performance at all.
Description
Typically, this lackluster performance improvement after enabling cPanel's NGINX caching solution ends up being attributed to various configuration incompatibilities, or problems that were present before cPanel's NGINX feature was installed and enabled. This guide will go over some of the common causes for lackluster performance improvements, as well as some techniques that you can make use of to help diagnose the issue.
Diagnostic Tools
First, it is important to become familiar with some of the diagnostic tools available to you for these issues, as well as gain a basic understanding for when these tools would serve a purpose for your situation.
Enable the X-Cache-Status header
We have the following guide that outlines how you can enable the X-Cache-Status header:
How to add the X-Cache-Status header to NGINX
This header is immensely helpful for determining which of your requests are being cached, and which ones are not. This will probably be one of the first things to enable when troubleshooting performance issues with NGINX.
Enable debug logging
We have a guide for enabling debug logging in NGINX here:
Enable debug logging for NGINX
This would typically only be useful if you suspect that there is a legitimate problem with the NGINX configuration or some other deeper issue. If you're just experiencing performance issues, the debug logs are not likely to help much, but they could prove useful in some scenarios which is why it is mentioned here.
Measure Response Times with a Curl Write-Out format configuration
We have a guide that explains how you can use a write out configuration along with curl to gain a breakdown of the request timings for a URL:
How to use a curl formatter to diagnose slow websites
This can be very useful tool because it offers an objective measurement of how long it takes for a request to complete, in an easy to read format.
However, it is very important to understand the various components that make up the overall request time, also known as the TTFB or Time To First Byte. A common mistake made is to see a high overall request time and attribute it to being a problem with the server.
Based upon your server's specific configuration, the TTFB could be composed of many different parts, but this is a basic overview in most NGINX cases.
- The time it takes for the request to travel from your computer and arrive at the server - NETWORK
- The time it takes for NGINX to process the request and either serve a cach, or proxy the request to Apache
- ( If Proxied ) The time it takes for Apache to process the request and either send NGINX the content, or send the request to PHP or another script for processing.
- ( If processed by PHP or other scripting language ) The time it takes for PHP or the script to process the request, and if database calls are required, the time it takes to send the database request to the database for processing
- ( If database processing is involved ) The time it takes for the database to produce results
- The time it takes for PHP or the script to process the database results
- The time it takes for PHP to send the completed content back to Apache
- The time it takes for Apache to send the completed content to NGINX
- The time it takes for NGINX to process the content and send it to the network
- The time it takes for the data to travel from the server to the client - NETWORK
While a lot of those steps are performed on the server, the first and last steps, the NETWORK portion of the TTFB, are very often the biggest contributors to the overall TTFB when NGINX has served a cached document.
If you suspect that the network could be contributing to the performance issues, you could try using the curl formatter to request the domain from within your server and compare the results with a request made from a remote client. This, in most cases, will bypass most of the network. There can be caveats on some servers that would invalidate this kind of test, so care should be taken when evaluating the results of this kind of test based on your specific situation.
Make use of MTR to analyze the network connection
The MTR utility can at times provide valuable insight into network problems that may be contributing to the lackluster performance that you're experiencing. We have a couple of guides for this utility here:
How to use MTR to check the network behavior of a specific service
Common Configuration Problems That Contribute to NGINX Performance Problems
Below are some of the problems that we've encountered where a configuration problem was the cause of performance issues with NGINX.
The Expires header is configured to expire the cache too quickly
We have the following guide that explains how you may configure the Expires header with Apache's mod_expires module:
How to set Expires headers for your site on cPanel
We've found some cases where the Expires header was intentionally set to 1 second to avoid serving stale content.
The problem with this can be that if the Expires header is set too low, NGINX will not ever have a chance to serve a cached version of the site, which essentially nullifies it's purpose. If you set the X-Cache-Status header as described earlier in this article, and you find that most or all of your requests are showing EXPIRED, you should review the Expires configuration for the site.
Consideration should also be made for the fact that the Expires header can be set by the code of the site its self in addition to customizations to the NGINX configuration, or the Apache configuration.
The max-age request header as set by the client is not set properly
We've also found instances when benchmarking NGINX, the max-age request header was set incorrectly which was invalidating the NGINX cache, and therefore was severely hurting performance.
While this is not likely to happen in a real world setting, this is something to keep in mind when benchmarking NGINX.
Other Common Issues That Contribute to Poor Performance
Firewall or General Network related issues
As this was touched on earlier in the section about using the curl formatter to test response times, it is very common for the network between the server, and the client to introduce unwanted delays into the response.
Firewall configurations can also potentially ratelimit traffic, or altogether block it, causing performance issues.
Determining if the source of the performance issue is the network as opposed to something else can be difficult at times.
However as mentioned previously, one way to help diagnose network related issues would be to use the curl formatter technique mentioned earlier in this article to compare the response time of a request that is made from within the server via command line, to a request that is made by a remote client.
If you find that the response time is much greater when making the request from a remote location, it would be a strong indicator that the network could be a large contributor to the problem. Unfortunately NGINX is not capable of improving network responsiveness so you would need to contact your network provider, or a network administrator to further diagnose and resolve the issue.
You may also consider reviewing the results of a network trace generated by the MTR utility in an attempt to identify network latency problems as is mentioned earlier in this article.