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

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

Bernie wrote:
>>Daniel wrote:
>>I am sure we are not. Notice the connection ids are all 1 in the >full script Dan posted. LR is surely sending the secondary gets in >parallel and most likely prior to the primary get finishing. That >would alert me to the possibility that response times reported by >the two tools may very well be different.
>> 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.
>I suspect Dan edited the connection Ids to be all 1, or perhaps the script is >synthetic and was not the product of a recording. In any event, I'd consider >putting the primary get on id 1, followed by a synchronize command, followed >by the secondary gets each having a seperate channel Id, followed by a >synchronize and then an end timer command. Of course I could be talking out >of my hat here... not knowing all the details and this could all be putting >too fine a point on things given that Dan has a much bigger problem on his >hands in that the test won't run!
DanD responds:
Bernie, this script was recorded, connection IDs were not edited; but I will be trying your suggestions anyway...given how perplexing this behavior was, and how suspect it made me that perhaps I've been reporting inacurate response times on *other* projects where cpus was *not* pegged.
...Dan
Dan Downing
www.mentora.com