script runs for a few iterations, then it fails

[Bhagya Shri]

I have recorded a simple script in web http/html mode.

Login in init block, some navigations in action block and logout in end block.

When i run the script for around 15 iterations it works.. then it fails..

There are no correlation nor any parameters required as it is a simple login navigate and logout.

But everything in action block works any number of times.

 

please let me know for a solution any

 

 

message when it fails

 

 

 

Start auto log messages stack.

vuser_end.c(24): \n

vuser_end.c(24): </body>\r\n

vuser_end.c(24): <script type="text/javascript">\r\n

vuser_end.c(24): \r\n

vuser_end.c(24): </script> \r\n

vuser_end.c(24): </html>\r\n

vuser_end.c(24): \r\n

vuser_end.c(24): t=136558ms: 5-byte chunked response overhead for "

http://10.1.2.10/AGX/inbound_listing.jsf" (RelFrameId=1, Internal ID=100)

vuser_end.c(24): 0\r\n

vuser_end.c(24): \r\n

vuser_end.c(24): t=136672ms: Request done "

http://10.1.2.10/AGX/inbound_listing.jsf" [MsgId: MMSG-26000]

vuser_end.c(24): Error -26366: "Text=

agXchange - 6 :: Login ::

" not found for web_reg_find [MsgId: MERR-26366]

End auto log messages stack.

 

--
Cheers!!
Bhagya

[Krishnakanth PPS]

Probably your test data isnt sufficient.

Check the if your 15th iteration is working manually or not.

I find that is an issue with your parameters.

--
You received this message because you are subscribed to the Google "LoadRunner" group.
To post to this group, send email to LR-Loa...@googlegroups.com
To unsubscribe from this group, send email to
LR-LoadRunne...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/LR-LoadRunner?hl=en

[Floris Kraak]

On Mon, Mar 15, 2010 at 7:50 PM, Krishnakanth PPS
<krishnak...@gmail.com> wrote:
> Probably your test data isnt sufficient.
> Check the if your 15th iteration is working manually or not.
> I find that is an issue with your parameters.
>

I find that hard to believe as the original poster explicitly said
there were no parameters ;-)

The test failing here is a test for the presence of a login field. It
fails inside your vuser_end() section as pointed out by the line
numbers, which is where the original poster said his logout logic
resided. Therefore, either the logout logic inside the script does not
actually work, or the logout button doesn't.
My personal bet is that the logout logic of the application clears a
cookie in order to drop the session, and the script logic never does
that so the user remains logged in.

(Note to the original author. NEVER EVER put your login and logout
logic in vuser_init() or vuser_end(). The HP training materials that
claim that that is a good idea need to be burned and forgotten. Put
them inside properly named "Login and "Logout" actions where you have
some freedom to decide when and where to run them.
Putting any type of logic that is not INITIALIZATION or CLEANUP logic
in vuser_init() or vuser_end() is crazy talk. Seriously.)

Regards,
Floris
---
'What does it mean to say that one is 48% slower? That's like saying
that a squirrel is 48% juicier than an orange - maybe it's true, but
anybody who puts the two in a blender to compare them is kind of
sick.'
--- Linus Torvalds

[manish agarwal]

Hi Bhagya Shri,

 

There might be problem of session experied time out value. Please check your application code with developer and ask them the session experied timeout value.

 

The possibility is that, I am not sure but may be one iteration is taking around 60 secs and than for 15 iteartion it is taking 900 secs. Development team may set this value to 1000 secs thats why when you try to run more than 15 itearrtion, script is not working.

 

If development team says that value is already set enough, than there might be some issue with session only. Because your sript is working fine till 15 iteartion, there should not be any issue with your script.

 

Thanks,

Manish

 

--

[Mohan]

I agree with Floris. It looks as though the logout txn is failing.
Try simple options first, like Cleanup cache and cookies before the
login txn; parametrizing the login IDs and running with different
IDs.

[pramod phophalia]

Hi,

 

Could you try to uncheck the check box "Simulate a new user on each iteration" and "clear cache on each iteration" under Browser Emulation in Run time Settings and run for more than 15 iteration once.See if you can rid of the error.

 

Thanks

Pramod

[Rupesh Garg]

Team:

We are setting up the SiteScope for monitoring the following architecture:

Web server : Linux based IBM HTTP server

Application server: Linux based IBM Web Sphere Server 6.1

Database server: SQL Server 2005 - Windows

Please let me know that what are the configuration changes needed at each server to enable SiteScope monitoring

 

[pablomar]

no need of changes, but you have to set up sitescope with users/passowords to access those machines

and of course choose the counters and all the stuff

--

[James Pulley]

Sitescope is agentless.  Consult the documentation

--

[vjp...@gmail.com]

Floris,

have to disagree with the below.

The decision to put login and logout in  init and end should be driven by the business requirement.

How do you test an application where a user logs in at the begining of the day, stays logged in for the whole day , doing various stuff while inside and logs out only at the end?

A typical example is a  Ticket resolver in peregrine - they login at the begining of the day, and log out only during a break.

There are specific requests by clients not to simulate login and logout during the steady state period, modelled on the real user behaviour.  the above approach is the most easiest way to simulate such kind of usage.

-Venkat

[Floris Kraak]

On Wed, Mar 17, 2010 at 2:49 AM, vjp...@gmail.com <vjp...@gmail.com> wrote:
>
> have to disagree with the below.
>
> The decision to put login and logout in  init and end should be driven by
> the business requirement.

There is no reason to not implement that as separate, apropriately
named, actions in your script.
You can still put those in the init or end sections of your run logic
if there really is such a requirement.

And even then there are good reasons to implement such a thing
slightly differently than blindly putting it in the init and end
sections of the run logic and praying that the user wil *never ever*
hit an error condition of any kind.

> How do you test an application where a user logs in at the begining of the
> day, stays logged in for the whole day , doing various stuff while inside
> and logs out only at the end?
>
> A typical example is a Ticket resolver in peregrine - they login at the
> begining of the day, and log out only during a break.
>

You put his activities in an action block, have that action block
executed a large number (say 100, or even 1000 for my part) times, and
put login and logout before and after it. This way, if the user
encounters an unresolvable error condition, the user will simply log
out, log back in, and start over from a 'known good' starting point.

> There are specific requests by clients not to simulate login and logout
> during the steady state period, modelled on the real user behaviour.  the
> above approach is the most easiest way to simulate such kind of usage.
>

So, what happens if you do this? You start your test, everything looks
fine. Rampup looks fine. Then you hit steady state. It looks fine, so
you go home to let his test run overnight.
But then, suddenly, one of the users gets an error - something simple,
like a connection timeout because a scheduled batch job is running
concurrently with the vuser load. What happens?
Loadrunner restarts the iteration. Because the iteration gets
restarted, the user attempts to access a page that is not available at
the time - loadrunner has an empty page as a result, and at the start
of the iteration the user tries to click on a link ('home') that does
not exist in the current context.
. Result? Another error. And another. And another. And so forth, ad
infinitum. The virtual user has ended up in an unresolvable error
state. This is not just a possibility - I've seen it happen. I've seen
tests that ended up with *all* users in unresolvable error conditions
because the script had no graceful way to deal with this situation.

Compare that to the way I handle this: The start of the iteration is
'login' or maybe even the application's start page. The virtual user
always starts off from scratch and never has to depend on the state of
the application under test. As long as it runs inside the action block
it will do exactly what is asked from it by the existing business
requirements, but it has a failsafe in case something goes wrong.

Sure, every so much time the users will log out and log in again - but
given proper settings, that can be a very, very long time.

So, to recap:
- Putting user level test logic in vuser_init and vuser_end is bad.
The purpose of vuser_init() and vuser_end() is initialisation and
cleanup, respectively. What you put in there is things like
web_add_auto_filter() and web_global_verification(), or initialisation
of parameters. The HP training materials are teaching people to abuse
them for something they were never intended for.
- The proper thing to do is to put user level test logic into
-actions-, that have good descriptive names. "Login". "LandingPage".
"BookTicket". Then you use the run logic section of your runtime
settings to model the user behaviour.
- Putting login and logout into the init and end sections of your run
logic settings means your virtual user cannot recover from a number of
error conditions. To remedy that you should Instead put in a block
that gets executed a large number of times, with a login at the start
of the iteration and a logout at the end.

