On 15/01/2010, Robert Elliot <[email protected]> wrote: > > Hi, > > 1. What's about memory used by JMeter? Does JMeter uses small memory at > start point and then memory raises up and up? > > > The memory remains pretty constant (it's using the same JVM args as on the > local machine where there is no problem). The CPU however ramps steadily up > until both CPUs are just over 50%, whereas locally it remains pretty static > and significantly lower. > > > > 2. What option do you use for Threads Group: stop test, stop thread or > continue on error? > > Continue on error. > > > > > 3. Have you tried to change Transaction Controller to Simple Controller? > > > Not yet - I'll try it, but I think we need the Transaction Controller in > order to get the total time for the sub samples. >
If the samples have a suitable naming convention, then you could generate this info from the output file, but that's more work. > > > > 4. What version of JMeter was being used ? > > 2.3.2 That's rather old. Try 2.3.4 instead. > We have no listeners enabled, we're running headless and getting the results > using the -l option. That's good. > We've tried switching to csv output format, thinking it might be the XML > generation that was the issue, but we're still seeing the same behaviour. Unless you really need XML, use CSV. CSV is better for test runs with lots of output, because files are much smaller. > To try and take load out of the equation a bit I also switched it to use 5 > threads and try and do 300 transactions a minute for 5 minutes - so each > thread needs to do 1 a second, and we should get a total of 1500 > transactions. The first ~200 go through at between 100 and 150 ms each, then > it starts to ramp up until at the end it's up at more than 2 seconds. In > total it manages 1000 transactions in 5 minutes. So basically the same > behaviour, just less dramatic than with 128 threads and 480 transactions a > minute. > > Thanks for your help. > > > > С уважением, > > Андрей Похилько > > > > -----Original Message----- > > From: Robert Elliot [mailto:[email protected]] > > Sent: Thursday, January 14, 2010 8:22 PM > > To: [email protected] > > Subject: JMeter performance degrades over time on one machine > > > > Hi all, > > > > We're experiencing an odd problem with JMeter. > > > > We have a simple test - a Transaction Controller with two child HTTP > Samplers, one to retrieve a page and one to submit a form on it. We want to > measure the total time of the transaction under load (480 transactions a > minute). Run on a local dev machine we see the transaction controller's time > just above the sum of the two sample times - as you'd expect. Roughly 50 ms. > > > > However, we want to run this test as part of our automated build. Run on > the build slave (same test, same JMeter version, same parameters, against the > same web server) it starts OK, but gradually degrades. What's strange is > that the individual HTTP samples remain the same (c. 20ms each) but the > transaction controller sample steadily increases up to 60 seconds! Looking > at the timestamps of the sample and httpSamples it appears that time is being > lost before each of the httpSamples. Running top seems to show that the CPU > eventually hit 100%, though we believe that this may be the sum of 2 CPUs at > c.50%; locally the CPU never gets anywhere near that. > > > > The buildslave is not particularly underpowered, it's a reasonable virtual > machine. And it has the same problem even when we reduce the number of > threads to 2 (with a ramp up time of 60 seconds). > > > > We're a bit baffled. Has anyone experienced similar and managed to solve > it? Setting log level to debug reveals nothing. > > > > Thanks, > > Rob > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
