Hello!

On Mon, Jun 30, 2014 at 11:10:52PM -0400, Paul Schlie wrote:

> Regarding:
>
> > In http, responses are not guaranteed to be the same. Each
> > response can be unique, and you can't assume responses have to be
> > identical even if their URLs match.
>
> Yes, but potentially unique does not imply that upon the first valid ok or valid
> partial response that it will likely be productive to continue to open further such
> channels unless no longer responsive, as doing so will most likely be counter
> productive, only wasting limited resources by establishing redundant channels;
> being seemingly why proxy_cache_lock was introduced, as you initially suggested.

Again: responses are not guaranteed to be the same, and unless
you are using cache (and hence proxy_cache_key and various header
checks to ensure responses are at least interchangeable), the only
thing you can do is to proxy requests one by one.

If you are using cache, then there is proxy_cache_key to identify
a resource requested, and proxy_cache_lock to prevent multiple
parallel requests to populate the same cache node (and
"proxy_cache_use_stale updating" to prevent multiple requests when
updating a cache node).

In theory, cache code can be improved (compared to what we
currently have) to introduce sending of a response being loaded
into a cache to multiple clients. I.e., stop waiting for a cache
lock once we've got the response headers, and stream the response
body being load to all clients waited for it. This should/can
help when loading large files into a cache, when waiting with
proxy_cache_lock for a complete response isn't cheap. In
practice, introducing such a code isn't cheap either, and it's not
about using other names for temporary files.

--
Maxim Dounin
http://nginx.org/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx