sebb wrote:
On 05/12/2008, kirk <[EMAIL PROTECTED]> wrote:
Hi sebb,
These are actualy jsessionid's. For the test I used 2 samplers in the
thread with only 3 threads. I was looking for the information in the tree
listener and it correlated with what the server was saying.
I don't know for certain how jsession ids are passed from client to
server. Assuming that this is done via cookies, then JMeter will only
send the cookie if there is a Cookie Manager and the cookie matches
the domain. Cookies are stored by the Cookie Manager for the local
thread only, so each thread can have the same cookie name with
different values.
If "Clear Cookies each iteration" is selected, then cookies will be
cleared at the start of each iteration of the parent container -
usually the Thread Group.
The cookie is intially stored on receipt of a Set-Cookie: header.
The server is free to provide whatever cookies it wishes. It may
generate a new cookie each time it sees a request without a cookie
(e.g. that is what Google seems to do), or it may require a login.
I'm using Jetty and it assigns a new jsession every time one is not
passed to it. That works very well. If the cookie manager is put into
the test plan, the jsession id is passed to jetty and it does not assign
a new one. That is evident by my testing.
What I was really hoping for was a new session id for each thread at the
restart of the loop. That didn't seem to happen even though the clear
cookies flag was set.
In that case, either there is a JMeter bug (AFAIK, 2.3.2 Cookie
Manager is working OK), or the server must be resending the same
cookie to JMeter.
I'll vote JMeter problem although it may not be a bug per say. The fact
that all sessions that don't have a jsession id are assigned one and
that one is always sent by JMeter even with the clear cookies box ticked
suggests that maybe cookies are cleared by jsession isn't. If that
doesn't happen, jmeter, tomcat and like will use the same session unless
the application over-rides with it's own cookies.
When looking for why that was happening I noted that
only one thread was being worked which made my test even worse.
I assume you are referring to a server thread.
No, the JMeter threading. From the output you can see that requests
received by the server were almost completely dominated by a single
jsession id. This implies that one thread in JMeter was responsible for
most of the load on the server. If there were a way to clear the
jsession id, that wouldn't matter. However.....
Not having a
cookie manager cases the server to react as expected in that there is a new
jsession assigned to each sampler request. I'm using the latest release.
Do you mean 2.3.2?
yes, and I tried it in a couple of previous versions also. The behavior
was the same.
Regards,
Kirk
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]
---------------------------------------------------------------------
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]
