• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question Nginx microcache configuration for high traffic sites

Émerson Felinto

Regular Pleskian
Screenshot 2018-03-18 at 08.45.32.png
What configuration do you usually use here? I have several WordPress sites and would like to enable caching globally for everyone. What is the safest setting?
Is there any additional configuration required for sites that use Cloudflare?
 
Hi,
I am with plesk 17.5 and I cant find where to enable micro caching. Is it somthing new to plesk 17.8?
 
Do you know why here is displaying "BYPASS"?
View attachment 14176
These are my nginx microcache settings.
View attachment 14175

Hello,
With micro-caching, Nginx only serve cache if the next upstream (Apache) is down. It provide a way to avoid error 502 bad gateway but it doesn't server a static version of your website if Apache is running properly.


Hi,
I am with plesk 17.5 and I cant find where to enable micro caching. Is it somthing new to plesk 17.8?

Yes, micro-caching is a new feature available on Plesk 17.8
 
With micro-caching, Nginx only serve cache if the next upstream (Apache) is down. It provide a way to avoid error 502 bad gateway but it doesn't server a static version of your website if Apache is running properly.
So what's the purpose of nginx microcache if it does not help save site resources ?

I had actually noticed that the "proxy_valid" directive was something like: proxy_valid "XXXXX" when it should actually be: proxy_valid 200 "XXXX".
 
So what's the purpose of nginx microcache if it does not help save site resources ?

I had actually noticed that the "proxy_valid" directive was something like: proxy_valid "XXXXX" when it should actually be: proxy_valid 200 "XXXX".

The main purpose of microcaching is to reduce downtime by serving cache each time the next upstream is down. So in case of high-traffic, if Apache timeout or isn't able to answer to a request, Nginx will use micro-caching instead of displaying a 502 Bad Gateway.
During Let's Encrypt renewal, it will also avoid this error.
 
That does not make much sense.
In my plesk it is written "nginx cache". This type of cache is very strange.

Nginx proxy_cache can be used to do serve static content from another upstream. I'm using it on my blogs running with Ghost but it require to exclude all URLs you do not want to cache or to use cookies to bypass the cache. Otherwise, Nginx will directly serve cache content until it expire.
Here the configuration I use with Ghost (cache expiration set to 10 minutes) :
Code:
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=STATIC:75m inactive=24h max_size=512m;
server {


    server_name yourwebsite.tld www.yourwebsilte.tld;

   root /var/www/yourwebsite.tld/system/nginx-root;

  access_log /var/log/nginx/yourwebsite.tld.access.log rt_cache_redis;
  error_log /var/log/nginx/yourwebsite.tld.error.log;
 
  add_header X-Cache-Status $upstream_cache_status;

    location / {
        proxy_cache STATIC;
        proxy_cache_valid 200 10m;
        proxy_cache_valid 404 1m;
        proxy_ignore_headers X-Accel-Expires Expires Cache-Control;
        proxy_ignore_headers Set-Cookie;
        proxy_hide_header Set-Cookie;
        proxy_hide_header X-powered-by;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:2368;
        expires 10m;
    }
    location ~ ^/(?:ghost|signout) {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://127.0.0.1:2368;
        add_header Cache-Control "no-cache, private, no-store, must-revalidate, max-stale=0, post-check=0, pre-check=0";
    }

Plesk micro-caching configuration use the directive proxy_cache_use_stale which allow nginx to server content from cache only for the following upstream status (http_500 http_502 http_503 http_504 updating) :
Code:
        add_header X-Cache-Status $upstream_cache_status;
        set $no_cache "";

        set $cache_cookie $http_cookie;

        if ($cache_cookie !~ "^\s*$") {
                set $no_cache 1;
        }

        location / {
                proxy_pass https://XXX.XXX.XXX.XXX:7081;
                proxy_set_header Host             $host;
                proxy_set_header X-Real-IP        $remote_addr;
                proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
                proxy_set_header X-Accel-Internal /internal-nginx-static-location;
                access_log off;

               proxy_cache_key "$scheme$request_method$host$request_uri";

                proxy_no_cache $no_cache $http_pragma $http_authorization $arg_nocache;
                proxy_cache_bypass $no_cache $http_pragma $http_authorization $arg_nocache;

                proxy_cache yourwebsite.tld_proxy;
                proxy_cache_valid "5";
                proxy_cache_use_stale http_500 http_502 http_503 http_504 updating;
                proxy_cache_background_update on;
        }
 
Yes, I understand that it is possible to use custom rules, but the default configuration of Plesk is meaningless. They promised a major update in March on performance. Yeah, it's all marketing.
 
Yes, I understand that it is possible to use custom rules, but the default configuration of Plesk is meaningless. They promised a major update in March on performance. Yeah, it's all marketing.

Nginx cache configuration can be easily customized :
Enabling nginx caching
Apache and Nginx Settings

Plesk 17.8 is a major update on performance, especially for the Plesk web interface. But Nginx cache cannot be (fully) automatically configured & optimized by Plesk. For example, the static cache configuration used on my Ghost blogs require to use an external comments system and any modification on the website is visible 10 minutes later.
Using cache on a website is always making compromises between performance and dynamic features.
 
So, as it is written in the documentation, this feature only makes sense for popular blogs or news websites.
 
Last edited:
Plesk 17.8 is a major update on performance, especially for the Plesk web interface. But Nginx cache cannot be (fully) automatically configured & optimized by Plesk. For example, the static cache configuration used on my Ghost blogs require to use an external comments system and any modification on the website is visible 10 minutes later.
When we are talking about nginx microcache it is not necessary to put a big time like 10min. Only 15s for example already produces significant results. This is because when nginx needs to update the cache it requests from the machine itself (localhost connection) if it is properly configured.
For example, let's say that in one minute there are 10,000 requests on the server. In practice, with nginx microcache there are only 4 requests. This is because Nginx generates the cache only once and then delivers the cached page for the next requests. Even a value like 1s would have great effect. I really believe Plesk should put this as a default setting. It simply does not make sense. I think this setting will help to decrease the use of resources, when in practice it does not help at all.
 

Without load testing obviously :rolleyes:

I'm going to flip this thread an entire 360 and rant now about why you SHOULDN'T microcache;

Like @Tomek said earlier, It's useless on a site with just moderate traffic. You're also essentially wasting resources (CPU) with the constant re-cache of the page and simply; it doesn't handle dynamic content. Dare I say - It's useless with Wordpress? It literally takes a snapshot, a photo, of the site and serves it up to all viewers. Have different views for both desktop and mobile? Well, that's not pretty but we will save that rant for another day.
 
Back
Top