[PATCH 0 of 5] cache patches
Maxim Dounin
mdounin at mdounin.ru
Mon Dec 12 10:00:02 UTC 2011
Hello!
On Mon, Dec 12, 2011 at 12:07:25AM +0000, António P. P. Almeida wrote:
> On 11 Dez 2011 16h01 WET, mdounin at mdounin.ru wrote:
>
> Hello Maxim,
>
> > Hello!
> >
> > Here are patch series which addresses several issues in cache
> > (first 3 patches), and adds cache lock support (last 2).
> >
> > I'm planning to commit first 3 patches shortly, cache lock patches
> > will remain experimental for a while. Review and testing
> > appreciated.
>
> I will. If I understood correctly the later two patches implement a
> locking mechanism so that if /foobar is not cached and there are 5
> requests for foobar in time interval below the cache lock timeout then
> only the first request goes upstream the other requests are queued and
> are served up when the upstream returns a response.
Yes.
>
> Example:
>
> location /foobar {
>
> # usual proxy cache stuff...
>
> proxy_cache_lock on;
> proxy_cache_lock_timeout 500; # the default, can be tweaked
The default for proxy_cache_lock_timeout is "5s".
> proxy_pass http://my_upstream;
> }
>
> 1. Request for /foobar comes in at t=0
>
> 2. Additional request for /foobar comes in at t=200ms
>
> 3. Additional request for /foobar comes in at t=220ms
>
> Requests 2 and 3 are queued by the cache manager. Request 1 is
> forwarded upstream. When a response arrives, requests 2 and 3 are
> served.
In the above scenario, request (2) will be served at t=700ms
(500ms after request) and request (3) will be served at t=720ms.
This is because right now requests use periodic timer (each 500ms)
to see if response arrived.
If a response doesn't arrive at all, at 5s200ms (after
proxy_cache_lock_timeout) request (2) will be allowed to go to
upstream, and at 5s220ms request (3) will be allowed to go to
upstream. That is, proxy_cache_lock_timeout is a per-request
safeguard timeout.
> For the moment the cache entries that are updating will use the
> current 'proxy_cache_use_stale updating' setting.
Yes.
Maxim Dounin
More information about the nginx-devel
mailing list