Hello,

While doing benchmarks in a configuration using proxy_cache and proxy_cache_lock, I noticed that many requests had a duration very close to 500ms.

Upon further analysis, I determined that a huge majority of these requests were actually HITs, and investigated to see where do the delay came from.

I currently suspect that this particular delay come from HITs that were delayed by proxy_cache_lock (i.e were waiting for an initial request to succeed and cache the object). I found support for this claim in the following code:
https://github.com/nginx/nginx/blob/master/src/http/ngx_http_file_cache.c#L449 (and 509).

Am I right in assuming the proxy_cache_lock is using a 500ms polling rate ? Are there any plans to move to an event-based mechanism ?

In our use-case (2s video fragments) this represents 25% of the segment duration, so it can be quite impacting, furthermore because this mechanism can act on several layers of caches. We're planning to try using a 10ms interval instead (replacing 500 by 10 in the 2 lines should suffice right ?) - but would it be interesting to make a real patch to have a configurable value ?

Is there another work-around ?

Thanks,
Best regards,
Aurélien