Envoyé de mon smartphone BlackBerry 10. Message d'origine De: kmaxwilliam...@gmail.com Envoyé: vendredi 9 juin 2017 00:12 À: Astrat Goe; Tomcat Users List Objet: Re: Tomcat 8/NIO performance discrepancies
Gvhuf Envoyé de mon smartphone BlackBerry 10. Message d'origine De: Astrat Goe Envoyé: mercredi 7 juin 2017 21:29 À: Tomcat Users List Répondre à: Tomcat Users List Objet: Re: Tomcat 8/NIO performance discrepancies Ggfggthgd Vid > On Jun 8, 2017, at 4:28 AM, Mark Thomas <ma...@apache.org> wrote: > > On 07/06/17 20:25, Piyush Kumar Nayak wrote: >> Mark, >> >> It may not be important, but just to be clear, I'm not testing on localhost. >> My JMeter and Tomcat are on different machines, with 1 Gbps NIC interfaces >> between them. > > I'm aware you were using two machines but that doesn't appear to be a > significant factor in the observed differences. > >> Can you also please provide some pointers on the following: >> - How did you disable session on your JSP? > > Look in the index.jsp for the ROOT web application that ships with > Tomcat for an example. Full details are in the JSP specification. > >> - Did you observe anything that suggests that the client is not closing the >> connections? > > Yes. This looks like a JMeter issue. It isn't the first time JMeter has > given strange results under load. I've switched to ab which I have found > to be generally much more reliable for these sorts of tests. > > I'm still seeing significant differences in BIO with and without an > executor. > > I'm still looking for the root cause. I have noticed that without an > executor I see far fewer keep-alive requests than I'd expect. That could > explain the difference, or some of it at least. > > Mark > > >> I did not specify the implementation for the HTTP sampler that I configured >> with JMeter, and it is not set in my jmeter.properties file. So, going by >> JMeter's documentation, Apache HttpComponents HttpClient 4.x. should be in >> use. >> >> Thanks >> Piyush. >> >> -----Original Message----- >> From: Mark Thomas [mailto:ma...@apache.org] >> Sent: Wednesday, June 07, 2017 8:27 PM >> To: Tomcat Users List <users@tomcat.apache.org> >> Subject: Re: Tomcat 8/NIO performance discrepancies >> >> On 06/06/17 09:10, Piyush Kumar Nayak wrote: >>> Thanks, Mark. >>> >>> Here are some additional details. >> >> Thanks. These help a lot to make sure we are testing (at least roughly) the >> same thing. >> >>> I am using Apache JMeter to inject load. I am using a simple hello-world >>> JSP. >>> >>> The test JMX simulates 100 concurrent user threads with a ramp-up of 5 secs >>> and uses an HTTP Cookie Manager, that reuses cookies for each user thread. >> >> I've disabled session in the JSP for my test and used a simpler JSP. >> That should amplify any difference in connector performance. >> >> I'm also testing on localhost. >> >>> I have disabled access log in tomcat. All the other server.xml settings are >>> the default. >>> >>> >>> The BIO with Executor configuration we are using is: >>> <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" >>> maxThreads="150" minSpareThreads="4"/> >>> >>> <Connector port="8080" protocol="org.apache.coyote.http11.Http11Protocol" >>> connectionTimeout="20000" >>> redirectPort="8443" /> >> >> FYI for anyone following along. That is a non-executor config. The connector >> needs to specify the executor it wants to used. >> >> I do see odd behaviour with BIO + executor. It locks up very easily. It >> appears that the client isn't closing the connections. I don't see this >> problem with BIO but that may be related to how BIO without an executor >> handles large numbers of connections. >> >> If I lower the client thread count, the odd behaviour stops and I do see >> notably higher throughput with BIO + executor. That is unexpected. >> >> My initial thoughts are maybe a contention issue related to the thread pool. >> I'm continuing to investigate. I plan to look at performance first and then >> the locking up. >> >> Mark >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org