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 (asf.osuosl.org: domain of sebbaz@gmail.com designates
 64.233.182.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=mezIELdeNfif+fnO/8RQjYSCbo7xXiPiuRXcDMzop1Z21A+i8dnvHxacz1ozQ+PN+M412UmDnhdViG4bMZIBX4wNuxUpNEu0xBCzlk5RyGAkooyUD3EZm0AfqWjyxNl+qSf1UBMrvPr3OYUZVy6wkcJsp8d8NaOkLGX6eMjFBsU=
Message-ID: <25aac9fc05070116225600976b@mail.gmail.com>
Date: Sat, 2 Jul 2005 00:22:08 +0100
From: sebb <sebbaz@gmail.com>
Reply-To: sebb <sebbaz@gmail.com>
To: Rabi Lahiri <rabi.lahiri@gmail.com>
Subject: Re: HTTP timeouts with __StringFromFile function
Cc: JMeter Users List <jmeter-user@jakarta.apache.org>
In-Reply-To: <3da8afd605070115191840a307@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <3da8afd605062916097fcdb3c6@mail.gmail.com>
	 <25aac9fc050630024936c17b60@mail.gmail.com>
	 <3da8afd605063018117fc05a2f@mail.gmail.com>
	 <25aac9fc05070105113a2e46e3@mail.gmail.com>
	 <3da8afd60507011330a0147b1@mail.gmail.com>
	 <25aac9fc05070114513aa6b431@mail.gmail.com>
	 <3da8afd605070115191840a307@mail.gmail.com>

On 7/1/05, Rabi Lahiri <rabi.lahiri@gmail.com> wrote:
> That indeed was the issue.  Somewhere in the process of reading the
> documentation I had gotten the idea that a thread corresponds to a
> user instead of an actual java thread and hadn't really taken into

A JMeter thread corresponds to a user *and* a Java thread.

Real users operate independently, which is why JMeter uses a thread
for each user.

> account the load on the machine running jmeter.  The biggest problem
> had to do with the fact that, to me at least, the concept of 10
> threads running * 10 loops would do the exact same test 10 times with
> 10 threads each. =20

Depends on how the test is set up.
If the samplers have fixed URLs etc, then yes, the same test will be
repeated in each thread.

If the threads go through some login process that provides a different
cookie to each login, then of course the different threads will
continue to with their own cookie (assuming there is a Cookie Manager
present) and so won't be exactly the same test.

But if the samplers use variables, each thread can be different.

> If I have 100 unique requests that I want to read
> from a file, a setup like that would intuitively mean running the
> first ten requests ten times each. =20

???

> What it actually does, and what I
> want it to do but didn't know how to set up, was to read all 100
> requests once each. =20

As you've no doubt seen, StringFromFile reads the next record from the
file each time it is invoked. Each occurence of SFF will be invoked
once per thread. So each thread will get a different line from the
file (unless it wraps back to the start). Same with CSVRead.

> In other words, we lost a couple days to an issue
> with confusing documentation and label names rather than a bug in the
> program.

Which parts of the documentation are confusing?
How can they be clarified?

>=20
> much thanks,
> Rabi
>=20
> On 7/1/05, sebb <sebbaz@gmail.com> wrote:
> > On 7/1/05, Rabi Lahiri <rabi.lahiri@gmail.com> wrote:
> > > Actually I think the user parameter thing was a bit of a red herring.
> > > It worked that way several runs in a row but I can't reproduce the
> > > behavior any longer.
> > >
> > > Here's a simple example that demonstrates the behavior I don't quite =
understand.
> > >
> > > standard HTTP sampler (not my subclass), uncheck follow redirect and
> > > uncheck use keepalive.  point to www.google.com port 80.
> > >
> > > Timing is avg/min/max, with 1 loop and varying numbers of threads,
> > > according to the aggregate report listener:
> > > 1 thread      =3D 48 / 48 / 48
> > > 10 threads  =3D 47 / 44 / 52
> > > 25 threads  =3D 66 / 46 / 107
> > > 50 threads  =3D 89 / 39 / 193
> > > 100 threads =3D 137 / 46 / 247
> > > 500 threads =3D 1236 / 47 / 8076
> > > 1000 threads =3D 1670 / 29 / 15379
> > >
> > > I wouldn't expect to see the increasing average times that way - even
> > > if a few threads spike and make the max value go way up, the general
> > > performance should still be pretty constant, as observed with the
> > > minimum timing column.  Also, if instead of 1000 threads in 1 loop, I
> > > use 10 threads with 100 loops, I get
> > >
> > > avg / min / max
> > > 56 /  24   / 197
> > >
> > > Which looks much more reasonable.  Since the request is the same all
> > > the time, shouldn't the timing for 10 threads * 100 loops be very
> > > similar to that with 1000 threads * 1 loop?
> >
> > No, they are not at all equivalent.
> >
> > A test with a single loop does not get a chance to stabilise - apart
> > from the fact that 1000 threads * 1 loop is a much higher load for the
> > JMeter host machine than 10 threads with 100 loops.
> >
> > >
> > > thanks again,
> > > Rabi
> > >
> > > On 7/1/05, sebb <sebbaz@gmail.com> wrote:
> > > > Which version of Jmeter are you using?
> > > >
> > > > I don't understand what's happening here.
> > > >
> > > > Try replacing your HTTP Sampler with a JavaTest sampler to see if t=
he
> > > > timings are affected by the presence of the user parameter
> > > > pre-processor or not.
> > > >
> > > > Or indeed try using the standard HTTP Sampler instead of yours.
> > > >
> > > > If either of these shows the timing problem, please create a Bugzil=
la
> > > > issue, and then attach the following:
> > > >
> > > > - simple test script that has OK timing data
> > > > - simple test script that causes timing data problems
> > > > - jmeter.log for both test runs
> > > > - jtl files for both runs.
> > > >
> > > > S.
> > > >
> > > > P.S. If you thing the changes you made to the HTTP Sampler might be
> > > > useful to others, perhaps you would consider filing a Bugzilla
> > > > enhancement request to describe what you have added.
> > > >
> > > > On 7/1/05, Rabi Lahiri <rabi.lahiri@gmail.com> wrote:
> > > > > I have the duration assertion as a child of the sampler.
> > > > >
> > > > > Something interesting I noticed just now, though - if I use stati=
c
> > > > > arguments and no User parameter preprocessor with the sampler, th=
e
> > > > > timing data looks fine.  If I add the user parameter preprocessor=
 with
> > > > > two $_StringFromFile functions (as a child of the sampler), the t=
iming
> > > > > data gets messed up and looks cumulative among all the threads, e=
ven
> > > > > if I don't actually use the variables from the file (i.e. I leave=
 the
> > > > > arguments to the sampler as static data).
> > > > >
> > > > > Could the thread timers be including the time that each thread is
> > > > > blocked on I/O or somehow accumulating time because of that?  We =
have
> > > > > subclassed the HTTPSampler and AbstractSamplerGui for our project=
;
> > > > > otherwise everything is from the standard distribution.
> > > > >
> > > > > thanks again,
> > > > > Rabi
> > > > >
> > > > > On 6/30/05, sebb <sebbaz@gmail.com> wrote:
> > > > > > Where have you put the duration assertions in relation to the s=
amplers?
> > > > > >
> > > > > > Which version of JMeter are you using?
> > > > > >
> > > > > > S
> > > > > > On 6/30/05, Rabi Lahiri <rabi.lahiri@gmail.com> wrote:
> > > > > > > Hi,
> > > > > > > I've looked through all the docs I could find and the mail ar=
chives
> > > > > > > and couldn't find an answer to this.  I have a subclass of HT=
TPSampler
> > > > > > > and need to implement timeouts for my requests.  I'm using th=
e sampler
> > > > > > > with the following setup:
> > > > > > >
> > > > > > > 500 threads
> > > > > > > 1 loop
> > > > > > > parameter "args" is _StringFromFile(args.txt)
> > > > > > > parameter "method" is _StringFromFile(methods.txt)
> > > > > > >
> > > > > > > My service needs to pass args and method dynamically this way=
.
> > > > > > > args.txt and methods.txt are 500-line files which constitute =
the
> > > > > > > requests I need.  This works fine and I can test the results =
of each
> > > > > > > with response assertions, except that duration assertions don=
't work
> > > > > > > properly.  The duration assertion appears to be timing the wh=
ole set
> > > > > > > of 500 threads instead of each one individually, so as soon a=
s the
> > > > > > > group time hits the assertion value every thread fails.  For =
example,
> > > > > > > let's say each call takes exactly 200 ms.  If I set the durat=
ion
> > > > > > > assertion to 1100ms, the first five responses succeed but all=
 the rest
> > > > > > > fail.  I need to be able to set it up so that I can verify th=
at no
> > > > > > > individual call takes more than, say, 250ms.  Is this possibl=
e?  If I
> > > > > > > need to make a code change, can it be done relatively simply?
> > > > > > >
> > > > > > > thanks,
> > > > > > > Rabi Lahiri
> > > > > > >
> > > > > > > -------------------------------------------------------------=
--------
> > > > > > > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apach=
e.org
> > > > > > > For additional commands, e-mail: jmeter-user-help@jakarta.apa=
che.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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