Nginx fastcgi cache HIT vs STALE

cachenginx

I have strange problem with nginx microcache. When nginx serve STALE content, it takes too long.
My actual microacha part in config:

...
fastcgi_cache biznisto.sk;
fastcgi_cache_bypass $skip_cache;
fastcgi_cache_key "$scheme$request_method$host$request_uri$rt_session";
fastcgi_cache_valid 200 301 302 5m;
fastcgi_cache_use_stale updating error timeout invalid_header http_500;
fastcgi_cache_lock on;
fastcgi_cache_revalidate on;
fastcgi_cache_background_update on;
fastcgi_pass_header Set-Cookie;
fastcgi_pass_header Cookie;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
add_header X-Cache $upstream_cache_status;
...

Screens
STALE – wait 565ms

HIT – wait 59ms

Any suggestions?
Thanks

Best Answer

The fastcgi_cache_background_update directive allows updating an expired cache item while the stale cached response is being returned to the client.

If, however, the response is fully returned, but updating is not yet finished, it will delay subsequent actions, including processing of additional requests on the same connection, and/or the closing of the connection.

This behaviour ensures that:

a client cannot impose uncontrolled load on the server, assuming various limitations like limit_conn are in place
the overall operation is usually better and, in the worst case, is not worse than without background update.

https://trac.nginx.org/nginx/ticket/1329

Correct way in new versions of nginx

Turn out my first answer to this question was correct at certain time, but it turned into another pitfall - to stay up to date please check Taxing rewrite pitfalls

I have been corrected by many SE users, so the credit goes to them, but more importantly, here is the correct code:

server {
       listen         80;
       server_name    my.domain.com;
       return         301 https://$server_name$request_uri;
}

server {
       listen         443 ssl;
       server_name    my.domain.com;
       # add Strict-Transport-Security to prevent man in the middle attacks
       add_header Strict-Transport-Security "max-age=31536000" always; 

       [....]
}

Nginx Stale Cache and proxy_cache_path

Turns out that this is not currently possible with Nginx. I ended up setting up Varnish with a long TTL (7 days) as well as a long grace setting (2 days). I then have a script hit each URL every few days and force a warming of the cache.

Given the amount of content that I need to cache, and how infrequently each item is accessed, I was at first concerned that the cost of running Varnish would be prohibitive (all that RAM!) -- which is why I was looking at Nginx's file based caching. However, Varnish does indeed have a file backed caching option that has been working very well for me. So far my cache is about 80GB and performing very nicely!

Best Answer

Related Solutions

NGINX Redirect – How to Rewrite All HTTP Requests to HTTPS While Maintaining Sub-Domain

Correct way in new versions of nginx

Nginx Stale Cache and proxy_cache_path

Related Topic