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 theby royteeuwen - Nginx Development
Hey Maxim, 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 thoughby royteeuwen - Nginx Development
Hey, We are using NGINX as a proxy / caching layer for a backend application. Our backend has a relatively slow response time, ranging between the 100 to 300ms. We want the NGINX proxy to be as speedy as possible, to do this we have implemented the following logic: - Cache all responses for 5 mins (based on cache control headers) - Use stale cache for error's on the backend - Do a background uby royteeuwen - Nginx Development
When using the nginx proxy cache, you have the option to set the cache lock, see http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_lock The downside of this is, that once the cache is locked, there is a polling for subsequent requests to wait for 500ms before checking if the cache lock has expired. There is a "workaround" by just setting the cache lock timeout onby royteeuwen - Ideas and Feature Requests