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

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

Dan Downing wrote:
> Nothing changed on the server; issue replicated on a second server;
> and yes, have successfully completed other tests since.

So, my questions then would be: what are the similarities of the 2
failure? and, what are the differences between these and the tests
that worked as you expected?

> In the second 'cpu-pegging' example that I did not describe -- a
> much more complex script with minimal millisecond WAITs --
> cpu-pegging problem was solved by inserting randomized 10-20 second
> WAITs between the 26 script steps.

But then you weren't creating as much load ... ?
It is an interesting fact that the (larger) WAITs did help though.  I
wonder if the smaller WAITs were seen by the executor as just not
enough to cause it to pause (once it got behind) and therefore the
potential context switches were few and far between.
Did you try this technique on your other failure and it didn't help?

> > > we eventually accomplished this using LR
> 
> > Out of interest: how much were the LR licenses that allowed you to
> > complete this task?
> 
> Pulled in a favor and used another customer's license :)

Lucky customer this time round ;)

> > Except: look at the content of this page ..It's not well formed
> > HTML at all just a bunch of javascript.
> 
> True...but should this matter?

Only if you are doing a LOAD RESPONSE_INFO BODY with an identifier,
then there is a chance the HTML parser could have got all sorts of
upset.

> > Are you doing any LOAD RESPONSE_INFO's with this content?  Do you
> > have any WAITs left in your script or have they all been edited
> > out? SYNCHRONIZE used?
> 
> No LOAD RESPONSE, had 4 WAIT 25's btw PRIMARY GET and GET URIs did
> *not* use SYNCHRONIZE REQUESTS (see the full script in my response to
> Bernie).

I just went back and had another look at your script - the interesting
point is that you only use a single connection id, was the script
actually recorded this way?  Because the requests all occur on a
single connection then the chances are once load ramps up all of your
WAITs will be totally ignored and you have absolutely no need for any
SYNCHRONIZE between them.  The final SYNCHRONIZE at the end of the
scripts serves absolutely no purpose as there are no connections open
at that point to synchronize with.  If anything, I would have made
your script end:
  SYNCHRONINZE REQUESTS
  End Timer SP01_load_page
  End Timer T_SP_SYN1_V1
  DISCONNECT ALL
Although  I don't think any of this is the source of your issue just
from the fact that Bernie has run this exact script without issues.

Your script is also using HTTP/1.0 but with Keep-Alive - can you
compare this (with the connection usage) to the way that the LR 
repacement was scripted?  Just out of interest.

> Good suggestion about looping, though I resist looping in the script
> because the Summary Results monitor only refreshes when the script
> completes a Commander-controlled iteration -- and you lose run-time
> feedback.

Interesting you mention run-time feedback - what are you watching?
I try to avoid doing any sort of Test monitoring when I'm running a
heavy test that I want accurate timings for - monitoring is something
that can definitely cause extra load ... not that it should but ...

Bernie: were you monitoring your test at runtime?

> > The "Failed processing TOF" error is usually accompanied by
> > another, more meaningful error - I'd be very interested if there
> > is one and if, what it is ...
> 
> There was no other error reported.

Might just be memory shortage being hit, or could be some sort of
corruption.  My gut feeling is that once 'something' in your test
goes 'pear shaped' then it's all down hill from there - what the
original problem is holds the most interest for me.

Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
    OpenSTA part-time caretaker - http://OpenSTA.org/