NGINX stale-while-revalidate cluster

[Maxim Dounin]

Hello!

On Sat, Jul 08, 2017 at 10:28:54PM +0200, Joan Tomàs i Buliart wrote:

> Hi Peter,
> 
> 
> yes, it's true. I will try to explain our problem better.
> 
> We provide a mobile solution for newspaper and media groups. With this 
> kind of partners, it is easy to have a peak of traffic. We prefer to 
> give stale content (1 or 2 minutes stale content, not more) instead of 
> block the request for some seconds (the time that our tomcat back-end 
> could expend to crawl our customers desktop site and generate the new 
> content). As I tried to explain in my first e-mail, the 
> proxy_cache_background_update 
> <http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_background_update> 
> works ok while the number of servers is fix and the LB in front of them 
> does a URI load balancer.
> 
> The major problem appears when the servers has to scale up and scale 
> down. Imagine that the URL1 is cache by server 1. All the request for 
> URL1 are redirected to Server1 by the LB. Suddenly, the traffic raise up 
> and a new server is added. The LB will remap the request in order to 
> send some URLs to server 2. The URL1 is one of this group of URL that 
> goes to server 2. Some hours later, the traffic goes down and the server 
> 2 is removed. In this situation, the new request that arrive to Server 1 
> asking for URL1 will receive the version of some hours before (not some 
> minutes). This is what we are trying to avoid.

This situation is exactly why "stale-while-revalidate=<time>" has 
the "=<time>" in it: to only allow stale content for some limited 
time.  If the response is more stale than the specified time, it 
is not used, and the request is passed to the upstream server 
instead.  That is, the version of some hours before will not be 
returned, exactly as you want to.

Similar behaviour can be achieved by using the "inactive=" 
parameter of the proxy_cache_path directive (for example, when 
using "proxy_cache_use_stale updating").  Responses which were not 
requested (and hence not updated) for the specified time will be 
removed from cache, and so won't be returned in such situation.  
This is slightly less flexible though, as you can't control the 
time on a per-response basis.

-- 
Maxim Dounin
http://nginx.org/