On 05/12/2008, kirk <[EMAIL PROTECTED]> 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 <[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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
