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 <[email protected]> > To: JMeter Users List <[email protected]> > Subject: Re: JMeter > Date: 13/11/07 00:23 > > > On 12/11/2007, Dan Keeley <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > We are seeing some regular (20second apart) spikes in our throughput. > > > > Do you mean that the throughput suddenly increases? > > Are the requests still successful? > > > > > We suspect these are from the application tier, but are not 100% > sure. So i > > > just wanted to check whether jmeter will put through a constant rate > of > > > requests after the ramp-up period and whether or not it could be > responsible > > > 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. > > > > > They are always 20 seconds regardless of high or medium throughput so > i > > > pretty much discount garbage collection. Although i'm learning it's > > > 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. > > > > > Thanks, > > > Dan > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
