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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
