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

[Dan D. <ddo...@me...>]

Dan,
Responses to your queries below...
>Has this 'hefty load server' been used successfully on similar gigs >in the past? If so, has ANYTHING changed on it since then? Can you go back and recreate the successful load tests on it now?
Nothing changed on the server; issue replicated on a second server; and yes, have successfully completed other tests since.  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.
>> 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 :)
>> The Script:? Could not be simpler -- a single page with nothing more 
>> than the customer's logo.?
>So you're saying the content can't really be at fault and we can >create any simple HTML Web page with a graphic in it to simulate >the same problem ...
Correct.  And looks like Bernie used the essence of my script, but was unable to replicate.
>> PRIMARY GET URI
>> "http://syn1.sellpoint.net/QA/smloadtest.html HTTP/1.0" ON 1?? HEADER 
>> DEFAULT_HEADERS ,WITH {"{the usual stuff here"}
>Except: look at the content of this page ..It's not well formed >HTML at all just a bunch of javascript.
True...but shouldthis matter?
>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).
>As your script is so short I would have considered doing looping in >the script rather than having the Test Executer doing the >iterating - it theoretically should save you some HP. Your Task >setup sounds a little overcomplicated but that in itself should not >cause you a serious resource problem unless you are hitting a bug - >besides from another email you suggest that a much simpler task >setup produce similar awful results.
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.
>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.
>> These timer results were proven "false" when
>> (a) customer (and us) could hit the page manually and get <5 seconds 
>> response at something under 1000 v-users, and (b) subsequent test with 
>As soon as the CPU and/or memory starts thrashing on a load >generating machine just throw the results away - they are worthless!
>:shrug: Sorry - this will always be the case, and I'm sure it is >with LR and others as well.
Good point, and I agree.  Timers are reporting the entire bottleneck time at this point.
> I believe understanding of and/or resolution of this apparent 
>> 'load-driving bottleneck' to be of pivotal interest to all serious opensta users.
>Absolutely! Let's get to the bottom of what happened and then you >can pay me to fix it ;)
I am starting a list of issues to discuss / compare against other current top pet peeves/bugs -- and have you fix -- to be followed by a check. Bernie is not the only one whose business is heavily dependent on opensta :) !

...Dan
Dan Downing www.mentora.com