Facebook
Twitter
-
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
- Thread starter Émerson Felinto
- Start date
Émerson Felinto
Regular Pleskian
Okay, feel free...
Émerson Felinto
Regular Pleskian
It's not just one site but multiple websites.
In terms of resource usage, what's better: Apache + Nginx or Apache + Nginx with microcache?
In terms of resource usage, what's better: Apache + Nginx or Apache + Nginx with microcache?
Émerson Felinto
Regular Pleskian
Yes, I already did this test with cPanel (see Engintron) and the result was fantastic.
Apache + Nginx with optimized microcache
Plesk does in my opinion a good job and give us a lot of posibility to manage the system out of the box in our hands, but performance and ressource tuning need some hands on, knowledge and for sure time too do....
Last edited:
I think that putting this as a default setting, it would be very dangerous.
What happens if someone installs a shopping cart?
Correct me if I'm wrong
Secondly, if I understood virtubox correctly, this mechanism only works in the moment when apache can not answer?
For example, when one page on the blog becomes viral and gets a lot of traffic from social media. Then this feature will help to handle this traffic?
Correct me if I'm wrong
What happens if I have an WP Super Cache or other caching plugin installed? In this case, using this feature will also be helpful?
Last edited:
It shouldn't bypass proxy with these caching settings. Need more info. Could you please provide more info, for example your vhost Nginx config (in PM)?
You're wrong. The main purpose of caching is always to reduce system load and increase responsibility by using upstream (and PHP) only once per defined period of time. Managing backend inaccessibility periods with stale cache records is just a good bonus.
Wrong again. proxy_cache_use_stale directive allows returning stale cache records (records with expired TTL) if upstream is inacsessible. When upstream is accessible, record is fetched from upstrean, then being returned from cache during TTL, then fetched from upstream again.
I have tried with the same settings and cache status is always BYPASS
Code:
content-encoding: br
content-type: text/html; charset=UTF-8
date: Wed, 21 Mar 2018 10:18:41 GMT
link: <https://XXX.xyz/index.php/wp-json/>; rel="https://api.w.org/", <https://XXX.xyz/>; rel=shortlink
ms-author-via: DAV
referrer-policy: strict-origin-when-cross-origin
server: nginx
status: 200
strict-transport-security: max-age=15799999;
vary: Accept-Encoding
x-cache-status: BYPASS
x-content-type-options: nosniff
x-frame-options: sameorigin
x-powered-by: PleskLin
x-robots-tag: noindex
x-xss-protection: 1; mode=blockBy checking my vhost, I have noticed the variable $no_cache isn't set to 0 initially :
Code:
set $no_cache "";
if ($request_uri ~* "/wp-admin/") {
set $no_cache 1;
}Sorry, I was thinking it was mostly used to avoid 502 bad gateway due to Apache. But in this case, it may require to customize nginx configuration for each website to avoid issues with cache. I'm not sure it's the easiest cache solution for Plesk users. Or it will be great to be able to set a list of cookies to bypass the cache, instead of cookies to cache.
Yes, after reading nginx doc again, you are right. I'm french, so the word "stale" wasn't explicit for me, but it make sense now.
Émerson Felinto
Regular Pleskian
Shopping cart usually uses cookies. Requests with cookies are not served from cache by default.
"" means the same as 0 in this case. Empty string returns false in if expression.
I see response headers only. Could you please provide request headers for this bypassed request?
Yes :
Code:
:authority: XXX.xyz
:method: GET
:path: /
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
cache-control: max-age=0
cookie: g5-collapsed={"particles.search.":false}; wordpress_test_cookie=WP+Cookie+check
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.45 Safari/537.36
XXX.xyz jquery.js?ver=1.12.4 autoptimize_5180077a0836686a332724c2abec7a4d.js wp-emoji-release.min.js?ver=4.9.4 favicon.icoPlesk Nginx caching doesn't allow serving requests with cookies from cache by default, because cookies suggests interaction with server backend. However, you may add a list of "safe" cookie names to appropriate field if you're absolutely sure using someone's cached answer for request with these cookies is safe for your users.
Last edited:
Laurence@
Regular Pleskian
Problem is 99% of sites use cookies. Therefore this Nginx caching is not going to work with most sites. Surely a switch to cache all that activates "proxy_ignore_headers" and then a field to add cookies not to ignore would be more useful? Most cookies can be cached. Just some cookies like those used on shopping carts should be excluded maybe?
I agree with you Laurence@ , it's really painful to list all "safe cookies" to allow Nginx cache.
I'm using Nginx proxy-cache with the blogging app Ghost and it cache everything with the directive "proxy_ignore_headers Set-Cookie;" expected the location /ghost (the same than /wp-admin on wordpress).
Here an example :
Code:
add_header X-Proxy-Cache $upstream_cache_status;
location / {
proxy_cache ghost;
proxy_cache_valid 200 30;
proxy_cache_valid 404 1m;
proxy_ignore_headers X-Accel-Expires Expires Cache-Control;
proxy_ignore_headers Set-Cookie;
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;
}
location /content/images {
alias /var/www/ghost.fr/htdocs/content/images;
try_files $uri$webp_suffix $uri =404;
access_log off;
expires max;
}
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_set_header Host $http_host;
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";
pagespeed standby;
}It should be possible to do something similar with WordPress, like :
Code:
set $no_cache "";
set $bypass_reason "";
# do not cache wordpress location
location ~ ^/(?:wp-admin|xmlrpc.php|wp-(login|register|mail).php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml) {
include proxy_params;
proxy_pass https://wordpress;
add_header Cache-Control "no-cache, private, no-store, must-revalidate, max-stale=0, post-check=0, pre-check=0";
set $bypass_reason "location";
}
# Bypass if it's a POST request
if ($request_method = POST) {
set $no_cache 1;
set $bypass_reason "POST request";
}
if ($http_cookie ~* "(wordpress_logged_in_|wp\-postpass_|woocommerce_items_in_cart|woocommerce_cart_hash|wptouch_switch_toogle|comment_author_|comment_author_email_)") {
set $no_cache 1;
set $bypass_reason "HTTP Cookie";
}Laurence@
Regular Pleskian
Where would you put that code? Little confused there.
But going back to the overall function, I don't understand why Plesk would add a cache that simply won't work on 99% of websites. Is it just marketing? "Hey we do microcaching (you just can't use it without a degree in computer science).
But going back to the overall function, I don't understand why Plesk would add a cache that simply won't work on 99% of websites. Is it just marketing? "Hey we do microcaching (you just can't use it without a degree in computer science).