I'm going to try to and create an integration test for it so that I can show the setup doing the unexpected 500ms locking for stale+1 requests. I can then set the debug level and if I can't figure it out I will post back here with the integration tests.

The reason I posted on the devel list was because I wanted to adjusted the 500ms lock / sleep period to be configurable, but seeing as I made the wrong assumption it turned into a user discussion, sorry!

Greets,
Roy

> On 27 Mar 2023, at 02:25, u5h <u5.horie@gmail.com> wrote:
>
> Hi, I had a same issue in those days.
> Did you try the proxy_cache_lock_timeout?
>
> https://forum.nginx.org/read.php?2,276344,276349#msg-276349
>
> But the below article said if you reduce simply the once busy loop time, it may not resolve this problem for which based on the nginx event notification mechanism in case it has many concurrently same content request.
>
> https://blog.lumen.com/pulling-back-the-curtain-development-and-testing-for-low-latency-dash-support/
>
> By the way, we might have been better to use nginx@mailing such a user level discussion.
>
> —
> Yugo Horie
>
> On Fri, Mar 24, 2023 at 19:18 Maxim Dounin <mdounin@mdounin.ru <mailto:mdounin@mdounin.ru>> wrote:
>> Hello!
>>
>> 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
>> http://mdounin.ru/
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel@nginx.org <mailto:nginx-devel@nginx.org>
>> https://mailman.nginx.org/mailman/listinfo/nginx-devel
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-devel

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel