jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirk <>
Subject Re: determining ramp-up period
Date Fri, 24 Jun 2011 11:29:42 GMT
Gosh, I was about to dig into source code to setup some examples but I think you're explanation
short-circuted that effort.

There is a different problem with large numbers of threads that I was writing up in a different
email. I'll transfer to here and then continue. As follows:

Iincreasing the number of threads would sort of increase the load but then you start hitting
the wall in a number of other areas. For example, I have a benchmark that I've been running
for years. This single threaded bench stresses the thread scheduler. The measured body of
the bench should run in 1 second flat. Here are traditional results. Results get worse as
you multi-thread.

XP : 1900 ms
Mac OSX 1100 ms
Linux (just about every distro) : 1200ms
Windows 7: 1010ms
Solaris: 1100ms or 10100ms depending upon Kernel settings
Anything OS virtualized hardware (Virtual Box, VMWare, Parallels) >2000ms (depending on
virtualized OS)

Sony has done something to Windows 7 so on better class hardware it runs in 1000ms. That said,
hardware doesn't seem to matter. If I take a Dell box and run XP on it, I'll get 1900ms and
if I run RedHat, 1200ms.

Thread scheduling is getting better but... I was going to look in the code for calls to sleep(),
currentTimeMilis() and other things that depend upon hardware/OS for specific performance
details. These are outside of JMeter's control but like any framework, you can play into a
platform's weaknesses or play away from them. Large numbers of threads currently plays into
most platform's weaknesses. I'd like to think that common ground is that it's better if JMeter
could produce a given load with fewer threads. That said, I don't expect JMeter to jump to
an event base model *any* time soon.. that is completely unreasonable. However, I'll see if
I can hack out a new ThreadGroup that reflects what I think can be done in the short term.


On Jun 24, 2011, at 9:45 AM, Felix Frank wrote:

> On 06/24/2011 01:37 AM, sebb wrote:
>>> It means, keep up the Y requests / time unit... and you cannot do that with JMeter
or any other load test harness with a similar threading model. This threading model is easy
to write, easy to understand but self throttling. Event base models are harder to understand,
more difficult to implement but open by design and less likely to self throttle.
>> What I would do here is increase the number of threads.
>> This will allow more requests to be generated, at least until the
>> number of threads / memory use starts to be an issue.
>> At which point, add another JMeter client to share the load.
>> Or am I overlooking something?
> I believe so.
> Many web applications reach a throughput plateau and cannot generate
> more than X responses per time unit.
> If you double (triple,...) the number of threads, you have some Jmeter
> instances with twice (three times,...) as many threads patiently waiting
> for the server. The load as perceived by the system under test remains
> roughly equal.
> (Please take my word for it. Same as Kirk, I suffered from this on
> several occasions before. Nevertheless, Jmeter has proven time and again
> to be both the most versatile and powerful load generator from the
> arsenal I've yet tried.)
> If the system under test is a simplistic web application, I've used
> timeouts to enable my threads to send more requests than the server will
> readily respond to. Of course, the response data collected by such a
> Thread Group is specious. So I'll have another, smaller Thread Group,
> which acts patiently and collects performance and correctness data.
> All of this is a crude work-around of course. If Kirk has a model in
> mind that will make such devices unnecessary, any positive developments
> would be greatly appreciated.
> Regards,
> Felix
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message