On 13/11/2007, Dan <[EMAIL PROTECTED]> wrote: > 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. >
Perhaps try one of the other constant throughput options. > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
