Mailing-List: contact jmeter-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "JMeter Users List" <jmeter-user@jakarta.apache.org>
Received-SPF: pass (nike.apache.org: domain of kirk.pepperdine@gmail.com
 designates 209.85.161.44 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=cUaHIUyS74/qdXvZKYnQ/MLxFJ369Rcnm6ripcpWQf6BPDzkyl6nD+hTAE8L0WvZh/
         xzsTn2+i1I1Bo3QzA7TeL9b8GMZAIAnehzylLxGb6wU3JScfds5mGfQ5K+0aS06w02h0
         qfgufgaE+EEjqMnVzaf8SsgQCAOz1VgbqTlcQ=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: determining ramp-up period
From: Kirk <kirk.pepperdine@gmail.com>
In-Reply-To: <4E04407C.4080701@mpexnet.de>
Date: Fri, 24 Jun 2011 13:29:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <94DEEAEA-D1CB-479C-A79E-E09E7D6307EF@gmail.com>
References: <1308700591314-4512401.post@n5.nabble.com>
	<68A39D9C74BD8241B3659184041D6F63012124A9@SRCEXC.srchq.src-solutions.com>
	<BANLkTin+ku=igLMFB7059i_X9dOTByKPgg@mail.gmail.com>
	<68A39D9C74BD8241B3659184041D6F63012124AC@SRCEXC.srchq.src-solutions.com>
	<4E019F67.3070200@mpexnet.de>
	<68A39D9C74BD8241B3659184041D6F630121250B@SRCEXC.srchq.src-solutions.com>
	<4E01F02C.4050707@mpexnet.de>
	<68A39D9C74BD8241B3659184041D6F630121256F@SRCEXC.srchq.src-solutions.com>
	<4E02E87F.1050503@mpexnet.de>
	<69A1B578-91BC-4236-B394-73BEFEB13F59@gmail.com>
	<BANLkTi=swsykVnJcVgBZ7bkaK1DpsychyQ@mail.gmail.com>
	<8C5B7B50-4F43-456B-A848-28BAFC7989F4@gmail.com>
	<BANLkTinPhGZMt5i4xhRtaJyMiSjtfZUmYw@mail.gmail.com>
	<3AFDD3A9-3EFD-4F7C-898A-D4DBB893F3C6@gmail.com>
	<BANLkTimGuoaNtW5aC2EZzdT3EMTe3Oux+w@mail.gmail.com>
	<BANLkTi=QTVpOm2twTP01sKX+htREVToimQ@mail.gmail.com>
	<365775F2-465F-4B8C-AD9B-1D25F4AA4D6E@gmail.com>
 <BANLkTi=_6MbvoM6WMnLcqhwkhp4HY9s_1g@mail.gmail.com>
 <4E04407C.4080701@mpexnet.de>
To: "JMeter Users List" <jmeter-user@jakarta.apache.org>

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.

Regards,
Kirk

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.
>>=20
>> Or am I overlooking something?
>>=20
>=20
> I believe so.
>=20
> Many web applications reach a throughput plateau and cannot generate
> more than X responses per time unit.
>=20
> 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.
>=20
> (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.)
>=20
> 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.
>=20
> 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.
>=20
> Regards,
> Felix
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>=20


---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org