Of course, no problems on test client points to the fact that you should start investigating the application :).
Use jdk's jvisualvm & visualgc to monitor the application under test. On Fri, Dec 16, 2011 at 7:34 AM, Kirk <[email protected]> wrote: > Summary > > JMeter Machine > CPU is idle, network is idle, no GC during "lockup". No matter, GC will > drive CPU utilization high so the fact that CPU is idle suggest resource > starvation.. i.e. all of the JMeter threads will be found to be blocked on > a socket call.. i.e. the problem is in your application and not JMeter. > > I think you need outside help as the problems you're facing go beyond a > simple Q&A here. Sorry to spam the list but I do offer tuning services and > a performance tuning course. We can talk off-line about either if your > interested. > > Kind regards, > Kirk Pepperdine > > On Dec 15, 2011, at 9:40 PM, Robin D. Wilson wrote: > > > I don't use CacheManager (since that would defeat the purpose of the > test - > > which is to exercise the entire system for all assets from the pages > being > > requested). > > > > I have logged the GCs (without removing the plugins), and it doesn't do > any > > GCs at all during the 'pause' period. The GC right before the pause takes > > less than a second (.26...) and the one right after is in the same > ball-park > > of duration. But during the pause, no GCs at all occur. > > > > CPU goes to idle on the JMeter box during the pause (as does network and > > disk I/O, and swap usage). There is a _little_ activity, but I've been > > attributing that to the Remote Desktop I'm using to get to the box, and > the > > PerfMon graphs that are still collecting data. But compared to before and > > after the pause the activity level is less than 2% during the 'pause' > > period, compared to 75-80% during the 'run' period. > > > > I will try to get the thread dump - I'm working on some production issues > > today, so I haven't had time to setup for a thread dump today. > > > > -- > > Robin D. Wilson > > Sr. Director of Web Development > > KingsIsle Entertainment, Inc. > > VOICE: 512-777-1861 > > www.KingsIsle.com > > > > > > -----Original Message----- > > From: Philippe Mouawad [mailto:[email protected]] > > Sent: Thursday, December 15, 2011 2:23 PM > > To: JMeter Users List > > Subject: Re: Strange 'pause' activity during testing > > > > Do you use CacheManager ? > > You should remove any plugin and activate GC logs to check it's not GC ? > > How is CPU on JMeter stack ? > > > > Regards > > Philippe > > > > > > On Thu, Dec 15, 2011 at 9:09 PM, Robin D. Wilson <[email protected]> > wrote: > > > >>> Maybe then there is a problem with the scanning of the HTML to > >>> extract the > >> embedded resources, or maybe one of the embedded resources is a tar-pit. > >> > >> If this were the case, I would expect the first sample to show the > > problem. > >> The fact that it does 600+ iterations without a problem - and _then_ > >> stalls seems like it rules out any problem with the returned HTML > >> (especially since the only difference in the returned result is the > >> username supplied by JMeter). > >> > >>> Do all the expected embedded resources get downloaded? > >> > >> Zero errors (even with the pauses there are no errors at all). > >> > >>> Are there any unusually long elapsed times for embedded resources? > >> > >> I see the 'max request duration' jump up right after the pause - but > >> it is only 10-11 seconds (not ~35 seconds like the pause). > >> > >>> Or large gaps between the parent sample download completion and the > >>> start > >> of the first embedded resource? > >> > >> Not that I can see... I'll see if I can get more detail on this. > >> > >>> That would suggest the page took a while to parse. > >> > >> I would assume that because this happens ~600+ iterations into the > >> test (the first time), that if it was related to parsing the page, I > >> would see it earlier in the test run cycle. And I wouldn't expect a > >> parsing problem to repeat on such a consistent basis - without > >> happening on every sample. > >> Right > >> now, if it is a parsing problem, it only happens the ~600th time it > >> sees the same page, which seems really surprising to me (then it > >> happens again after another ~600 iterations, etc.). Also, I would > >> expect the parser to take up some CPU and perhaps even some I/O > >> cycles, but the PerfMon shows idle during the pause period. > >> > >>> You'll need to select the optiion to "save subresults" in order to > >>> see the > >> embedded samples. > >> > >> ... > >> > >> > >>> BTW, you wrote you were running JMeter 2.4.1 - that does not exist, > >>> so > >> perhaps you meant the current version, 2.5.1? > >> > >> Sorry, I meant 2.4. I didn't upgrade to 2.5 (and beyond) because of a > >> previously reported problem where 2.5+ slows down my throughput to > >> about 60% of what I get on 2.4. > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > > > -- > > Cordialement. > > Philippe Mouawad. > > > > > > --------------------------------------------------------------------- > > 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] > >
