Hi, On Fri, Oct 27, 2017 at 09:24:01AM +0800, 安格 wrote: > Dear Roman, > > > Thanks for your valuable response. > So ,is that means, If we optimize the parameter of the keep-alive to avoid > keep-alive connection ? then we can avoid this kind of performance issue ? > Or if the mirror subrequest is slow than original subrequest, then we can't > avoid this kind of performance issue ? Thanks in advance.
It should be ok unless you wait for the (non-keepalive) client connection to be closed. It won't until the mirror subrequests are done. > > > -- > > > > Regards, > Yuan Man > Trouble is a Friend. > > > > At 2017-10-26 20:22:13, "Roman Arutyunyan" <a...@nginx.com> wrote: > >Hi, > > > >On Thu, Oct 26, 2017 at 03:15:02PM +0800, 安格 wrote: > >> Dear All, > >> > >> > >> I have faced a issue with Nginx "ngx_http_mirror_module" mirror function. > >> want to discuss with you about this. > >> > >> > >> The situation is like below: > >> While I try to copy the request form original to mirror side, if the > >> original application can process 600 request per seconds, but the mirror > >> environment can only process 100 requests per seconds. Normally, even the > >> mirror environment can't process all the request in time. it's should not > >> impact the nginx forward the request to the original environment. But we > >> observed if the mirror environment can't process all the request, then the > >> Nginx will fall in issue , and original environment can't feedback process > >> result to client in time. Then from client side, it seems the Nginx is > >> down. If you have faced same issue before ? any suggestion ? > > > >A mirror request is executed in parallel with the main request and does not > >directly affect the main request execution time. However, if you send > >another > >request on the same client connection, it will not be processed until the > >previous request and all its subrequest (including mirror subrequests) > >finish. > >So if you use keep-alive client connections and your mirror subrequests are > >slow, you may experience some performance issues. > > > >-- > >Roman Arutyunyan > >_______________________________________________ > >nginx mailing list > >nginx@nginx.org > >http://mailman.nginx.org/mailman/listinfo/nginx -- Roman Arutyunyan _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
