Ok. I've finally also found out that each thread is set to go at 3 requests per minute and my ramp up period is 20 seconds. So; 3 requests per minute is every 20s as well so perhaps they're clashing.
I've upped my ramp-up to 30s and we'll see if there's any difference tonight. It may be that i ought to run with say half the number of threads and double the throughput? I imagine that could smooth things out. Perhaps even 1/4 the number of threads and 4x throughput etc.. I'll experiment further tomorrow. Thanks! Dan --------- Original Message -------- From: JMeter Users List <jmeter-user@jakarta.apache.org> To: JMeter Users List <jmeter-user@jakarta.apache.org>, Dan <[EMAIL PROTECTED]> Subject: Re: JMeter - arrival rate variations Date: 13/11/07 16:31 > On 13/11/2007, Dan <[EMAIL PROTECTED]> wrote: > > Ok excellent i'm getting somewhere. > > > > I've found that the arrivial rate varys from 91 requests per second to 110 > > r/s and the low points are every 20s. > > We are using the constant throughput controller, so i guess that could mean > > that prior to the low point those requests have been processed quicker than > > normal for some reason. (?) > > If the rate dropped below the target - e.g. if the server was slow to > respond - then the CTC will decrease the delay to try to catch up; > this will cause a temporary increase in the request rate. > > > I think i'll try running with multiple servers. but i still suspect this is > > something in the app or db layer. Looking at cpu/memory/network stats there > > doesnt appear to be much load on the test script server - but of course that > > doesnt mean there isnt a limit somewhere! > > I have recently enabled the summary option, maybe i'll turn that off again. > > we run up to about 3,000 threads in each test. ( solaris 64 bit VM ) > > The Summariser should be quite cheap to process. > > > Thanks, > > Dan > > > > --------- Original Message -------- > > From: JMeter Users List <jmeter-user@jakarta.apache.org> > > To: JMeter Users List <jmeter-user@jakarta.apache.org> > > Subject: Re: JMeter > > Date: 13/11/07 00:23 > > > > > On 12/11/2007, Dan Keeley &lt;[EMAIL PROTECTED]&gt; wrote: > > > &gt; Hi, > > > &gt; > > > &gt; We are seeing some regular (20second apart) spikes in our throughput. > > > > > > Do you mean that the throughput suddenly increases? > > > Are the requests still successful? > > > > > > &gt; We suspect these are from the application tier, but are not 100% > > sure. So i > > > &gt; just wanted to check whether jmeter will put through a constant rate > > of > > > &gt; requests after the ramp-up period and whether or not it could be > > responsible > > > &gt; for these peaks? > > > > > > The rate at which JMeter generates requests depends on what timers are > > > present in the plan. Some combinations of random timers and > > > controllers could cause spiky behaviour. > > > > > > &gt; They are always 20 seconds regardless of high or medium throughput so > > i > > > &gt; pretty much discount garbage collection. Although i'm learning it's > > > &gt; dangerous to ignore things such as this! > > > > > > I agree, it seems a bit unlikely that it is GC. > > > > > > Have you checked the elapsed times? > > > Do they show a pattern? > > > > > > Also check the gaps between request initiation. > > > Are they consistent with the test plan? > > > > > > Fluctuations in elapsed times are more likely to be caused by > > > resources external to the JMeter host. > > > > > > Fluctuations in request initiation could be caused by JMeter probems > > > (or possibly JMeter host problems) - but remember that the Constant > > > Throughput timer will adjust the gaps to try and maintain a suitable > > > rate. > > > > > > > > > You could try running the test plan against the JMeter mirror server > > > and see how that behaves. > > > > > > Reduce JMeter resource usage by following the advice here: > > > > > > http://jakarta.apache.org/jmeter/usermanual/best-practices.html#lean_mean > > > > > > You can also try dividing the load between multiple independent JMeter > > > instances so that each one is only processing a low throughput. Check > > > that they all run OK independently, and then start them together. If > > > you then start seeing the problem, then it must be some resource that > > > is common to all the instances, e.g. the application or perhaps the > > > network. > > > > > > Check what the OS monitoring tools show on the different hosts. > > > > > > &gt; Thanks, > > > &gt; Dan > > > &gt; > > > &gt; > > > &gt; --------------------------------------------------------------------- > > > &gt; To unsubscribe, e-mail: [EMAIL PROTECTED] > > > &gt; For additional commands, e-mail: [EMAIL PROTECTED] > > > &gt; > > > &gt; > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > ________________________________________________ > > Message sent using UebiMiau 2.7.10 > > > > > > > > --------------------------------------------------------------------- > > 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] > > > ________________________________________________ Message sent using UebiMiau 2.7.10 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
