Hello!
On Wed, Sep 10, 2014 at 10:21:18AM -0400, nanochelandro wrote:
> Hello All,
>
> fastcgi_cache_use_stale is awesome, especially with "updating" parameter.
> But I have a feeling that it lacks a complementary parameter (or a separate
> setting to tune "updating" behaviour) that would instruct nginx to quickly
> return stale cached response also on first request (while fastcgi app is
> busy doing it's hard work). Currently existing behaviour is to return stale
> cached responses on consequent requests only, but first response is delayed
> until fastcgi finishes it's job.
>
> What do you think?
As of now, nginx needs a client request to be able to request a
resource from a backend and to save it to the cache. That is,
this behaviour is an implementation detail which isn't trivial to
change.
--
Maxim Dounin
http://nginx.org/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
On Wed, Sep 10, 2014 at 10:21:18AM -0400, nanochelandro wrote:
> Hello All,
>
> fastcgi_cache_use_stale is awesome, especially with "updating" parameter.
> But I have a feeling that it lacks a complementary parameter (or a separate
> setting to tune "updating" behaviour) that would instruct nginx to quickly
> return stale cached response also on first request (while fastcgi app is
> busy doing it's hard work). Currently existing behaviour is to return stale
> cached responses on consequent requests only, but first response is delayed
> until fastcgi finishes it's job.
>
> What do you think?
As of now, nginx needs a client request to be able to request a
resource from a backend and to save it to the cache. That is,
this behaviour is an implementation detail which isn't trivial to
change.
--
Maxim Dounin
http://nginx.org/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx