> 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

Reply via email to