Hi Sebb,
I guess I should add my work around is to set the thread count for the
thread group to some wild a$$ large value, set the ramp-up time to the
duration that I'd like the test to run, and then set the loop count to 1
which allows the thread to die when it's finished executing the test
plan. The throughput controller at the top of the test plan seems to
throttle things the way I was hoping for. That said, I've not done a
proper statistical analysis of behavior to confirm. The added advantage
of doing this is that is turns jmeter testing from being closed (self
throttling) to open system. This loads my systems in a way that is
better representative of the load I'm trying to simulate. What I'm
seeing is the requests are coming in a regular intervals which isn't
something that I like. To that point I'd like the throughput controller
to incorporate a Poisson distribution. Best would be a new type of
thread group I'd call a throughput thread group. Something where I could
specify a inter- new user arrival rate with a distribution. Something
that works similarilly to the hack that I'm currently using only better.
Regards,
Kirk
sebb wrote:
On 03/12/2008, kirk <[EMAIL PROTECTED]> wrote:
Hi,
I was looking at providing a particular load pattern on a server. When I
wasn't seeing that load show up, I dropped some debug statements into my
servlet code that printed the session id. What I found was that adding a
cookie manager limited the number of sessions to the number of threads.
However, setting the clear cookies check box didn't seem to allow the server
to assign a new session id and hence, create new sessions once the thread
restarts the thread group. Further more, one thread seemed to be carrying
all of the load. Here is the output from my test servlet. The thread group
is configured for 3 threads The cookie manager is set to clear cookies at
the end of each iteration.
15nhcqlwugmkh
npli36fysau0
1nmwz0414pt0d
npli36fysau0
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
15nhcqlwugmkh
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
1nmwz0414pt0d
...
Is this expected behavior?
Difficult to say without knowing how the session ids are allocated and
how many samplers there are in the thread.
You might find it helpful to turn on debugging for the Cookie Manager
(e.g. select it and use Help/Enable debug).
The View Results Tree Listener can be used to show the cookies; you
can see noew ones are being sent by the server.
Server cookies are also stored as variables, so you could save those
in the JTL file:
http://jakarta.apache.org/jmeter/usermanual/listeners.html#sample_variables
Thanks,
Kirk
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
