I think the original post mentioned that GC was not running.
can you take a thread dump when there is a pause and see what the threads
are waiting on?



On Wed, Dec 14, 2011 at 1:56 PM, Kirk <[email protected]> wrote:

> 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