Issue Nginx Caching - x-cache-status: BYPASS (working but not serving from cache)

[Laurence@]

Upgraded a server to 17.8 to test the new microcaching. When I look a page with browser dev tools I see x-cache-status: BYPASS. I believe this indicates caching is active but the page is not being served from the cache. Tested on a bunch of pages with the same result. Frustrating.

Any ideas?

 

[Brujo]

have you seen this thread it is also about BYPASS Nginx microcache configuration for high traffic sites

 

[Laurence@]

Great. What a complete letdown. I wonder when we will ever have a decent caching solution with Plesk. Can't use the Varnish/Docker solution as Docker doesn't support CloudLinux. LSCache from LiteSpeed is overpriced. FastCGI_Cache no worky reverse proxy. So so so so so disappointing.

 

[IgorG]

@Laurence@ What about Redis?

 

[Laurence@]

Hi Igor,

Redis does work and it's pretty simple but it's not an out-box-solution. For Wordpress hosting it requires the Redis Page Cache plugin. Which is fine. It does also require symlinking the advanced-cache.php from inside the plugin folder to wp-content which of course requires SSH access. I guess we could instruct clients to just copy the file over but also that would need to be done every time the plugin was updated.

 

[Laurence@]

@IgorG So I'm leaning towards just using pure Nginx with PHP-FPM. If using this server config surely it should be easy to activate fastcgi_cache for all domains? Any tutorial for that?

 

[trialotto]

Hi Igor,

Redis does work and it's pretty simple but it's not an out-box-solution. For Wordpress hosting it requires the Redis Page Cache plugin. Which is fine. It does also require symlinking the advanced-cache.php from inside the plugin folder to wp-content which of course requires SSH access. I guess we could instruct clients to just copy the file over but also that would need to be done every time the plugin was updated.

Essentially, Redis can work for PHP over Memcached connectors, making it a bit more easy and a bit more reliable than the result of the dodgy Redis plugins for WordPress.

Furthermore, Redis support can be compiled into Nginx and that has an additional value: (native) Nginx caching is disk based, Nginx + Redis caching is memory based.

Nevertheless, using Redis for any WordPress instance would be rather an overkill: it simply is not required, one can suffice with Memcached.

In summary, just keep in mind the following:

- use Memcached for WP instances, if and only if necessary, valuable and required,
- use (disk based) Nginx caching for WP instance, but not for the WP admin panel,
- activate OPCache for PHP (if it is not activated yet, it should be).

Finally, note that any form of caching increases the attack surface: caching creates additional security risks.

By the way, Redis is NOT "pretty simple": configuring a Redis server instance properly is highly technical and associated with many pitfalls, meaning that any suboptimal Redis configuration can reduce the value of the Redis cache considerably.

Regards!

 

[Laurence@]

So I've been doing some extensive testing. Two domains, same wordpress theme, same server.

First of all, this new Nginx cache. In Nginx settings if you deactivate the 3 options in "Return stale cached records" you will be on pure fastcgi_cache (Nginx) or proxy_cache (Nginx/Apache).

On one domain I put no Nginx cache, ran Nginx as proxy and installed Redis Page Cache. On the other domain I tested the page with just fastcgi_cache and proxy_cache. Not that "use_stale" nonsense.

The speed increase with Nginx cache was negligible. I averaged 950ms.

The site with Redis Page Cache average 730ms.

You'd think fastcgi/proxy_cache would be faster. It's slower than WP Super Cache and W3TC. Disappointing.

 

[trialotto]

@Laurence@

I like the fact that you do some extensive testing and comparison. Nice!

However, there are some things to note.

The statement

The speed increase with Nginx cache was negligible. I averaged 950ms.

The site with Redis Page Cache average 730ms.

is as expected: Redis (memory based caching) is always faster than any type of disk based caching, such as Nginx caching.

The statement

You'd think fastcgi/proxy_cache would be faster. It's slower than WP Super Cache and W3TC. Disappointing.

is not a complete conclusion: this is simply due to the facts that (amongst others)

1 - nobody would think that disk based caching (such as proxy_cache) would be faster (certainly not in comparison to memory based caching)

2 - the WP plugins WP Super Cache and W3TC are doing much more than caching, but everything is done at the Apache level

