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

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

  
Dan Sutcliffe wrote:
>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?
The similarities between the two examples:
1 - Run on same W2K load server
2 - In the first attempt, script had only the *small* (subsecind) WAITs btw PRIMARY GETs and GET URIs (commented out any longer than 1 second)
3 - Similar aggressive load ramp per Task Group -- 100vu/goup, 50 users/batch, 3 seconds/batch, 1 sec. batch ramp-up (later reduced to 1 vu/batch, 3 sec/batch, 1 sec. bath rampup)
The differences:
1 - Many pages, each with many resources, using multiple conids, lots of LOAD RESPONSEs
2 - Reading a file with 26 comma-delimited script parameters, then calling a routine that parsed these out into local variables
>> 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 ... ?
Correct; 1/20th the vusers, about 1 minute end-end response time for the script.
>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?
Definitely, it is the 10-20 secind WAITs that solved the cpu-pegging problem (this after we worked on tuning the data-parsing code, which we thought might be the problem--it wasn't).
>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? 
Yes, it was recorded this way; I did not notice there was a single conid for all the GETs til, you two mentioned it.
>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:
>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.
Yeah. I will have to retest this on my other laptop from home with my Verizon FIOS 15 Megabit connection--and will send another report.
>> 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?
Was watching the opensta Summary Results, plus perfmon on our load driver.
>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.
Roger this.
 
...Dan
www.mentora.com



...Dan
Dan Downing
www.mentora.com