Re: [OpenSTA-users] Severe load ramp-up limitation encountered

[Daniel S. <da...@Op...>]

Danny Faught wrote: 
> > You didn't mention any think time in your script.  If you don't
> > have any delays, then I would >anticipate that even a single VU
> > would peg your CPU. 

Dan Downing wrote:
> Well that is true -- no WAITs in this one -- given it is a single
> page; and only one iteration, so no pacing WAITs between iterations
> either. 

Well we know this is not exactly true now from your declaration and
full script posting in the reply to Bernie.  That said Danny's advice
realy needs to be re-iterated: removing all of your WAITs is almost
never a good idea, unless all you want to do is stress all your
servers to breaking point and are not interested in the timing just
what breaks when this happens ...

> That said, LR had no cpu-pegging with these bursts of load... and
> it returned reasonable times (0.5 seconds at the low end). 

I don't think we're comparing like with like though - I've never
really used LR but from what I understand from discussions I've had
with people who do and have used it, its replay actually works
quite differently than the OpenSTA Executor, and may actually be
self throttling to some extent.  ie. when the primary return starts
to slow down then the secondaries will get relevant delays before
they are sent.  The SCL replay will just attempt to keep sending
those secondary GETs at the interval that is given in the script.

This is one of the reasons it is OK to put a SYNCHRONIZE after your
primary GET - it 'sort of' simulates the total slow down as the
primary response times get longer ... although it isn't ideal because
you lose the actual simulation of secondary GETs starting before the
primary has completely finished, which may well happen in a real 
browser.

Not sure if this helps you solve your problem but ...
Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/