You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by sebb <se...@gmail.com> on 2008/12/02 14:11:12 UTC
Re: Load and Performance Testing in JMeter
On 02/12/2008, giridharan <gi...@comneti.com> wrote:
>
> Hi,
>
> We have developed a webportal app using GWT / ext. We need to measure the
> load performance test of the system. We tried to utilise JMeter for the
> purpose.
>
> Even though we can record and run it, the results given by JMeter (in
> milliseconds) leaves a lot to be desired.
What do you mean by that?
> The time measured for the individual modules are unrealistic.
Again, what do you mean?
> Is there a way to precisely configure a
> GWT/ext app using JMeter for performance testing?
No idea what you mean; sounds like a question for a GWT/ext user list.
> --
> View this message in context: http://www.nabble.com/Load--and-Performance-Testing-in-JMeter-tp20791704p20791704.html
> Sent from the JMeter - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: thread group thread behavior
Posted by sebb <se...@gmail.com>.
On 05/12/2008, kirk <ki...@gmail.com> wrote:
>
>
> >
> > > 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.
> > >
> > >
> > >
> >
> > However, it should allocate a new cookie every time the Cookie Manager
> > parent controller loops.
> >
> >
> k, that is my understanding as well.
>
> >
> >
> > >
> > > >
> > > >
> > > > > 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
> > >
> > >
> >
> > I've not seen that - are you sure cookies are being sent after being
> cleared?
> >
> >
> yes, the server is reporting on the jsession as you can see in the output.
I can see the values, but they mean nothing to me without seeing what
JMeter is doing.
Are you positive that the first sampler in the thread after the
cookies have been cleared is sending a cookie? This should be visible
in the View Results Tree "Request" panel. The Set-Cookie headers
appear in the "Sampler Result" panel.
> If the cookie manager is deleted from the test plan, a new jsession is
> assigned on every simple sample.
OK, but that does not have any bearing on whether the Cookie Manager
is misbehaving or not.
> >
> >
> > > 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.
> > >
> > >
> >
> > That's probably due to the Throughput Controller.
> >
> >
> The output you are looking at was produced before I went to the *weird*
> configuration and before I started using the throughput controller.
>
> >
> >
> > > 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.....
> > >
> > >
> > >
> >
> > Which can well be the case if that's what the Throughput Controller
> > has been told to do ...
> >
> >
> ok, but just to be clear, this threading question was observed prior to my
> using the through put controller. I only started going *weird* in an attempt
> to work around the problem.
>
> I think what I need to do next is post a test servlet along with a test
> plan. The application that I'm currently using is a wee bit too big to post.
OK - but please don't post code / JMX to the mailing list.
Either upload to a public URL and post that, or create a Bugzilla
issue and attach to that, or send the file(s) to me directly.
>
> 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:
> > > > > > > jmeter-user-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail:
> > > > > > > jmeter-user-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > >
> > >
> > > >
> > > > >
> > > > >
> > > > > > To unsubscribe, e-mail:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > jmeter-user-unsubscribe@jakarta.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > For additional commands, e-mail:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > jmeter-user-help@jakarta.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > >
> > >
> > > >
> > > > > To unsubscribe, e-mail:
> > > > > jmeter-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > > > > jmeter-user-help@jakarta.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > >
> > >
> > > > To unsubscribe, e-mail:
> > > >
> > > >
> > > jmeter-user-unsubscribe@jakarta.apache.org
> > >
> > >
> > > > For additional commands, e-mail:
> > > >
> > > >
> > > jmeter-user-help@jakarta.apache.org
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > jmeter-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > jmeter-user-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> jmeter-user-help@jakarta.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: thread group thread behavior
Posted by kirk <ki...@gmail.com>.
>> 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.
>>
>>
>
> However, it should allocate a new cookie every time the Cookie Manager
> parent controller loops.
>
k, that is my understanding as well.
>
>>>
>>>> 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
>>
>
> I've not seen that - are you sure cookies are being sent after being cleared?
>
yes, the server is reporting on the jsession as you can see in the
output. If the cookie manager is deleted from the test plan, a new
jsession is assigned on every simple sample.
>
>> 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.
>>
>
> That's probably due to the Throughput Controller.
>
The output you are looking at was produced before I went to the *weird*
configuration and before I started using the throughput controller.
>
>> 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.....
>>
>>
>
> Which can well be the case if that's what the Throughput Controller
> has been told to do ...
>
ok, but just to be clear, this threading question was observed prior to
my using the through put controller. I only started going *weird* in an
attempt to work around the problem.
I think what I need to do next is post a test servlet along with a test
plan. The application that I'm currently using is a wee bit too big to post.
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:
>>>>>> jmeter-user-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail:
>>>>>> jmeter-user-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>
>>>>
>>>>> To unsubscribe, e-mail:
>>>>>
>>>>>
>>>>>
>>>> jmeter-user-unsubscribe@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>> For additional commands, e-mail:
>>>>>
>>>>>
>>>>>
>>>> jmeter-user-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>
>>>> To unsubscribe, e-mail:
>>>> jmeter-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail:
>>>> jmeter-user-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>>
>>> To unsubscribe, e-mail:
>>>
>> jmeter-user-unsubscribe@jakarta.apache.org
>>
>>> For additional commands, e-mail:
>>>
>> jmeter-user-help@jakarta.apache.org
>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> jmeter-user-help@jakarta.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: thread group thread behavior
Posted by sebb <se...@gmail.com>.
On 05/12/2008, kirk <ki...@gmail.com> wrote:
> sebb wrote:
>
> > On 05/12/2008, kirk <ki...@gmail.com> 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.
>
However, it should allocate a new cookie every time the Cookie Manager
parent controller loops.
> >
> >
> > > 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
I've not seen that - are you sure cookies are being sent after being cleared?
> 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.
That's probably due to the Throughput Controller.
> 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.....
>
Which can well be the case if that's what the Throughput Controller
has been told to do ...
> >
> >
> > > 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.
The Throughput Controller has not changed in a while, though the
documentation has been updated.
> 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:
> > > > > jmeter-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > > > > jmeter-user-help@jakarta.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > >
> > >
> > > > To unsubscribe, e-mail:
> > > >
> > > >
> > > jmeter-user-unsubscribe@jakarta.apache.org
> > >
> > >
> > > > For additional commands, e-mail:
> > > >
> > > >
> > > jmeter-user-help@jakarta.apache.org
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > jmeter-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > jmeter-user-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> jmeter-user-help@jakarta.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: thread group thread behavior
Posted by kirk <ki...@gmail.com>.
sebb wrote:
> On 05/12/2008, kirk <ki...@gmail.com> 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:
>>>> jmeter-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail:
>>>> jmeter-user-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>>
>>> To unsubscribe, e-mail:
>>>
>> jmeter-user-unsubscribe@jakarta.apache.org
>>
>>> For additional commands, e-mail:
>>>
>> jmeter-user-help@jakarta.apache.org
>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> jmeter-user-help@jakarta.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: thread group thread behavior
Posted by sebb <se...@gmail.com>.
On 05/12/2008, kirk <ki...@gmail.com> 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.
> 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.
> 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.
> 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?
> I'll turn on debug to see if I can figure out whats happening.
>
> Regards,
> Kirk
>
>
> sebb wrote:
>
> > On 03/12/2008, kirk <ki...@gmail.com> 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:
> > > jmeter-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > jmeter-user-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> jmeter-user-help@jakarta.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: thread group thread behavior
Posted by kirk <ki...@gmail.com>.
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.
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. When looking for why that was happening I noted
that only one thread was being worked which made my test even worse. 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.
I'll turn on debug to see if I can figure out whats happening.
Regards,
Kirk
sebb wrote:
> On 03/12/2008, kirk <ki...@gmail.com> 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:
>> jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> jmeter-user-help@jakarta.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: thread group thread behavior
Posted by kirk <ki...@gmail.com>.
sebb wrote:
> On 05/12/2008, kirk <ki...@gmail.com> wrote:
>
>> 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.
>>
>
> That sounds weird.
>
Well, not really. JMeter as it is currently implemented is good for
simulating close systems such as call centers where there are a fixed
number of users rolling over a set of usage patterns. It is less suited
for open systems where the number of users may vary and entry into the
system is pretty much unthrottled. Unfortunately this represents the
vast majority of systems that I bench/tune. So this scheme with a
randomizer on the front end is more representative of the type of
testing that I do.
I always use JMeter in my performance talks that I often do at
conferences. I'll be presenting a university session at Devoxx (formally
Javapolis) where I'll be using JMeter to load test the demo app. I'll be
presenting this method of load testing on Tuesday.
>
>> The throughput controller at the top of the test plan seems to throttle
>> things the way I was hoping for.
>>
>
> The Throughput Controller is badly named - it does not actually
> control throughput, it merely controls the number of executions. You
> should probably be using the Constant Throughput Timer.
>
Humm, I don't think constant throughput is what I'd like either then. I
need to re-think this part.
>
>> 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.
>>
>
> Not sure I understand what that means.
>
One of the things that I run into are badly configured stress test
harnesses. Because of this I often validate the harness prior to using
to actually drive a load test. I just want to make sure that the traffic
coming from the harness is what I expect it to be from the server's
point of view. That typically requires doing some sort of statistical
analysis on data generated by a *null* server.
I did have one client that delayed their release because they couldn't
meet critical performance requirements. Turned out the bottleneck in the
system was in the test harness (not JMeter ;)). Once the harness was
tuned, the application managed to just meet requirements. Just two weeks
ago I ran into another similar situation so.....
>
>> 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.
>>
>
> There is currently no Poisson timer, but there are other timers that
> you can use, e.g.
>
> http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Gaussian_Random_Timer
Gaussian is good but for this case, Poisson is more appropriate. It's been on my list for a while to create one.. time...
Regards,
Kirk
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: thread group thread behavior
Posted by sebb <se...@gmail.com>.
On 05/12/2008, kirk <ki...@gmail.com> wrote:
> 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.
That sounds weird.
> The throughput controller at the top of the test plan seems to throttle
> things the way I was hoping for.
The Throughput Controller is badly named - it does not actually
control throughput, it merely controls the number of executions. You
should probably be using the Constant Throughput Timer.
> 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.
Not sure I understand what that means.
> 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.
There is currently no Poisson timer, but there are other timers that
you can use, e.g.
http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Gaussian_Random_Timer
> Regards,
> Kirk
>
>
> sebb wrote:
>
> > On 03/12/2008, kirk <ki...@gmail.com> 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:
> > > jmeter-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > jmeter-user-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> jmeter-user-help@jakarta.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: thread group thread behavior
Posted by kirk <ki...@gmail.com>.
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 <ki...@gmail.com> 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:
>> jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> jmeter-user-help@jakarta.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: thread group thread behavior
Posted by sebb <se...@gmail.com>.
On 03/12/2008, kirk <ki...@gmail.com> 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:
> jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
thread group thread behavior
Posted by kirk <ki...@gmail.com>.
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?
Thanks,
Kirk
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org