Does this clarify things?

[vjp...@gmail.com]

"You put his activities in an action block, have that action block
executed a large number (say 100, or even 1000 for my part) times, and
put login and logout before and after it. This way, if the user
encounters an unresolvable error condition, the user will simply log
out, log back in, and start over from a 'known good' starting point."

You have valid points and what you state is a valid approach as well and to be fair, I have seen that / done that as well . But for obvious reasons, our load tests  99.5% - nay almost 100% of these "login at start, run, logout at end" have been of less than two hours duration.   All these tests are run with us eyeballing the controller - never away from it.  So to do "your" approach, I actually had to do a smoke test and calculate the typical iteration duration -  because our scripts are a random distribution of actions. coming up with a random number say 100 may make the script end early or make the script run very long.

Its a good approach if I want to do a shorter duration user session - say half hour or so, but getting it to last exactly two hours or one hour will be a challenge.

Be that as it may , the problem with the above approach - IMO is that if the iterations have been running slow, and sometimes very slow, the logouts wont happen at the end of the steady state.. the script will insist on doing all its 100 or 200 or whtever iterations you ahve set. and you can expect to wait a long time for them to ramp down, or you have to do a hard stop.

You will also note that I said "the approach is the most easiest way to simulate such kind of usage.". The choice of word was a deliberate one on my part. It may be not the best way, but its the easiest way to do it and get your numbers.  After all, dont make life too complicated by overdesigning something if it can be done in a simpler fashion.  Plus we have eyeball Mk1 to take care of connection failures etc because SLA failures like that will anyway invalidate my two hour test.

>Because the iteration gets restarted, the user attempts to access a page that is not available at
> the time - loadrunner has an empty page as a result, and at the start
> of the iteration the user tries to click on a link ('home') that does
> not exist in the current context.

.have login as a function in init, and then call it when your text check / user session check at the beginning of the iteration fails. Ofcourse you can come back by saying have the same thing in Login Action, but as I said, I would like to keep my life simple, not overdesign it.

>>So, to recap: - Putting user level test logic in vuser_init and vuser_end is bad.

Not if one knows how to use it properly and understands what can be done with it.

-Venkat

[Floris Kraak]

On Wed, Mar 17, 2010 at 12:47 PM, vjp...@gmail.com <vjp...@gmail.com> wrote:
>
>  So to do "your"
> approach, I actually had to do a smoke test and calculate the typical
> iteration duration -  because our scripts are a random distribution of
> actions. coming up with a random number say 100 may make the script end
> early or make the script run very long.
>
> Its a good approach if I want to do a shorter duration user session - say
> half hour or so, but getting it to last exactly two hours or one hour will
> be a challenge.

True enough. If your requirement is that the script absolutely cannot
log in/log out at periodic intervals.
Usually having a login/logout cycle every 30-40 iterations is good
enough to cover the needs of the AUT, though.

I don't claim that there never is a good reason to do login/logout
from init and/or end. I just claim that doing it in vuser_init() and
vuser_end() (the functions) is bad form.

> Be that as it may , the problem with the above approach - IMO is that if the
> iterations have been running slow, and sometimes very slow, the logouts wont
> happen at the end of the steady state.. the script will insist on doing all
> its 100 or 200 or whtever iterations you ahve set. and you can expect to
> wait a long time for them to ramp down, or you have to do a hard stop.

Yes, that is the main drawback. Gradual stop will be painful. With
your 2-hour test cycle timing it will be an interesting challenge.
For longer tests where you start a test in the evening and go home to
leave it running that drawback is a often non-issue though. If your
test specifications require it to run at least 8 hours and you have
12+ hours until you get back then rampdown taking 2 hours is not that
big a problem.

It'd be better if there was some way for a script to check if the user
is in the "Gradual Stop" state, by the way. Then you could just call
lr_abort() or lr_exit_vuser() with appropriate parameters at the start
of the iteration if the user was actually busy stopping.