3 - doing everything at the Apache level is essentially ineffective, making the before mentioned WP plugins not the best solution to increase performance: it is possible to replicate almost all settings of W3TC and WP Super Cache at the Nginx level and that is more performant than using the plugins themselves

4 - when having Nginx set to serving static files directly, huge parts of W3TC and WP Super Cache essentially become ineffective: Nginx is bypassing requests

5 - plugins like W3TC and WP Super Cache rely heavily on specific techniques like compression, which is not a good thing for speed of serving requests (!)

6 - plugins like W3TC allow for activation for memcache: if activated, this gives your comparison bias since W3TC contains a memory based caching solution

7 - plugins like W3TC and WP Super Cache require a whole lot of resources: in order to increase performance, there is a significant performance penalty (odd!)

8 - there is NO plugin that can help to increase the performance of a badly coded site

and so on.

In general, there are some rules of thumb:

A - use plugins like W3TC and WP Super Cache, since they are convenient, even though they are NOT the most optimal solution for performance objectives,

B - make sure your site or application is perfectly and efficiently coded,

C - try to implement minification of css and js: in the site or application and NOT by using some kind of plugin,

D - do not focus on TTFB,

E - implement Nginx and assign most of the tasks executed by W3TC or WP Super Cache to Nginx: translate to Nginx directives and deactivate the W3TC or WP Super Cache plugin and you will see a gain in performance.

Hope the above helps and explains a bit.

Kind regards............

 

[Laurence@]

I was just putting W3TC etc as a comparison. By far the fastest solution I have found so far is the Redis Page Cache plugin (with Redis installed obviously). I was just hoping that fastcgi/proxy_cache would be as fast

 

[trialotto]

I was just putting W3TC etc as a comparison. By far the fastest solution I have found so far is the Redis Page Cache plugin (with Redis installed obviously). I was just hoping that fastcgi/proxy_cache would be as fast

In theory, there should not be a huge difference, as long as the requested page is already cached.

The above implicitly means that some tweaking and fine-tuning of Nginx cache would result in a considerable performance increase.

However, that would also require some manual tweaks of Nginx as a whole, since the out-of-the-box Nginx (as shipped with Plesk) is more or less doing the work required, but that work is not done in the most optimal way: adding some Nginx modules, adding some Nginx directives and/or tweaking config helps.

In summary, there is the "theory" (read: it should not make a difference) and the "practice" (read: Plesk and/or default Nginx have their limitations, alternatives can hence make a considerable contribution to performance).

Finally, note that Redis in essence is a hybrid form of caching: depending on the configuration, some of the requests are served from memory and other requests are being served from a disk based form of cache, implying that a default Redis config often is sufficient AND that Redis tweaking can also improve performance a lot.

Kind regards........

 

[Laurence@]

@trialotto thanks for the input. Do you have any resources you could point me to in regards to fine tuning Nginx?

 

[trialotto]

@Laurence@

The most complete and correct set of documents can be found on the site of Nginx, see this page to start with.

However, nowadays the documentation of Nginx (open source) and Nginx Plus are combined into one set of docs: be aware that all Nginx Plus directives do not work in Plesk.

In order to understand the Nginx logic, it is probably meaningful to read this page on DigitalOcean: it is old documentation, but it is still fine (other pages might not be).

Finally, when changing something in Plesk, always keep in mind that

a) you make sure that you did a configtest first by running the command nginx -t

b) any reload of Nginx config does not require a Nginx restart, but the simple command: nginx -t && service nginx reload (again, we want to do a configtest first!)

c) Plesk has it's own config structure, implying that it is not always possible to effectuate specific Nginx directives at specific locations (work-around can be required)

d) Plesk's config structure is templated, in the sense that manual adjustment of Nginx config files for specific domains will be overwritten sooner or later

e) Plesk's config template for Nginx configuration can be customized: the Nginx template can be replaced by your own custom template (this is for the future, just noting it!)


Hope the above helps a bit......

..... kind regards!

 

[Laurence@]

I was just hoping that someone on this forum had already done the heavy lifting and there was an easy walkthrough somewhere. Due to how Plesk overwrites anything not templated I think it would be risky to travel into that uncharted territory.

 

[Laurence@]

Been playing around with it and added all cookies and still getting a BYPASS.

