STALE responses taking as much as MISS responses

Joan Tomàs i Buliart joan.tomas at
Tue Feb 12 18:31:28 UTC 2019


after applying tcp_nopush off, the test that we have in place is working as
expected. The problem is that this improvement is not happening on
Our production environment is mainly a CDN -> NGinx -> Origin. We want to
use Nginx in order to control the eviction time of the content (our use
case needs a long stale-while-revalidate time and CDN priorizes fresh
content instead of stale). Our CDN give us the latency of our NGINX and
after apply the change, we are not able to see any improvement. We have
decided to put an ELB in front of Nginx, just to have another way to
measure, and we can see the same behaviour.
Could you give us any clue to discover what it is happening?

On the other hand, we saw that $request_time, when STALE, is the time to
refresh the cache, not the time to return the STALE content. Could somebody
confirm this? Which could be the metric to measure the real "latency" from
the user point of view (in our case CDN)?

Many thanks for your help!!

On Tue, 12 Feb 2019 at 13:07, Reinis Rozitis <r at> wrote:

> > X-MShield-Cache-Status: STALE
> > 0.004329:0.000000:0.004364:0.000000:0.212526:0.212644
> I see according to the timings you hit the 200ms tcp_nopush delay.
> Try setting tcp_nopush off;
> For more explanation you can read up
> rr
> _______________________________________________
> nginx mailing list
> nginx at

[image: Inline image 2] <>
Joan Tomàs-Buliart
ES: (34) 93 178 59 50
US: (1) 917-341-2540 <%281%29%20917-341-2540%20ext.%20107>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: badge-and-logo.png
Type: image/png
Size: 10663 bytes
Desc: not available
URL: <>

More information about the nginx mailing list