> You will also note that I said "the approach is the most easiest way to
> simulate such kind of usage.". The choice of word was a deliberate one on my
> part. It may be not the best way, but its the easiest way to do it and get
> your numbers.

Easiest? Maybe. I've seen enough tests fail because users end up in
unrecoverable error situations for me to vastly prefer doing something
else that is maybe not as easy, but also guaranteed to keep on working
in the face of an intermittent error or two.

> After all, dont make life too complicated by overdesigning
> something if it can be done in a simpler fashion.

It's not overdesigning anything. All I am arguing for is that people
make sure the naming of their action blocks matches reality. Is that
so complicated?

> Plus we have eyeball Mk1 to take care of connection failures etc because SLA failures like that will
> anyway invalidate my two hour test.

It was an example of the type of thing that could go wrong. There are
a million other ways that a script
might temporarily fail, as I am sure you are aware.

>>Because the iteration gets restarted, the user attempts to access a page
>> that is not available at
>> the time - loadrunner has an empty page as a result, and at the start
>> of the iteration the user tries to click on a link ('home') that does
>> not exist in the current context.
>
> .have login as a function in init, and then call it when your text check /
> user session check at the beginning of the iteration fails. Ofcourse you can
> come back by saying have the same thing in Login Action, but as I said, I
> would like to keep my life simple, not overdesign it.

That's another valid approach to the problem.
However, there is literally no difference between putting login as a
function in vuser_init (the action block) and making a Login action.
Each action is actually a function that gets called by loadrunner's
run logic engine. You can call them from within the script yourself.
Your login() function would be identical to the Login() function that
you get when you put the same code in an action block named "Login".
I vastly prefer the action variant simply because it is the path of
least surprise to the person who comes after me. A Login action does
exactly what it advertises, whereas a vuser_init section with a
login() function might be missed at first.

>>>So, to recap: - Putting user level test logic in vuser_init and vuser_end
>>> is bad.
>
> Not if one knows how to use it properly and understands what can be done
> with it.

Sorry, we'll just have to agree to disagree there. Sure, if you start
making functions inside vuser_init then you can do a lot of very
flexible things. In fact, I regularly do so. But I never put user
level actions (=transactions) in there. If you can put it in a
transaction then there is no reason for it not to be a separate action
to begin with.

[vjp...@gmail.com]

Well you have made your points, and I have made mine.  In the end, each of us will work with the style we are comfortable with and the style that we believe is the fastest or easiest - As long as we get valid results and are aware of the things that can go wrong in each approach - we are good.

-Venkat
 

[John Crunk]

Was just looking at this thread. How do you do a duration test in 30 min?

John Crunk Ph.D ABD

Sent from my iPhone

[vjp...@gmail.com]

Whats the context?

[Bhagya Shri]

hi all,

 

tried clearing cache, cookies, adding headers, but still the same issue

 

 

yes..it is a business requirement to login once and work on...also during load test login uses most resources..so one login is recommended...

 

Also, No parameters required. Manually it works fine

 

Please check the error message below…..when it fails

 

Start auto log messages stack.

vuser_end.c(24):     //--></script>\r\n

vuser_end.c(24):     \n

vuser_end.c(24):     </body>\r\n

vuser_end.c(24):      <script type="text/javascript">\r\n

vuser_end.c(24):      \r\n

vuser_end.c(24):     </script>         \r\n

vuser_end.c(24):      </html>\r\n

vuser_end.c(24):     \r\n

vuser_end.c(24): t=201102ms: Server 10.1.2.11 has shut down the connection              [MsgId: MMSG-26000]

vuser_end.c(24): t=201102ms: Closed connection to 10.1.2.11:80 after completing 0 requests             [MsgId: MMSG-26000]

vuser_end.c(24): t=201211ms: Request done "http://10.1.2.11/AGX/inbound_listing.jsf"            [MsgId: MMSG-26000]

vuser_end.c(24): Error -26366: "Text=

        agXchange - 6 :: Login ::

    " not found for web_reg_find, Snapshot Info [MSH 0 8]  [MsgId: MERR-26366]

End auto log messages stack.

--

You received this message because you are subscribed to the Google "LoadRunner" group.
To post to this group, send email to LR-Loa...@googlegroups.com
To unsubscribe from this group, send email to
LR-LoadRunne...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/LR-LoadRunner?hl=en

