Configurable sleep period for connections

Maxim Dounin mdounin at
Fri Mar 24 10:18:01 UTC 2023


On Fri, Mar 24, 2023 at 09:24:25AM +0100, Roy Teeuwen wrote:

> You are absolutely right, I totally forgot about the cache_lock. 
> I have listed our settings below.
> The reason we are using the cache_lock is to save the backend 
> application to not get 100's of requests when a stale item is 
> invalid. Even if we have use_stale updating, we notice that only 
> the first request will use the stale item, the following 
> requests will do a new request even though there is already a 
> background request going on to refresh the stale item. (This 
> does not happen if we set keepalive to 0, where new connections 
> are being used, but has the performance degradation as 
> mentioned.) This was the reasoning for the cache_lock, but that 
> gives the issue about the 500ms lock, while the item might 
> already be refreshed after 100ms.

To re-iterate: proxy_cache_lock is not expected to affect requests 
if there is an existing cache item (and keepalive shouldn't affect 
proxy_cache_lock in any way; not to mention that the "keepalive" 
directive, which configures keepalive connections cache to 
upstream servers, does not accept the "0" value).

You may want to dig further into what actually happens in your 
configuration.  I would recommend to start with doing a debug log 
which shows the described behaviour, and then following the code 
to find out why the cache lock kicks in when it shouldn't.

Maxim Dounin

More information about the nginx-devel mailing list