NGINX stale-while-revalidate cluster
mdounin at mdounin.ru
Mon Jul 10 12:07:58 UTC 2017
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
> 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.
More information about the nginx