Request Headers:

Accept text/html,application/xhtml+xm…plication/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate, br
Accept-Language en-US,en;q=0.5
Authorization Basic YmxvZ2Rldjo0cnMkemVCbG5kVmY4QTVr
Cache-Control max-age=0
Connection keep-alive
Host wordpress.hostnexus.com
Upgrade-Insecure-Requests 1
User-Agent Mozilla/5.0 (Windows NT 10.0; …) Gecko/20100101 Firefox/61.0

Add cookie exceptions that were still showing up. Had to remove some plugins to get the above. But still a BYPASS. On a clean WP install I can get a HIT but this is a staging site for a real blog.

 

[Laurence@]

Further has revealed that I'm now getting a HIT in Chrome, but a BYPASS in FireFox. Seems due to the way the different browsers handles the Vary header. Found it discussed in varnish:

Varnish acts differently on different browser, why?

So looks like an Nginx config issue.

 

[Laurence@]

Furthermore, Redis support can be compiled into Nginx and that has an additional value: (native) Nginx caching is disk based, Nginx + Redis caching is memory based.

I'm confused by this reply. Nginx cache is loaded from the disk but stored and served from memory. It should not be slower than Redis?

 

[trialotto]

I'm confused by this reply. Nginx cache is loaded from the disk but stored and served from memory. It should not be slower than Redis?

There is a simple difference: Nginx (native) caching just serves (static) files from a disk, whereas Nginx with Redis caching (read: Nginx has been compiled with a connector that allowes to serve requests from the Redis server, that stores data in memory) just serves (static) data (read: both files and key-value pairs) from memory (through a connector).

 

[Laurence@]

But that's not true at all. Nginx serves content from memory.

Cache Placement Strategies for NGINX and NGINX Plus

Where is Cached Data Stored?
NGINX and NGINX Plus utilize a hybrid disk‑and‑memory cache. Whether the cache is on disk, in SSD, or elsewhere, the operating system page cache brings a cached item into main memory when it’s requested.

 

[trialotto]

@Laurence@

This statement

But that's not true at all. Nginx serves content from memory.

is not exactly hitting the truth.

First of all, there is Nginx Plus, a commercial version that behaves entirely different than the Open Source variant of Nginx, as shipped with Plesk.

Second, Nginx (read: both versions of Nginx) essentially uses memory to store all config, including metadata as specificied by proxy_cache_path directives (i.e. the keyzones).

Third, there is this thing about Nginx documentation: most of it is written for Nginx Plus, you are citing an article that is applying to Nginx Plus, not fully to Nginx Open Source.

Fourth, page content can and will only be served from memory, if and only if the Nginx config is proper: limiting the cache size can result in the desastrous result that every request will be served from disk cache (and often a Nginx conf mistake is made that will essentially Nginx caching ineffective, in the sense of "not working").

Fifth, Nginx Plus is not shipped with Plesk and across various versions of Plesk, various versions of Nginx Open Source are present (and each of these Nginx versions has a different set of capabilities with respect to caching, depending on the directives included at compilation time).

Sixth, Nginx Open Source and Nginx Plus will not often and/or not (at all) serve requests from cache, if the request uri contains variable request parameters (read: version strings or other parameters that vary across requests): if the request is not "sanitized", Nginx will just see it as a new request, hence not serving the request from cache.

And so on.....

Note that you can test the degree in which Nginx Open Source makes use of memory based caching of page content by creating one huge testpage and caching it, by just requesting the (huge) page multiple times after Nginx has been set up properly: if everything is working properly, you should see an increase in the memory used by Nginx.

But do not bother to execute this test, since the result will often be the same in almost all cases: Nginx does not serve the request from memory.


A final remark and tip: if you want to get the most out of Nginx and/or Nginx caching, just choose between the following alternatives

1 - use Plesk version 17.8.11, a Plesk version that ships with functionality to setup caching for Nginx Open Source (version 1.13.8, shipped with Plesk 17.8.11)

OR

2 - compile your own Nginx binary from the mainline version repository

and alternative two is the preferred one.

Naturally, the recommend alternative is to buy the (very expensive) commercial subscription on Nginx Plus. It really is worth it, but it does not "fit" nicely into Plesk.

Regards..........