opensta-users — OpenSTA users discussion and support

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

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

Bernie Velivis wrote:
> Aside from the synchronize requests appearing after the end timer
> for SP01_load_page, there is nothing in the script that looks
> suspicous to me.

I'm never sure about the SYNCHRONIZE at the end of a script - I
wonder if SCL flow just ends without any SYNCHRONIZE whether the 
connections just get dropped even if they haven't completed or
whether, in fact, there is kind of automatic SYNCHRONIZE when a
script comes to an end - ie. the script doesn't actually end until
all of its active connections have finished doing there stuff ...
and what does this mean if you are using HTTP keep-alive?  Will it
wait until connection timeout? or stop when active HTTP requests
are all done?

> Perhaps you are assuming the disconnect 1 command is a synchronize
> command?  I dont think it is.

According to the documentation a DISCONNECT <conid> will actually
wait until the HTTP requests on the connection have finished before
closing the TCP connection - so in one sense the DISCONNECT does
act like a SYNCHRONIZE for a single connection.  If you do a
DISCONNECT ALL then that would be like a SYNCHRONIZE followed by
clowing all the TCP connections.

Don Downing wrote:
> > Now, as to my installation issue on my XP Pro/SP2 laptop:
> > Modeler and name server work fine, but I cannot open a Test,
> > and the icon for the Test in the Commander Explorer appears as a
> > "Windows Generic" icon rather than the red-blue-green clover
> > icon.  I just deinstalled/reinstalled.  Figure I must have a
> > conflict with some other app/dll...Ever encounter this?

I think this is just a Windows-ism, something which actually seemed
to get better in XP - who knows what causes it but it is a sign of
unpleasant things happening in your registry ...

