On 15/01/2010, Robert Elliot <[email protected]> wrote: > We just worked it out - did a thread dump when the samples were getting > really long and nearly every thread looked like this: > > "Signin Users Thread Group 1-128" prio=10 tid=0x00002aaacc144000 nid=0x5a81 > waiting for monitor entry [0x0000000048e95000..0x0000000048e95d00] > java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.jmeter.functions.JavaScript.execute(JavaScript.java:73) > - waiting to lock <0x00002aaab2cc0b08> (a > org.apache.jmeter.functions.JavaScript) > at > org.apache.jmeter.engine.util.CompoundVariable.execute(CompoundVariable.java:138) > at > org.apache.jmeter.engine.util.CompoundVariable.execute(CompoundVariable.java:107) > at > org.apache.jmeter.testelement.property.FunctionProperty.getStringValue(FunctionProperty.java:87) > at > org.apache.jmeter.testelement.property.AbstractProperty.hashCode(AbstractProperty.java:221) > at java.util.HashMap.put(HashMap.java:372) > at java.util.HashSet.add(HashSet.java:200) > at > org.apache.jmeter.testelement.AbstractTestElement.setTemporary(AbstractTestElement.java:389) > at > org.apache.jmeter.testelement.AbstractTestElement.setTemporary(AbstractTestElement.java:393) > at > org.apache.jmeter.testelement.AbstractTestElement.setTemporary(AbstractTestElement.java:393) > at > org.apache.jmeter.testelement.AbstractTestElement.addProperty(AbstractTestElement.java:217) > at > org.apache.jmeter.testelement.AbstractTestElement.mergeIn(AbstractTestElement.java:321) > at > org.apache.jmeter.testelement.AbstractTestElement.addTestElement(AbstractTestElement.java:115) > at > org.apache.jmeter.threads.TestCompiler.configureWithConfigElements(TestCompiler.java:281) > at > org.apache.jmeter.threads.TestCompiler.configureSampler(TestCompiler.java:86) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:278) > at java.lang.Thread.run(Thread.java:619) > > So they were all blocking trying to calculate a user defined variable using > javascript. Once we hard coded that value the problem went away. > > Is there a good way to calculate values up front and store them as > properties? We had wrongly assumed that by putting the User Defined > Variables panel outside the thread group the variables would just be > calculated once and then be available to all threads - the values are not > thread specific and never change.
If you do the calculations on the Test Plan, they should only be done once. Alternatively, pass them in as properties from the command-line or user.properties file and use the __P() function on the Test Plan. You may need JMeter 2.3.4 for this. > Thanks! Thanks for lettting us know what the problem was. > Rob > > > ----- Original Message ----- > From: "Robert Elliot" <[email protected]> > To: "JMeter Users List" <[email protected]> > Sent: Friday, 15 January, 2010 11:22:19 AM > Subject: Re: JMeter performance degrades over time on one machine > > > 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. > > > > > 4. What version of JMeter was being used ? > > 2.3.2 > > We have no listeners enabled, we're running headless and getting the results > using the -l option. 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. > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
