tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dimple ranka <dimplekra...@gmail.com>
Subject Re: Performance degrades on tomcat7 for the same runs of a sample performance 60 user test
Date Wed, 04 Nov 2015 04:24:26 GMT
Also forgot to mention that setting maxKeepAliveRequests to -1 did not
help. As expected from the connector documentation the default value for
this attribute is 100 and we have a 60 user test set up.

On Wed, Nov 4, 2015 at 8:18 AM, dimple ranka <dimplekranka@gmail.com> wrote:

> Hi Mark,
>
> Another observation to be noted here is that system CPU usage shoots up
> for subsequent runs, especially for later runs.
>
> We have been looking into this issue for couple of weeks now and it is
> clear in the same environment with the same setup it doesn't reproduce on
> tomcat6. The moment we deploy the web application in a tomcat7 container
> the slowness with subsequent runs shows up.
>
> Thanks,
> Dimple
>
> On Tue, Nov 3, 2015 at 2:36 PM, dimple ranka <dimplekranka@gmail.com>
> wrote:
>
>> Hi Mark,
>>
>> The test client is running on another machine.
>>
>> The server side test code is written using jersey 1.17.
>>
>> Will try out with playing with maxKeepAliveRequests.
>>
>> My only concern is that if jmeter is doing spoofy things then why it
>> doesnt show up on tomcat6.
>>
>> Thanks,
>> Dimple
>>
>> On Tue, Nov 3, 2015 at 2:27 PM, Mark Thomas <markt@apache.org> wrote:
>>
>>> On 03/11/2015 06:17, dimple ranka wrote:
>>>
>>> <snip/>
>>>
>>> > ##############################################
>>> > On tomcat7 number of requests fullfilled per second
>>> > ##############################################
>>> > * RUN1 ** ==> **  38128.97704918033 runs/sec*
>>> >  *RUN2 ==> **  19040.35947712418 runs/sec*
>>> >  *RUN3 ==> ** 19043.7908496732**  runs/sec*
>>> > * RUN4 ==> ** 19001.71568627451 runs/sec*
>>> > ##############################################
>>>
>>> Every performance test I have ever done with Tomcat, the first run has
>>> had poorer performance while the system warms up (threads started,
>>> caches filled, session ID generators initialised etc.) and subsequent
>>> tests have performed better.
>>>
>>> The results above suggest something about the test is broken.
>>>
>>> First of all, thank you for the detailed information. It helps a lot.
>>>
>>> Your server side test code won't run on Tomcat without additional
>>> libraries and configuration that you haven't specified. That makes it
>>> harder for people to reproduce your results. I'd recommend using a
>>> simple servlet for testing in the first instance and only when any
>>> issues have been resolved, move to your test.
>>>
>>> 20k requests/s is rather low. I'd expect those sorts of numbers from a
>>> single threaded test on reasonable hardware. With 8*2 threads to play
>>> with on the server I'd expect that number to be a lot higher.
>>>
>>> My experience of JMeter is that the results are unreliable as you
>>> approach the point where the overhead per request for JMeter approaches
>>> the overhead per request for Tomcat. You would probably get better
>>> results if you switched to a lower overhead test client. I tend to use
>>> ab for these sorts of tests.
>>>
>>> It is not clear from your original e-mail if the test client is running
>>> on the same machine as the server or not.
>>> If not, the network can have a significant impact. With this test a
>>> gigabit network should be fine but we have seen network saturation in
>>> performance tests for larger static files so do keep an eye on the
>>> network utilisation just to be safe.
>>>
>>> The higher the throughput, the greater the impact of HTTP keep-alive. I
>>> have frequently observed strange test results caused by the system
>>> running out of free ports due to the churn rate of connections. netstat
>>> is your friend. I'd recommend exploring the impact of different settings
>>> for maxKeepAliveRequests. You almost certainly want something
>>> significantly higher than the default of 100. A quick test would be to
>>> set it to -1 and see what impact that has.
>>>
>>> HTH,
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message