> Also, I tried your script verbatim, and saw longer response times
> (makes sense, my original had only 1 get, again more or less linear
> to 500 users but sp01_load_page timer ranged from .96 to 40 seconds.

So this might be a Windows 2000 Server thing - although I don't
remember anyone reporting potential issues with this OS before,
I remember 2003 Server gripes that we never got to the bottom of
but not W2K Server to my recollection.

> Minus the network differences, this seems to indicate a problem
> unique to your load server.

Or something that is being masked by your more limited intermediate
network - we really need some tests in a fast switched LAN
environment to rule out this potential explanation.  It does however
seem much more likely that this is an OS version related thing.

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

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/

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

[Bernie V. <Ber...@iP...>]

Dan,

> Your test config looks the same, and despite your 10MB link, interesting 
> that you did not peg your cpu or see abnormal paging.  What Timer values 
> did you get at various points pon your way to 1000 vu?

More or less linear from 1 to 500 VUs,  response time ranged from .2 to 10 
seconds for the one page I was downloading.

> What OS are you running on your laptop?  My server is running a Windows 
> 2000 Server SP4; this server is hosted in a Tier 1 datacenter in a 100MB 
> network.  Server has dual 100MB NICs.  I replicated this result on a 
> second similar server too.

XP Pro Version 2002, SP2

> I have seven INTEGER local variables defined (part of my stabdard 
> randomized ThinkTime vars)--but was not using them.  And contrary to my 
> earlier response about WAITs, I actually had four WAIT 25 between the 
> PRIMARY GET and the 4 subsequent GET URIs.  The full script is below.

Asside from the synchronize requests appearing after the end timer for 
SP01_load_page, there is nothing in the script that looks suspicous to me. 
Perhaps you are assuming the disconnect 1 command is a synchronys command? I 
dont think it is.

> Now, as to my installation issue on my XP Pro/SP2 laptop:  Modeler and 
> name server work fine, but I cannot open a Test, and the icon for the Test 
> in the Commander Explorer appears as a "Windows Generic" icon rather than 
> the red-blue-green clover icon.  I just deinstalled/reinstalled.  Figure I 
> must have a conflict with some other app/dll...Ever encounter this?


Haven't seen that before.

Also, I tried your script verbatim, and saw longer response times (makes 
sense, my original had only 1 get, again more or less linear to 500 users 
but sp01_load_page timer ranged from .96 to 40 seconds.

Minus the network differences, this seems to indicate a problem unique to 
your load server.

-Bernie


----- Original Message ----- 
From: "Dan Downing" <ddo...@me...>
To: <ope...@li...>
Sent: Friday, July 13, 2007 9:42 AM
Subject: [OpenSTA-users] FW: Severe load ramp-up limitation encountered


> Bernie Velivis wrote:
>>I can't replicate your problem, but I am currently sitting behind a 10Mb 
>>cable >modem and am therefore running a different test.
>>I was able to ramp up to 1000 users with no errors (expect some 10060 
>>network >timeouts which seem reasonable given my slow link)
>>My runtime parameters were:
>>Total number of users for this task Group: 1000 # virtual users for timer 
>> >results 1000 # of virtual users for http results: 1
>>Batch start options:
>>interval between batches: 1
>>Number of virt users per batch: 5
>>Batch ramp up time (seconds): 1
>>My script was set to loop for 1 hour and consisted of;
>>Start Timer T_DANDOWNING
>>PRIMARY GET URI "http://syn1.sellpoint.net/QA/smloadtest.html HTTP/1.0" ON
>>You dont have any large local variables defined do you?
>>FYI- I forced my 3.06 Ghz P4 Pentium processor to run at 1.5 Ghz, I have 
>>2GB of memory. CPU utilization never got much over 20% and I saw no 
>>abnormal paging.
> Bernie,
> How good of you to attempt to replicate...and I will follow suit, seeing 
> if I can replicate on my laptop (soon as I can resolve my local opensta 
> installation issue--see question below).
> Your test config looks the same, and despite your 10MB link, interesting 
> that you did not peg your cpu or see abnormal paging.  What Timer values 
> did you get at various points pon your way to 1000 vu?
>
> What OS are you running on your laptop?  My server is running a Windows 
> 2000 Server SP4; this server is hosted in a Tier 1 datacenter in a 100MB 
> network.  Server has dual 100MB NICs.  I replicated this result on a 
> second similar server too.
> I have seven INTEGER local variables defined (part of my stabdard 
> randomized ThinkTime vars)--but was not using them.  And contrary to my 
> earlier response about WAITs, I actually had four WAIT 25 between the 
> PRIMARY GET and the 4 subsequent GET URIs.  The full script is below.
> Now, as to my installation issue on my XP Pro/SP2 laptop:  Modeler and 
> name server work fine, but I cannot open a Test, and the icon for the Test 
> in the Commander Explorer appears as a "Windows Generic" icon rather than 
> the red-blue-green clover icon.  I just deinstalled/reinstalled.  Figure I 
> must have a conflict with some other app/dll...Ever encounter this?  Will 
> try on my other laptop when I get home...
> Thanks for your help!
> =========
> !Browser:IE5
> !Date : 6/20/2007
> Environment
> Description ""
> Mode  HTTP
> Wait  UNIT MILLISECONDS
> Definitions
> ! Standard Defines
> Include   "RESPONSE_CODES.INC"
> Include   "GLOBAL_VARIABLES.INC"
> CHARACTER*512 USER_AGENT
> Integer   USE_PAGE_TIMERS
> CHARACTER*256 MESSAGE
>
> !********************************************************************************
> ! These standard declarations follow Cookie definitions
>
> Integer  User_Think_Br (2 - 5)
> Integer  User_Think_Type (3 - 5)
> Integer  User_Think_Go (1-20) ! after semaphore
> Integer  User_Think
> Integer  Pacing_Between (2-3)
> Integer  Pacing
> Integer  WAITTime  ! for looping for response
> Timer   T_SP_SYN1_V1
> Timer   SP01_load_page
> CONSTANT  DEFAULT_HEADERS = "Host: syn1.sellpoint.net^J" &
>  "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 
> 2.0.50727)"
> Code
> !Read in the default browser user agent field
> Entry[USER_AGENT,USE_PAGE_TIMERS]
> Start Timer T_SP_SYN1_V1
> Start Timer SP01_load_page
> WAIT 25
>
> PRIMARY GET URI "http://syn1.sellpoint.net/QA/smloadtest.html HTTP/1.0" ON 
> 1 &
>  HEADER DEFAULT_HEADERS &
>  ,WITH {"Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, " &
>    "application/vnd.ms-powerpoint, application/vnd.ms-excel, 
> application/msword, " &
>    "application/x-shockwave-flash, */*", &
>   "Accept-Language: en-us", &
>   "Connection: Keep-Alive"}
> WAIT 25!328
>  GET URI "http://syn1.sellpoint.net/QA/tentoe2.com HTTP/1.0" ON 1 &
>   HEADER DEFAULT_HEADERS  &
>   ,WITH {"Accept: */*", &
>    "Referer: http://syn1.sellpoint.net/QA/smloadtest.html", &
>    "Accept-Language: en-us", &
>    "Connection: Keep-Alive"}
>  WAIT 25!156
>  GET URI "http://syn1.sellpoint.net/Tentoe/vsr_common.js HTTP/1.0" ON 1 &
>   HEADER DEFAULT_HEADERS  &
>   ,WITH {"Accept: */*", &
>    "Referer: http://syn1.sellpoint.net/QA/smloadtest.html", &
>    "Accept-Language: en-us", &
>    "Connection: Keep-Alive"}
>  WAIT 25!172
>  GET URI &
>   "http://syn1.sellpoint.net/Syndicate/" &
> 
> "SynImage?r=1182394421812&ttpid=TTPID-ADA-1380&vsr_sku=smproduct3-1&vsr_price=23.4&vsr_stock=23&" 
> &
> 
> "vsr_button_url=http%3A//syn1.sellpoint.net/images/sellpoint-logo.gif&vsr_shopping_cart=http%3A/" 
> &
>    "/www.sellpoint.net HTTP/1.0" ON 1 &
>   HEADER DEFAULT_HEADERS  &
>   ,WITH {"Accept: */*", &
>    "Referer: http://syn1.sellpoint.net/QA/smloadtest.html", &
>    "Accept-Language: en-us", &
>    "Connection: Keep-Alive"}
>  WAIT 25!141
>  GET URI "http://syn1.sellpoint.net/images/sellpoint-logo.gif HTTP/1.0" ON 
> 1 &
>   HEADER DEFAULT_HEADERS  &
>   ,WITH {"Accept: */*", &
>    "Referer: http://syn1.sellpoint.net/QA/smloadtest.html", &
>    "Accept-Language: en-us", &
>    "Connection: Keep-Alive"}
>  DISCONNECT FROM 1
> End Timer SP01_load_page
>  SYNCHRONIZE REQUESTS
> End Timer T_SP_SYN1_V1
> Exit
> ERR_LABEL:
> If (MESSAGE <> "") Then
>  Report MESSAGE
> Endif
> Exit
> =============
>
>
>
> ...Dan
> Dan Downing www.mentora.com
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> -- 
> OpenSTA-users mailing list Ope...@li...
> Subscribe/Unsubscribe/Options: 
> http://lists.sf.net/lists/listinfo/opensta-users
> Posting Guidelines: 
> http://portal.opensta.org/faq.php?topic=UserMailingList 

[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

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

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

Bernie Velivis wrote:
>I can't replicate your problem, but I am currently sitting behind a 10Mb cable >modem and am therefore running a different test.
>I was able to ramp up to 1000 users with no errors (expect some 10060 network >timeouts which seem reasonable given my slow link)
>My runtime parameters were:
>Total number of users for this task Group: 1000 # virtual users for timer >results 1000 # of virtual users for http results: 1
>Batch start options:
>interval between batches: 1
>Number of virt users per batch: 5
>Batch ramp up time (seconds): 1
>My script was set to loop for 1 hour and consisted of;
>Start Timer T_DANDOWNING
>PRIMARY GET URI "http://syn1.sellpoint.net/QA/smloadtest.html HTTP/1.0" ON
>You dont have any large local variables defined do you?
>FYI- I forced my 3.06 Ghz P4 Pentium processor to run at 1.5 Ghz, I have 2GB of memory. CPU utilization never got much over 20% and I saw no abnormal paging.
Bernie,
How good of you to attempt to replicate...and I will follow suit, seeing if I can replicate on my laptop (soon as I can resolve my local opensta installation issue--see question below).
Your test config looks the same, and despite your 10MB link, interesting that you did not peg your cpu or see abnormal paging.  What Timer values did you get at various points pon your way to 1000 vu?

What OS are you running on your laptop?  My server is running a Windows 2000 Server SP4; this server is hosted in a Tier 1 datacenter in a 100MB network.  Server has dual 100MB NICs.  I replicated this result on a second similar server too.
I have seven INTEGER local variables defined (part of my stabdard randomized ThinkTime vars)--but was not using them.  And contrary to my earlier response about WAITs, I actually had four WAIT 25 between the PRIMARY GET and the 4 subsequent GET URIs.  The full script is below.
Now, as to my installation issue on my XP Pro/SP2 laptop:  Modeler and name server work fine, but I cannot open a Test, and the icon for the Test in the Commander Explorer appears as a "Windows Generic" icon rather than the red-blue-green clover icon.  I just deinstalled/reinstalled.  Figure I must have a conflict with some other app/dll...Ever encounter this?  Will try on my other laptop when I get home...
Thanks for your help!
=========
!Browser:IE5
!Date : 6/20/2007
Environment
Description ""
Mode  HTTP
Wait  UNIT MILLISECONDS
Definitions
! Standard Defines
Include   "RESPONSE_CODES.INC"
Include   "GLOBAL_VARIABLES.INC"
CHARACTER*512 USER_AGENT
Integer   USE_PAGE_TIMERS
CHARACTER*256 MESSAGE

!********************************************************************************
! These standard declarations follow Cookie definitions

Integer  User_Think_Br (2 - 5)
Integer  User_Think_Type (3 - 5)
Integer  User_Think_Go (1-20) ! after semaphore
Integer  User_Think
Integer  Pacing_Between (2-3)
Integer  Pacing
Integer  WAITTime  ! for looping for response
Timer   T_SP_SYN1_V1
Timer   SP01_load_page
CONSTANT  DEFAULT_HEADERS = "Host: syn1.sellpoint.net^J" &
  "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 2.0.50727)"
Code
!Read in the default browser user agent field
Entry[USER_AGENT,USE_PAGE_TIMERS]
Start Timer T_SP_SYN1_V1
Start Timer SP01_load_page
WAIT 25

PRIMARY GET URI "http://syn1.sellpoint.net/QA/smloadtest.html HTTP/1.0" ON 1 &
  HEADER DEFAULT_HEADERS &
  ,WITH {"Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, " &
    "application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, " &
    "application/x-shockwave-flash, */*", &
   "Accept-Language: en-us", &
   "Connection: Keep-Alive"}
WAIT 25!328
  GET URI "http://syn1.sellpoint.net/QA/tentoe2.com HTTP/1.0" ON 1 &
   HEADER DEFAULT_HEADERS  &
   ,WITH {"Accept: */*", &
    "Referer: http://syn1.sellpoint.net/QA/smloadtest.html", &
    "Accept-Language: en-us", &
    "Connection: Keep-Alive"}
  WAIT 25!156
  GET URI "http://syn1.sellpoint.net/Tentoe/vsr_common.js HTTP/1.0" ON 1 &
   HEADER DEFAULT_HEADERS  &
   ,WITH {"Accept: */*", &
    "Referer: http://syn1.sellpoint.net/QA/smloadtest.html", &
    "Accept-Language: en-us", &
    "Connection: Keep-Alive"}
  WAIT 25!172
  GET URI &
   "http://syn1.sellpoint.net/Syndicate/" &
    "SynImage?r=1182394421812&ttpid=TTPID-ADA-1380&vsr_sku=smproduct3-1&vsr_price=23.4&vsr_stock=23&" &
    "vsr_button_url=http%3A//syn1.sellpoint.net/images/sellpoint-logo.gif&vsr_shopping_cart=http%3A/" &
    "/www.sellpoint.net HTTP/1.0" ON 1 &
   HEADER DEFAULT_HEADERS  &
   ,WITH {"Accept: */*", &
    "Referer: http://syn1.sellpoint.net/QA/smloadtest.html", &
    "Accept-Language: en-us", &
    "Connection: Keep-Alive"}
  WAIT 25!141
  GET URI "http://syn1.sellpoint.net/images/sellpoint-logo.gif HTTP/1.0" ON 1 &
   HEADER DEFAULT_HEADERS  &
   ,WITH {"Accept: */*", &
    "Referer: http://syn1.sellpoint.net/QA/smloadtest.html", &
    "Accept-Language: en-us", &
    "Connection: Keep-Alive"}
  DISCONNECT FROM 1
End Timer SP01_load_page
  SYNCHRONIZE REQUESTS
End Timer T_SP_SYN1_V1
Exit
ERR_LABEL:
If (MESSAGE <> "") Then
  Report MESSAGE
Endif
Exit
=============



...Dan
Dan Downing www.mentora.com

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

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

>Dan Downing wrote: 
>> So, whatever resources I am taxing, it occurs even with a single Task Group.  

>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. 

Well that is true--no WAITs in this one -- given it is a single page; an only one iteration, so no pacing WAITs between iterations either. 

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


...Dan


Dan Downing

www.mentora.com

Re: [OpenSTA-users] Problems recording Cookies

[Bernie V. <Ber...@iP...>]

> Huge thanks go to Bernie @ Performax for sponsoring much of this
> investigation and providing feedback and testing to support my
> theories.

My pleasure Daniel. Without a lot of these changes, I'd be loosing business. 
I've been delivering performance testing and engineering services since 2002 
almost exclusively with OpenSTA. Its a pretty simple proposition; if OpenSTA 
is misbehaving or lacking in functionality, and you are generating revenue 
using it (or worse, about to loose some business), its makes sense to 
outsource to an expert like you to bridge the gaps.

Bernie Velivis
Performax Inc (www.iPerformax.com)
2 Colburn Lane, Hollis, NH 03049, 603.860.7900 

[OpenSTA-users] Problems recording Cookies

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

Recently I got to delve deeply into the workings of the current
OpenSTA Gateway's mechanism of Cookie recording and the Modelers
creating SCL code from this to dynamically handle Cookies.

It has always been known that there are some 'issues' in this area
but no-one has really spent the time to thoroughly investigate this
and work out what they were ... until now.

The more astute of you may have noticed I've logged a whole bunch of
bugs recently related to this very subject.  I've also updated the
entry in the FAQ:
  http://portal.opensta.org/faq.php?topic=RecordingCookies

I'm not exactly impressed with the way Cookies are currently recorded
or the SCL code that is created - IMHO it all needs re-implementing -
saying that, it does seem to work 95% of the time. :shrug:

Rather than write an epic about all the problems and idiosyncrasies
that I found I'd like to invite those that are interested to read the
above FAQ entry and its linked bug reports and fire any questions you
have at me now while it is still fresh in my mind. :)

Huge thanks go to Bernie @ Performax for sponsoring much of this
investigation and providing feedback and testing to support my
theories.
Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

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

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

=20
> >Dan Downing wrote: =20
>>> The Test: Two load =20
>>> servers (dual 1Ghz P4s, 1 GB memory). On each, test had 20 Task =20
>>> Groups with this one script, in v-user "burst" =20
>>> groups of 50, 100, 150,...1000, doing a single iteration. Each group t=
o=A0=A0=20
>>> be launch 3 minutes apart =20
>>> (allowing the web server to settle from the previous burst). Ramp rat=
e=A0=A0=20
>>> of 300 users per minute (batch =20
>>> settings: 1/5/1 (interval btw =20
>>> batches/vusers per batch/batch ramp time). =20
> =20
>>Danny Faught wrote: =20
>>I'm curious if you tried to set up this scenario using a single task=A0=
=A0=20
>>group. I would guess >that if you could get what you want that way, it=A0=
=A0=20
>>would put less stress on your load >generators. =20
>>--=A0=A0=20
>>Danny R. Faught =20
> =20
> Danny, Thanks for your suggestion. While I did not try modeling the=A0=A0=
=20
> *entire set* of Task Groups into a single Task Group, I *did* (just thi=
s=A0=A0=20
> morning) re-run *just one* Task Group with 400 users -- and managed to p=
eg=A0=A0=20
> the cpu and drive up the pages/sec. just the same. =20
> =20
> So, whatever resources I am taxing, it occurs even with a single Task=A0=
=A0=20
> Group. =20
 =20
Bernie wrote: =20
=20
 =20
=20
>I'm having a little trouble visualizing what is happening. Could=20
you reply with the VU >parameters (i.e. batch start options, total=20
number of users, number of vir users for timers=20
>and http result)=20
for the single task group test? =20
=20
 =20
>>A picture is worth a few hundred words (depreciation).=A0 See attached.=
 =20
 Hmmm...can't send an attachment!#@?=20
OK; verbal it is.=20
1 task group, 400 vusers; 5 vu per batch, 1 sec between batches, 1 second=
 batch ramp-up.=20
=20
=2E..Dan=20
 =20
Dan Downing=20
 =20
 www.mentora.com=20
 =20

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

[Danny R. F. <fa...@te...>]

Dan Downing wrote:
> So, whatever resources I am taxing, it occurs even with a single Task Group. 

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.
-- 
Danny R. Faught
Tejas Software Consulting
http://tejasconsulting.com/

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

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

Dan Downing wrote:
> Hi opensta gurus (you know who you are):

Bernie: do you ever feel left out that your name isn't Dan?  ;)

Sorry to hear about your issues Dan, I've heavily clipped your
mail and asked a few, hopefully relevant, questions below:

> After several years of using opensta successfully on dozens of
> customer load tests, in the last 2 weeks I have attempted two
> projects with aggressive load ramp-ups where opensta flattened
> my hefty load server and reported *unrealistically high*
> response times even at low load -- and thus failed miserably (to
> great embarrassment with the customer

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?

> we eventually accomplished this using LR

Out of interest: how much were the LR licenses that allowed you to 
complete this task?

> 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 ...

> 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.

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?

> The Test:? Two load servers (dual 1Ghz P4s, 1 GB memory).?  On
> each, test had 20 Task Groups with this one script, in v-user "burst"
> groups of 50, 100, 150,...1000, doing a single iteration.? Each group
> to be launch 3 minutes apart (allowing the web server to settle from
> the previous burst).?? Ramp rate of 300 users per minute (batch
> settings:? 1/5/1 (interval btw batches/vusers per batch/batch ramp time).

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.

> The result:? (1)
> Test appeared to start up and run smoothly, until Group 8 (400-user burst)
> launched--at which point Error Log reports "Failed processing for TOF
> record for script line 59" (the PRIMARY GET); and what's worse, the Timer
> shows times at 50 users of about 2 seconds, rapidly climbing to 3.5 seconds at
> 100, to 10 seconds at 200, 20 seconds at 200, 30 seconds at 350...and so forth
> all the way to 60 seconds.

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 ...

> 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 LR
> showed these times to range from .7 seconds at just under 150 users, 5 seconds
> at 1000 users, and up to 9 seconds at 2000 users.
>
> Furthermore, perfmon showed that out dual-cpu server
> shoots up to 100% utilization when Task Group8 (400 users) starts--and stays
> there; and memory pages/sec. shoots up from an average of 8 to around 50, which
> spikes to 400 (I have a screen shot that shows this if want to see it).

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.

> 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 ;)
Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

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

[Bernie V. <Ber...@iP...>]

> Dan,
>
> I'm having a little trouble visualizing what is happening. Could you reply
> with the VU parameters (i.e. batch start options, total number of users,
> number of vir users for timers and http result) for the single task group
> test?

I hate to respond to my own posts, but "never mind". You included the info I 
asked for in a prior post.

I can't replicate your problem, but I am currently sitting behind a 10Mb 
cable modem and am therefore running a different test.

I was able to ramp up to 1000 users with no errors (expect some 10060 
network timeouts which seem reasonable given my slow link)

My runtime parameters were:

Total number of users for this task Group: 1000
# virtual users for timer results 1000
# of virtual users for http results: 1

Batch start options:
interval between batches: 1
Number of virt users per batch: 5
Batch ramp up time (seconds): 1

My script was set to loop for 1 hour and consisted of;

 Start Timer T_DANDOWNING
 PRIMARY GET URI "http://syn1.sellpoint.net/QA/smloadtest.html HTTP/1.0" ON 
1 &
  HEADER DEFAULT_HEADERS &
  ,WITH {"Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, " &
    "application/x-shockwave-flash, application/vnd.ms-excel, 
application/vnd.ms-powerpoint, " &
    "application/msword, */*", &
   "Accept-Language: en-us", &
   "Connection: Keep-Alive"}
 SYNCHRONIZE REQUESTS
 End Timer T_DANDOWNING

You dont have any large local variables defined do you?

FYI- I forced my 3.06 Ghz P4 Pentium processor to run at 1.5 Ghz, I have 2GB 
of memory. CPU utilizaiotn never got much over 20% and I saw no abnormal 
pagingl.

-Bernie

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

[Bernie V. <Ber...@iP...>]

Dan,

I'm having a little trouble visualizing what is happening. Could you reply 
with the VU parameters (i.e. batch start options, total number of users, 
number of vir users for timers and http result) for the single task group 
test?

-Bernie

----- Original Message ----- 
From: "Dan Downing" <ddo...@me...>
To: <ope...@li...>
Sent: Thursday, July 12, 2007 3:34 PM
Subject: Re: [OpenSTA-users] Severe load ramp-up limitation encountered


> >Dan Downing wrote:
>>> The Test: Two load
>>> servers (dual 1Ghz P4s, 1 GB memory). On each, test had 20 Task
>>> Groups with this one script, in v-user "burst"
>>> groups of 50, 100, 150,...1000, doing a single iteration. Each group to 
>>> be launch 3 minutes apart
>>> (allowing the web server to settle from the previous burst). Ramp rate 
>>> of 300 users per minute (batch
>>> settings: 1/5/1 (interval btw
>>> batches/vusers per batch/batch ramp time).
>
>>Danny Faught wrote:
>>I'm curious if you tried to set up this scenario using a single task 
>>group. I would guess >that if you could get what you want that way, it 
>>would put less stress on your load >generators.
>>-- 
>>Danny R. Faught
>
> Danny, Thanks for your suggestion. While I did not try modeling the 
> *entire set* of Task Groups into a single Task Group, I *did* (just this 
> morning) re-run *just one* Task Group with 400 users -- and managed to peg 
> the cpu and drive up the pages/sec. just the same.
>
> So, whatever resources I am taxing, it occurs even with a single Task 
> Group.
>
>
>
> ...Dan
>
>
> Dan Downing
>
>
> www.mentora.com
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> -- 
> OpenSTA-users mailing list Ope...@li...
> Subscribe/Unsubscribe/Options: 
> http://lists.sf.net/lists/listinfo/opensta-users
> Posting Guidelines: 
> http://portal.opensta.org/faq.php?topic=UserMailingList 

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

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

>Dan Downing wrote:=20
>> The Test:=A0 Two load=20
>> servers (dual 1Ghz P4s, 1 GB memory).=A0 On each, test had 20 Task =20
>> Groups with this one script, in v-user "burst"=20
>> groups of 50, 100, 150,...1000, doing a single iteration.=A0 Each grou=
p to be launch 3 minutes apart=20
>> (allowing the web server to settle from the previous burst).=A0=A0 Ram=
p rate of 300 users per minute (batch=20
>> settings:=A0 1/5/1 (interval btw=20
>> batches/vusers per batch/batch ramp time).=20
=20
>Danny Faught wrote:=20
>I'm curious if you tried to set up this scenario using a single task gro=
up.=A0 I would guess >that if you could get what you want that way, it wo=
uld put less stress on your load >generators.=20
>--=20
>Danny R. Faught=20
=20
Danny, Thanks for your suggestion.=A0 While I did not try modeling the *e=
ntire set* of Task Groups into a single Task Group, I *did* (just this mo=
rning) re-run *just one* Task Group with 400 users -- and managed to peg t=
he cpu and drive up the pages/sec. just the same.=20
=20
So, whatever resources I am taxing, it occurs even with a single Task Gro=
up.=20
=20
=20

=2E..Dan
=20

Dan Downing
=20

www.mentora.com
=20

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

[Danny R. F. <fa...@te...>]

Dan Downing wrote:
> The Test:  Two load
> servers (dual 1Ghz P4s, 1 GB memory).  On
> each, test had 20 Task Groups with this one script, in v-user "burst"
> groups of 50, 100, 150,...1000, doing a single iteration.  Each group to be launch 3 minutes apart
> (allowing the web server to settle from the previous burst).   Ramp rate of 300 users per minute (batch
> settings:  1/5/1 (interval btw
> batches/vusers per batch/batch ramp time).

I'm curious if you tried to set up this scenario using a single task
group.  I would guess that if you could get what you want that way, it
would put less stress on your load generators.
-- 
Danny R. Faught
Tejas Software Consulting
http://tejasconsulting.com/

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

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

Hi opensta gurus (you know who you are):




After several years of using opensta successfully on
dozens of customer load tests, in the last 2 weeks I have attempted two
projects with aggressive load ramp-ups where opensta flattened my hefty l=
oad
server and reported *unrealistically high* response times even at low loa=
d --
and thus failed miserably (to great embarrassment with the customer--we
eventually accomplished this using LR).




I seek your advice as to whether (a) there is/are tool or
system config settings I need to make, (b) there is something silly I hav=
e
simply missed, (c) there a bug lurking I should document and report, (d) I=
 have
hit an architectural limitation of the tool, (e) other.=A0 Your advice is=
 appreciated.




First failed project specifics (second one similar):




The Goal:=A0 Test the
response rate of Apache on each of two Sun servers (V440 - 16GB, 2 CPUs &=

V240 - 8GB, 2 CPUs).




The Script:=A0 Could
not be simpler -- a single page with nothing more than the customer's
logo.=A0 Here it is:






PRIMARY GET URI
"http://syn1.sellpoint.net/QA/smloadtest.html HTTP/1.0" ON 1=A0=A0 HEADER=

DEFAULT_HEADERS ,WITH {"{the usual stuff here"}




4 innocuous GET URIs follow.




The Test:=A0 Two load
servers (dual 1Ghz P4s, 1 GB memory).=A0 On
each, test had 20 Task Groups with this one script, in v-user "burst"
groups of 50, 100, 150,...1000, doing a single iteration.=A0 Each group t=
o be launch 3 minutes apart
(allowing the web server to settle from the previous burst).=A0=A0 Ramp r=
ate of 300 users per minute (batch
settings:=A0 1/5/1 (interval btw
batches/vusers per batch/batch ramp time).




The result:=A0 (1)
Test appeared to start up and run smoothly, until Group 8 (400-user burst=
)
launched--at which point Error Log reports "Failed processing for TOF
record for script line 59" (the PRIMARY GET); and what's worse, the Timer=

shows times at 50 users of about 2 seconds, rapidly climbing to 3.5 secon=
ds at
100, to 10 seconds at 200, 20 seconds at 200, 30 seconds at 350...and so f=
orth
all the way to 60 seconds.




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 LR=

showed these times to range from .7 seconds at just under 150 users, 5 se=
conds
at 1000 users, and up to 9 seconds at 2000 users.




Furthermore, perfmon showed that out dual-cpu server
shoots up to 100% utilization when Task Group8 (400 users) starts--and st=
ays
there; and memory pages/sec. shoots up from an average of 8 to around 50,=
 which
spikes to 400 (I have a screen shot that shows this if want to see it).




Questions:=A0 (1) Why
is the memory paging rate so strongly affected? (2) What other perfmon co=
unters
should I monitor to further diagnose the issue (I look at many including
System/threads & processor queue length, Memory/MB available, Physical
Disk/& Disk Time & Avg Queue length, Network Interface/Total
Bytes/sec,... and could not find any other counters "out of kilter");
(3) Is there a known limitation of opensta's overhead in allocating and
assigning threads that puts an upper limit to the ramp rate it can handle=
?




Thoughts:=A0 I
thought of implementing a Rendezvous (as per FAQ) to initialize all v-use=
rs
before launching them to the main app url -- thinking that this may overc=
ome
the 'startup overhead' that may be infecting the response results -- but h=
ave
not tried this yet.




Any insights to this apparent limitation, suggestions
about what else to do to further diagnose, or requests for more detail, g=
reatly
appreciated.




I believe understanding of and/or resolution of this
apparent 'load-driving bottleneck' to be of pivotal interest to all serio=
us
opensta users.=20




=20


=2E..Dan
=20

Dan Downing
=20

www.mentora.com
=20

Re: [OpenSTA-users] Names and naming in the OpenSTA community

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

| 
Dan Sutcliffe wrote:
| As tha author of most of the OpenSTA resource, the owner of the
| domains, and the original proposer of the name OpenSTA - I must
| respectfully tell you this is simply not the case or intention.
| 
| OpenSTA is the name of an architecture - Open System Testing
| Architecture -  the intention was always (and still is to me) that
| it is really a structure and set of protocols that a whole bunch
| of tools and services fit into....
| 
| | 
| Maybe, Mr Drowning, you just have a problem with names, as my last
| name isn't Sutcliff and Danny's last name isn't Fraught ;) :P
| 
| No worries, they're only names, cheers

Dan,
I stand corrected -- and re-educated  (yes, I *can* learn!) on at least 3
fronts...my apologies, and appreciation for being set on the right path.

And, truth be told, my fast typing (is there any other kind?) is lousy,
hence my occasional butchering of *people's* names.

But if my viewpoint cries for an interpretation:  As a non-participant in
the original product or its current maintenance, but an AVID user and
proponent of the technology, and with no human verbal example, I "learned"
to say Open-Ess-Tee-Ay.

Has a nice ring to it, I still think.

...Dan Downing
www.mentora.com

[OpenSTA-users] Names and naming in the OpenSTA community

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

Dan Downing wrote:
> Dan, OpenSTA *is* the tool name, at least according to the logo and
> headings on the opensta.org home page,

As tha author of most of the OpenSTA resource, the owner of the
domains, and the original proposer of the name OpenSTA - I must
respectfully tell you this is simply not the case or intention.

OpenSTA is the name of an architecture - Open System Testing
Architecture -  the intention was always (and still is to me) that
it is really a structure and set of protocols that a whole bunch
of tools and services fit into.

The current OpenSTA installation and toolset for Win32 platforms
is all that is currently available for OpenSTA, but I really hope
that this won't always be the case, and this installation does not
contain any single tool that is or can be called OpenSTA.  The 
closest thing to anything that could be called OpenSTA is perhaps
the whole CORBA NameServer mess ...

> and SAT is my pet abbreviation :).

I'm sure you meant STA ;)  The only reason I make a big deal about
any of this naming is the fact that so often I hear statements like:
 "... OpenSTA crashed ..."
which make little sense to me and do not help anyone diagnose an
issue.  At least if we use the actual util names (Commander, Modeler,
Gateway, Executer, etc.) then we are a step closer to being able help
whoever has the problem.

If you need a pet abbreviation, actually acronym, then the official
word (from the FAQ) is that it is OSTA and it should be pronounced
with a hard O sound like in 'cost' and the rest said as 'star', but
how a New Englander would say it, so maybe more like 'stah'.  There
was never any intention it be pronounced as an abbreviation - as in
Open Ess Tee Ay - it was always meant to be an acronym.

Maybe, Mr Drowning, you just have a problem with names, as my last
name isn't Sutcliff and Danny's last name isn't Fraught ;) :P

No worries, they're only names, cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/

Re: [OpenSTA-users] Because of High CPU usage users failed

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

| Parag Jadhav wrote:
| > I am using a server having following specifications:
| >
| > Processor: Intel Pentium 4, 3 GHz
| > RAM : 1GB
| >
| > I have analyzed performance of a Server using Perfmon while executing
| > a script for multiple users (say 10, 50 users)
| > and I found that  % Processor Time is above 90 %.
| > And I get following errors:
| >
| > E* HTTPRESPONSE (HTML parser): unresolved variable for connection (4),
| > E* TScript::run: ERROR in TOF execution; resuming...,
| >
| > for the line
| > LOAD RESPONSE_INFO BODY ON 4 &
| >  INTO CaseInfoVS1 &
| >  ,WITH  "HTML(0)/BODY(1)/FORM(0)/INPUT(3):ATTRIBUTE:value(2)"
| >
| > Can we say that because of high CPU usage this error is occurred?
| > Or is there anything I should look for?

Dan Sutcliffe wrote:
| Have you checked the FAQ?
| There's an entry for this very error:
|   http://portal.opensta.org/faq.php?topic=HtmlParserErrors
| 
| Also, you don't really make it clear wether it is your Web server or
| your load generating server which has high CPU usage - this fact is,
| of course, very important.
| 
In addition to what Dan states/asks, I would add:
1 - Do you get this error on *every* iteration, on single-user or 5 user
test, or only when you get to 50 and see 90% cpu utilization (on either the
target web server of your opensta Commander/load injector)?

2 - If it runs w/o error at "low load" and errors only at "high load" (as I
often see), I conclude that it is a load-related error -- either due to
overwhelming a resource on my load injector or on the web server.  If the
overall level of errors are smallish in number (<1-2% of overall successful
transactions), then I dismiss as "noise" due to imperfections of load
testing tools/environment.  If >2%, and resources on my load injector look
ok, then I conclude that the target server is not able to keep up, and is
not sending back complete html body from which to capture the values I
need--thus identifying a scalability problem on the target environment, to
be diagnosed and fixed.

Any other insights/opinions, gurus?

...Dan Downing
www.mentora.com

Re: [OpenSTA-users] For large size script, scl.exe gives errors

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

| Parag Jadhav wrote:
| > > > Is anybody has idea why its giving error?
| > > > Is it because of huge script size?
| 
| Danny Faught wrote:
| > > I used to see crashes on a certain large file every time I tried
| > > to do a search and replace.  I resorted to using an external
| > > editor for a while.  After the structure of the file changed a
| > > bit over time, I tried the builtin editor again and it was
| > > working fine.
| > >
| > > I tried to isolate the problem and found that both the file size
| > > and the format of the content was relevant to the crash, but I
| > > wasn't able to learn anything more.
| > >
| > > I recommend that you try to isolate the crash by finding the
| > > smallest subset of your script that reproduces the problem.
| 
| Dan Downing wrote:
| > I concur with what Danny reports.  We also have seen STA crash on
| > large scripts, of even 6,000+ lines.  Unexplained as to why.
| 

Dan Sutcliff wrote:
| Apart from the fact that there is no such tool as STA ... there's not
| even any tool called OpenSTA ;)
|   http://portal.opensta.org/faq.php?topic=OstaName
| We are all in agreement that script size AND content can have a
| bearing on various different possible problems with OpenSTAs tools.
| 
| Narrowing the bug occurence to the smallest/simplest specific example
| that exhibits the problem is the only way these types of problems
| stand ANY chance of being fixed.  The current organization of the
| OpenSTA project means that no-one is going to do this work for you,
| unless you pay them to, so if a bug is causing you a real problem
| then it is really only you that can help yourself get it fixed.
| You'll find if you can narrow a bug down to be very easily reproduced
| and well documented then you stand a much better chance of getting a
| fix.
| 
| Danny's problem with the editor has a bug report #1609533
| 
|
http://sourceforge.net/tracker/index.php?func=detail&aid=1609533&group_id=10
85
| 7&atid=110857
| But because it involves the Modeler's problem 3rd party editor
| (Codemax, which is no longer available or supported) it will only be
| fixed (maybe) when the editor is replaced.
| 
| Parag's problem with the compiler (scl.exe) may be in 2 broad areas:
| - bad SCL code generated by the Gateway which doesn't give a good
|   SCL compiler error.
| - SCL compiler just getting upset by valid code constructs or amount.
| The problem needs narrowing down much more before a bug should even
| be logged.

Dan, OpenSTA *is* the tool name, at least according to the logo and headings
on the opensta.org home page, and SAT is my pet abbreviation :).

Thanks for the editor insight here--was not aware of that.  I gotta spend
some time on the Developer site...

Btw, I *do* want to make a good contribution for bug-fixing and enhancements
-- and I suspect others might want to also...have you ever considered a
group mailing soliciting funding for such?

...Dan Downing
www.mentora.com

Re: [OpenSTA-users] For large size script, scl.exe gives errors

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

Parag Jadhav wrote:
> > > Is anybody has idea why its giving error?
> > > Is it because of huge script size?

Danny Faught wrote:
> > I used to see crashes on a certain large file every time I tried
> > to do a search and replace.  I resorted to using an external
> > editor for a while.  After the structure of the file changed a
> > bit over time, I tried the builtin editor again and it was
> > working fine.
> > 
> > I tried to isolate the problem and found that both the file size
> > and the format of the content was relevant to the crash, but I
> > wasn't able to learn anything more.
> > 
> > I recommend that you try to isolate the crash by finding the
> > smallest subset of your script that reproduces the problem.

Dan Downing wrote:
> I concur with what Danny reports.  We also have seen STA crash on
> large scripts, of even 6,000+ lines.  Unexplained as to why.

Apart from the fact that there is no such tool as STA ... there's not
even any tool called OpenSTA ;)
  http://portal.opensta.org/faq.php?topic=OstaName
We are all in agreement that script size AND content can have a
bearing on various different possible problems with OpenSTAs tools.

Narrowing the bug occurence to the smallest/simplest specific example
that exhibits the problem is the only way these types of problems 
stand ANY chance of being fixed.  The current organization of the
OpenSTA project means that no-one is going to do this work for you,
unless you pay them to, so if a bug is causing you a real problem
then it is really only you that can help yourself get it fixed.
You'll find if you can narrow a bug down to be very easily reproduced
and well documented then you stand a much better chance of getting a
fix.

Danny's problem with the editor has a bug report #1609533
  http://sourceforge.net/tracker/index.php?func=detail&aid=1609533&group_id=10857&atid=110857
But because it involves the Modeler's problem 3rd party editor
(Codemax, which is no longer available or supported) it will only be
fixed (maybe) when the editor is replaced.

Parag's problem with the compiler (scl.exe) may be in 2 broad areas:
- bad SCL code generated by the Gateway which doesn't give a good
  SCL compiler error.
- SCL compiler just getting upset by valid code constructs or amount.
The problem needs narrowing down much more before a bug should even
be logged.

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

Re: [OpenSTA-users] Because of High CPU usage users failed

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

Parag Jadhav wrote:
> I am using a server having following specifications:
>
> Processor: Intel Pentium 4, 3 GHz
> RAM : 1GB
> 
> I have analyzed performance of a Server using Perfmon while executing
> a script for multiple users (say 10, 50 users)
> and I found that  % Processor Time is above 90 %.
> And I get following errors:
>
> E* HTTPRESPONSE (HTML parser): unresolved variable for connection (4),
> E* TScript::run: ERROR in TOF execution; resuming...,
> 
> for the line
> LOAD RESPONSE_INFO BODY ON 4 &
>  INTO CaseInfoVS1 &
>  ,WITH  "HTML(0)/BODY(1)/FORM(0)/INPUT(3):ATTRIBUTE:value(2)"
> 
> Can we say that because of high CPU usage this error is occurred?
> Or is there anything I should look for?

Have you checked the FAQ?
There's an entry for this very error:
  http://portal.opensta.org/faq.php?topic=HtmlParserErrors

Also, you don't really make it clear wether it is your Web server or
your load generating server which has high CPU usage - this fact is,
of course, very important.

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

Re: [OpenSTA-users] Because of High CPU usage users failed

[vaibhav a. <va...@gm...>]

Hi parag,

This error mostly comes when openSta doesnt find the attribute to be
extracted in the response. i dont think this is happening because of
high CPU usage.

Thanks,
Vaibhav Agarwal
va...@cr...

On 7/5/07, parag jadhav <par...@gm...> wrote:
> Hi,
>
> I am using a server having following specifications:
>
> Processor: Intel Pentium 4, 3 GHz
> RAM : 1GB
>
> I have analyzed performance of a Server using Perfmon while executing
> a script for multiple users (say 10, 50 users)
> and I found that  % Processor Time is above 90 %.
> And I get following errors:
>
> E* HTTPRESPONSE (HTML parser): unresolved variable for connection (4),
> E* TScript::run: ERROR in TOF execution; resuming...,
>
> for the line
> LOAD RESPONSE_INFO BODY ON 4 &
>  INTO CaseInfoVS1 &
>  ,WITH  "HTML(0)/BODY(1)/FORM(0)/INPUT(3):ATTRIBUTE:value(2)"
>
> Can we say that because of high CPU usage this error is occurred?
> Or is there anything I should look for?
> Please let me know if anyone having idea?
>
> Thanks & Regards,
> Parag Jadhav
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> --
> OpenSTA-users mailing list Ope...@li...
> Subscribe/Unsubscribe/Options: http://lists.sf.net/lists/listinfo/opensta-users
> Posting Guidelines: http://portal.opensta.org/faq.php?topic=UserMailingList
>

[OpenSTA-users] Because of High CPU usage users failed

[parag j. <par...@gm...>]

Hi,

I am using a server having following specifications:

Processor: Intel Pentium 4, 3 GHz
RAM : 1GB

I have analyzed performance of a Server using Perfmon while executing
a script for multiple users (say 10, 50 users)
and I found that  % Processor Time is above 90 %.
And I get following errors:

E* HTTPRESPONSE (HTML parser): unresolved variable for connection (4),
E* TScript::run: ERROR in TOF execution; resuming...,

for the line
LOAD RESPONSE_INFO BODY ON 4 &
 INTO CaseInfoVS1 &
 ,WITH  "HTML(0)/BODY(1)/FORM(0)/INPUT(3):ATTRIBUTE:value(2)"

Can we say that because of high CPU usage this error is occurred?
Or is there anything I should look for?
Please let me know if anyone having idea?

Thanks & Regards,
Parag Jadhav

Re: [OpenSTA-users] Viewstate size is greater than 64Kb

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

Bernie  Velivis wrote:
| 
| > | Would you please tell me how can we correlate such a huge Viewstate in
| > | OpenSTA?
| > |
| 
| <Dan Downing wrote:>
| > Parag,
| > I've run into that before--and it has been a show stopper that I've not
| > been able to get around.
| >  If any of the other gurus have, would like to know too!
| 
| 
| Dan,
| 
| Daniel Sutcliffe dropped a hint today on the developers list that
| variables larger then 64K may soon be possible. I've kicked the tires on
| this functionality and it seems to work as advertised with no impact to
| stability.
| 
| I suspect that some other features I've contracted with Daniel to
| implement will also be released at that time. With these changes
| viewstates will be somewhat easier and more efficient to work with. I have
| no idea on what timeframe, if any, these features will be generally
| available so don't take this as a commitment, just an FYI that in
| principle the issue has been addressed and its probably a matter of time
| and/or money before its generally available.
| 
| 
Hey Bernie,
Good to hear from you and thanks for this tidbit--good news!

...Dan Downing
www.mentora.com