jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Speteanu <asp.ad...@gmail.com>
Subject Re: Strange 'pause' activity during testing
Date Fri, 16 Dec 2011 09:59:21 GMT
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 <kirk.pepperdine@gmail.com> 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:philippe.mouawad@gmail.com]
> > 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 <rwilson2@gmail.com>
> 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: user-unsubscribe@jmeter.apache.org
> >> For additional commands, e-mail: user-help@jmeter.apache.org
> >>
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> > For additional commands, e-mail: user-help@jmeter.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message