--
Cheers!!
Bhagya

[Rupesh Garg]

Ok..sure..only thing I was thinking that there might be some changes need to done on confiug files in Web Sphere to enable the configuration to gather the data

 

Rupesh Garg, PMP | Associate Technical Services Manager | AppLabs
Mobile: +91 9160002744 / rupes...@applabs.com|

[John Crunk]

Your problem is in your post. I suggest that you get training and mentoring fast

John Crunk Ph.D ABD

Sent from my iPhone

[Abhijeet Majgaonkar]

I think you have setup a text check in your script (" not found for

web_reg_find, Snapshot Info [MSH 0 8] [MsgId:

> MERR-26366]) which is failing and also before that, the session is timing out for some reason..

Could you check on that?

-Abhijit

On Mar 16, 10:08 pm, Bhagya Shri <bhagya....@gmail.com> wrote:
> hi all,
>
> tried clearing cache, cookies, adding headers, but still the same issue
>
> yes..it is a business requirement to login once and work on...also during
> load test login uses most resources..so one login is recommended...
>
> Also, No parameters required. Manually it works fine
>
> Please check the error message below…..when it fails
>
> Start auto log messages stack.
>
> vuser_end.c(24):     //--></script>\r\n
>
> vuser_end.c(24):     \n
>
> vuser_end.c(24):     </body>\r\n
>
> vuser_end.c(24):      <script type="text/javascript">\r\n
>
> vuser_end.c(24):      \r\n
>
> vuser_end.c(24):     </script>         \r\n
>
> vuser_end.c(24):      </html>\r\n
>
> vuser_end.c(24):     \r\n
>

> vuser_end.c(24): t=201102ms: *Server 10.1.2.11 has shut down the connection
>             [MsgId: MMSG-26000]*
>
> *vuser_end.c(24): t=201102ms: Closed connection to 10.1.2.11:80 after
> completing 0 requests             [MsgId: MMSG-26000]*
>
> *vuser_end.c(24): t=201211ms: Request done "http://10.1.2.11/AGX/inbound_listing.jsf*"            [MsgId: MMSG-26000]

>
> vuser_end.c(24): Error -26366: "Text=
>
>         agXchange - 6 :: Login ::
>
>     " not found for web_reg_find, Snapshot Info [MSH 0 8]  [MsgId:
> MERR-26366]
>
> End auto log messages stack.
>

> On Wed, Mar 17, 2010 at 7:19 AM, vjpj...@gmail.com <vjpj...@gmail.com>wrote:
>
>
>
> > Floris,
>
> > have to disagree with the below.
>
> > The decision to put login and logout in  init and end should be driven by
> > the business requirement.
>
> > How do you test an application where a user logs in at the begining of the
> > day, stays logged in for the whole day , doing various stuff while inside
> > and logs out only at the end?
>
> > A typical example is a  Ticket resolver in peregrine - they login at the
> > begining of the day, and log out only during a break.
>
> > There are specific requests by clients not to simulate login and logout
> > during the steady state period, modelled on the real user behaviour.  the
> > above approach is the most easiest way to simulate such kind of usage.
>
> > -Venkat
>

> > On Tue, Mar 16, 2010 at 4:21 AM, Floris Kraak <randa...@gmail.com> wrote:
>
> >> (Note to the original author. NEVER EVER put your login and logout
> >> logic in vuser_init() or vuser_end(). The HP training materials that
> >> claim that that is a good idea need to be burned and forgotten. Put
> >> them inside properly named "Login and "Logout" actions where you have
> >> some freedom to decide when and where to run them.
> >> Putting any type of logic that is not INITIALIZATION or CLEANUP logic
> >> in vuser_init() or vuser_end() is crazy talk. Seriously.)
>
> > --
> >  You received this message because you are subscribed to the Google
> > "LoadRunner" group.
> > To post to this group, send email to LR-Loa...@googlegroups.com
> > To unsubscribe from this group, send email to

> > LR-LoadRunne...@googlegroups.com<LR-LoadRunner%2Bunsu...@googlegroups.com>