Stability Test scenario "HttpSendRequest" failed, Windows error code=12152 "

[thinkquest1]

Hi all,

I am running a stability test under very light load for a web
application and I get random "HttpSendRequest" errors. I am exhausted
by checking the server logs for any related exception, but there is
nothing that I can related to these errors thrown by Loadrunner. Only
handful of these errors pop up for a test running for several hours


Error message:
"HttpSendRequest" failed, Windows error code=12152 (invalid server
response) and retry limit (0) exceeded

Any suggestion will be appreciate.

ciao,

[chaitanya bhatt]

You'r server may be stressed out. Switch back to winsock mode. Wininet doesn't give you exact HTTP error code details.

 

Thanks

Chaitanya M Bhatt

http://www.performancecompetence.com

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

[Sunny rao]

The  script plays back only using WinInet replay level, since it uses Authentication at the beginning of each iteration. why do you think the server being stress out? The load I am applying is less than few users which the server should handle without much issues. One more thing I am seeing it is throwing this error at response.redirect URL.

--SR

[James Pulley]

A couple of users with no think time can bury a server by totally
collapsing the expected period between responses which is a part of
the client server model

On Apr 28, 9:25 pm, Sunny rao <lr.thinkqu...@gmail.com> wrote:
> The  script plays back only using WinInet replay level, since it uses
> Authentication at the beginning of each iteration. why do you think the
> server being stress out? The load I am applying is less than few users
> which the server should handle without much issues. One more thing I am
> seeing it is throwing this error at response.redirect URL.
>
> --SR
>

> On Sat, Apr 28, 2012 at 10:15 PM, chaitanya bhatt <bhatt.chaita...@gmail.com

>
>
>
>
>
>
>
> > wrote:
> > You'r server may be stressed out. Switch back to winsock mode. Wininet
> > doesn't give you exact HTTP error code details.
>
> > Thanks
> > Chaitanya M Bhatt
> >http://www.performancecompetence.com
>

[Sunny rao]

I am certainly not using any think time, however have given sufficient pacing between iterations. Lack of think-time at the redirect URL might possibly be the cause of this error. but my dilemma is also why there is no indication of error in the logs during the time-frame when these "HttpSendRequest" occurs in the test 

-SR

[James Pulley]

No think times = bad practice.   Your non use of think time goes against your original premise of a very light load. 

Your error is on http send, which sounds like is a client generated event.   If your local stack errors and a frame is never put on the wire then it would never hit the server and never generate a logged server event.

Tell us about the load generators you are using?  Are they virtualized?  Are other services running on them ? 

[arun punaroor]

Try increasing the " Httprequest connect timeout" and  "Httprequest connect timeout " to   >120..

by default it is set to 120..

might help..  :)

Arun

[James Pulley]

"Try increasing the " Httprequest connect timeout" and "Httprequest
connect
timeout " to >120..
by default it is set to 120.. "

And how would you propose doing this on every client which connects to
your site..... This is really poor process. You should be
identifying the cause of the issue rather than changing the standard
so the error does not occur.

Why not just turn all errors into warnings so you have no errors in
your test no matter what the site does?

[Sunny rao]

There is no recorded think-time for that Http request, The error screen shot that I capture also shows that the application is trying to load the redirect URL but is stopped in between. I can manually induce some thinktime, but I get three HttpSendRequest errors in 3 hours. By inducing thinktime manually at that step I might increasing the Transaction response time more than my SLA requirement.

-SR

[James Pulley]

So your error rate is 3 out of how many?   How does this match to your requirement error rate?

[Sunny rao]

The error rate is 3 out of 120 approximately 3% . But this is not acceptable to our Business Partners. In this case I have to narrow down on the root cause of this issue.

-SR

[James Pulley]

What precisely is the error rate requirement?

[James Pulley]

Well, you have two possibilities, app or test design.   If you have no validating message, error, logged event or even network trace which shows that this is “off host” from your load generator then you will wind up falling back to test design.

 

Assuming you have at least three load generators (and one of them is not the same host as the controller), which load generator host does this impact and how is this host distinct from the two (or more) which are not generating an error?

[Sunny rao]

The requirement is error rate less than 1%

--SR

[James Pulley]

As you only have three errors on unable to parse (an OS level message by the way, not a tool level message, the server response could not be parsed).   Can we assume that these are concentrated on one of ~n~ generators and not every generator?

 

OK, assuming it leaves the server correctly this is clearly a client side event.   So you have a network corruption issue possibility.   IF not that then you are coming down to a resource issue on the box where there is not enough interrupt service to grab all of the frames and this then results in fragments of the response.   This happened more back in the era of MHZ CPUs instead of GHZ CPUs, but it can happen if your host is oversubscribed.

 

Bluntly, are you using virtualization for your load generators?   If so, move to physical generators for a retest.  With virtualization you now have a hypervisor brokering your resources and acting as a pass through on all communications.  If the hypervisor burps because you are running on a saturated VM host then you may be dealing with a rather rancid network aftermath resulting in the errors you are seeing.

 

How many generators do you have involved?   If only one, then you have design issues that need to be reconciled.   Consider moving to a minimum number of three generators, all hardware matched with two for primary load and one for control load (single virtual user of each type).   If you do involve virtualization always keep a reference/control generator in physical hardware.

[Taranjot Singh]

Hi ,

Use web_set_option ( "Max Redirection Depth "., "5"); for that
request which is failing and Uncheck the WININET option in the run
time settings .


apply and share your findings.

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

>> >> For more options, visit this group at
>> >>http://groups.google.com/group/LR-LoadRunner?hl=en
>>
>> > --
>> > 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

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

>> > For more options, visit this group at
>> >http://groups.google.com/group/LR-LoadRunner?hl=en
>
> --
> 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

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

> For more options, visit this group at
> http://groups.google.com/group/LR-LoadRunner?hl=en
>
>
>
> --
> 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
>
> --
> 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

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

> For more options, visit this group at
> http://groups.google.com/group/LR-LoadRunner?hl=en
>
>
>
> --
> 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
>
> --
> 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

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

> For more options, visit this group at
> http://groups.google.com/group/LR-LoadRunner?hl=en
>
>
>
> --
> 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
>
> --
> 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

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

> For more options, visit this group at
> http://groups.google.com/group/LR-LoadRunner?hl=en
>
>
>
> --
> 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
>
> --
> 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


--

--
Taranjot Singh

https://sites.google.com/site/performancetestingstuff/Home

[Sundar Bairavarasu]

Thank you James and everyone, You are right the Load Generators are on VM's, and the call that was waiting for a resource file, these errors are a manifestation of one of the two reasons you have sited above, I am more inclined towards the resource issue might not be due to sizing or capacity but due to a bug in the application . Some Application fixes have gone in and it apparently has resolved this issue and for past 2 days my test has passed with no errors.

-SR