might be GC.. me be that JMeter's threads are all hung up in your server doing 
stuff.

Regards,
Kirk
On Dec 14, 2011, at 10:35 PM, Robin D. Wilson wrote:

> I have a marginally complicated test case that performs a 'registration' on
> my site. It gets the home page, POSTS a form, gets the response, POSTS
> another form, gets that response, and then completes. The test runs fine
> with 100 threads, and 30000 iterations - IF I don't "Retrieve All Embedded
> Resources from HTML Files". In this mode, I am really testing the throughput
> of my 'tomcat' application, not the other elements of my system. (I'm
> assuming that the other elements are being retrieved from our Content Data
> Network instead of our main system in this case.)
> 
> If I enable the "Retrieve All Embedded Resources from HTML Files" flag, and
> tune the test down to 10 threads with 3000 total iterations, I notice a very
> strange behavior. The test runs along at a pretty good clip for the first
> ~600 iterations (about 1 min, 25 seconds into the run), and then it just
> stops making requests for about 35 seconds. Then, it picks back up again and
> runs for another 1 m 25s, and then stops again for 35 seconds... (NOTE: with
> the 10 threads, 3000 total iterations - but with "Retrieve All Embedded..."
> disabled - I don't see the 'stop' behavior either - so it isn't caused by
> tuning it down...)
> 
> I recently added the "Perfmon Metrics Collector" to the test script, so I
> could see if one of the servers was maxed out - but it looks like all the
> servers are idle during the 'stop' period. Likewise, I added the Perfmon for
> the "localhost" (running the JMeter test) to see if it was swamped - but it
> too is idle during the 'stop'. I swapped out our network switch (the test
> environment is on an isolated network switch) with a _much_ higher capacity
> switch - in case there was a network issue, still no change.
> 
> I'm running out of ideas for things to check - so I thought I'd ask you guys
> if you have any suggestions of things I should look at.
> 
> My system consists of:
> 
>       WinXP - running JMeter 2.4.1 - driving the test script in GUI mode
>       Server 1 - running Red Hat Linux, with "Apache (2.2.21)" as the web
> server - using AJP Proxy to Server 2
>       Server 2 - running Red Hat Linux, with Tomcat 7.0.21 as the App
> Server - connecting through Hibernate to Server 3
>       Server 3 - running Red Hat Linux with MySQL 5.x as the DB Server
> 
> All 4 machines are running on a private switched network (32Gbs backplane).
> 
> The requests are downloading about 3MB total (per thread per iteration) over
> 4 main URL requests, and 30+ 'Retrieve All Embedded' requests.
> 
> At first I thought it was the network - but the new switch seemed to deny
> that thought (the old switch had a much slower backplane). Also, I'm having
> no trouble collecting the PerfMon data during the 'stop' period - so the
> network is still functioning just fine...
> Then I thought it might be garbage collection on the tomcat - but I watched
> the gc.log - and it doesn't do any GCs during the 'stop' period.
> Then I thought it might be the garbage collection on the JMeter side, so I
> started the JMeter.bat from a 'cmd' prompt with gc logging enabled - it
> doesn't do any GCs during the 'stop' period either.
> 
> The apache, tomcat, and DB are all 'idle' (no CPU to speak of, no network
> I/O, no disk I/O, etc.) during the 'stop' period.
> 
> The JMeter box (WinXP) is doing very little during that time too (I
> attribute the little bit of activity to displaying the PerfMon graphs, and
> Remote Desktop display to my desktop computer)...
> 
> --
> Robin D. Wilson
> Sr. Director of Web Development
> KingsIsle Entertainment, Inc.
> VOICE: 512-777-1861
> www.KingsIsle.com
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to