Hi, Upon further testing, it appears the problem exists even with proxy_cache'd files with "proxy_cache_lock on".
(Please consider this a serious bug, which I'm surprised hasn't been detected before; verified on recently released 1.7.2) On Jun 24, 2014, at 8:58 PM, Paul Schlie <[email protected]> wrote: > Again thank you. However ... (below) > > On Jun 24, 2014, at 8:30 PM, Maxim Dounin <[email protected]> wrote: > >> Hello! >> >> On Tue, Jun 24, 2014 at 07:51:04PM -0400, Paul Schlie wrote: >> >>> Thank you; however it appears to have no effect on reverse proxy_store'd >>> static files? >> >> Yes, it's part of the cache machinery. The proxy_store >> functionality is dumb and just provides a way to store responses >> received, nothing more. > > - There should be no difference between how reverse proxy'd files are > accessed and first stored into corresponding temp_files (and below). > >> >>> (Which seems odd, if it actually works for cached files; as both >>> are first read into temp_files, being the root of the problem.) >> >> See above (and below). >> >>> Any idea on how to prevent multiple redundant streams and >>> corresponding temp_files being created when reading/updating a >>> reverse proxy'd static file from the backend? >> >> You may try to do so using limit_conn, and may be error_page and >> limit_req to introduce some delay. But unlikely it will be a >> good / maintainable / easy to write solution. > > - Please consider implementing by default that no more streams than may > become necessary if a previously opened stream appears to have died (timed > out), as otherwise only more bandwidth and thereby delay will most likely > result to complete the request. Further as there should be no difference > between how reverse proxy read-streams and corresponding temp_files are > created, regardless of whether they may be subsequently stored as either > symbolically-named static files, or hash-named cache files; this behavior > should be common to both. > >>> (Out of curiosity, why would anyone ever want many multiple >>> redundant streams/temp_files ever opened by default?) >> >> You never know if responses are going to be the same. The part >> which knows (or, rather, tries to) is called "cache", and has >> lots of directives to control it. > > - If they're not "the same" then the tcp protocol stack has failed, which is > nothing to do with ngiinx. > (unless a backend server is frequently dropping connections, it's > counterproductive to open multiple redundant streams; as doing so by default > will only likely result in higher-bandwidth and thereby slower response > completion.) > >> -- >> Maxim Dounin >> http://nginx.org/ >> >> _______________________________________________ >> nginx mailing list >> [email protected] >> http://mailman.nginx.org/mailman/listinfo/nginx > > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
