Sockets and WinInet errors during replay

[Sergey Minaev]

Hi all,

 

I have script Web(HTTP/HTML) for a simple web-application via browser. It correctly works manually and allows to record it with HTTPS. But there is an error during replay on the first request:

 

t=3896ms: Connecting to host10.***.***.61:443  
t=3918ms: Connected socketfrom 127.0.0.1:26381 to10.***.***.61:443 in 19 ms   
BIO[01B93D70]:write(1132,69) - socket fd=1132 
BIO[01B93D70]:writereturn 69 
BIO[01B93D70]:read(1132,7) - socket fd=1132 
BIO[01B93D70]:readreturn 7 
Error -27778: SSL protocol error when attempting to connectwith host"my_server_name"   
BIO[01B93D70]:Free - socket 
t=3998ms: Closed connection to my_server_name:443 after completing0 requests

I tried to use web_set_sockets_option(), web_set_option(), web_set_max_retries(). No effect.
Google recomends me to set "WinInet instead of sockets". It works!
But I've got other error. It happens on 'heavy' requests that have response times more than 30s:

 

Error -27492: "HttpSendRequest" failed, Windows error code=12002 and retry limit(5) exceededfor URL="https://my_server_name/url"

I've googled for the error. It recomends to remove option "WinInet instead of sockets" ))))

So I don't know how to fix the first problem (with socket error) or increase timeout on HttpSendRequest action for WinInet.

 

Had anybody same problems?

Thanks a lot!

[prasenjit dutta]

r u doing wiInet replay.....if so the uncheck that option then run.....

u'll get it in RTS--> Preferences --> advanced section's first check box

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

--
Prasenjit

[Sergey Minaev]

Jack,

 

as I wrote there are 2 (two) different errors:

 

• on Socket mode (Error -27778: SSL protocol error...)
• on WinInet mode (Error -27492: "HttpSendRequest" failed)

 

So I need to solve the problem on any of these mode...

[Oliver Lloyd]

If you are only getting this error on 'heavy' requests that last more
than 30 seconds then it is not really an 'error', it is simply the
windows API returning a timeout code. I would question why the request
is taking so long. This could relate to your AUT or the machines you
are generating load from.

On Aug 5, 1:26 pm, Sergey Minaev <samscro...@gmail.com> wrote:
> Jack,
>
> as I wrote there are 2 (two) different errors:
>

>    - on Socket mode (Error -27778: SSL protocol error...)
>    - on WinInet mode (Error -27492: "HttpSendRequest" failed)

[Sergey Minaev]

Oliver,

I agree that it's not an error but timeout.

So I need to increase it in any config file. I could not find such settings. Does anybody know where is it?

PS: the 'heavy' request is a search in huge data base so 30s is a normal response time

[Oliver Lloyd]

30 seconds is terrible for a search request, no matter how big the
data, I seriously hope you don't have users who will be waiting for
this long!

But anyway, the key question is are you seeing this time degrade as
the load increases?

Also, it's typically a mistake to respond to timeout errors by trying
to increase the timeout period - bit of a newbie mistake that one (no
offence) - you might get more mileage looking at when and why this
error happens and addressing the root cause.

[Sergey Minaev]

Oliver,

 

What error do you mean? It's just a timeout on server response in WinInet mode.

I agree that 30s is not normal for a good application but the goal of our work is to make this application better :) And if you never meet response times >30s you are really happy tester)))

 

PS: the question about WinINet mode settings is actual...

[Abhishek Banginwar]

30 seconds is a huge response time i agree but i have came across applications where it cant be avoided...consider a server which hosts scanned copy of the signatures which uses is used in bank's withdrawal....for normal accounts there wasnt a problem but there were accounts which had like 100 signatures...where we had hit in response time.

--

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

--
Abhishek

[Vivek]

People tend to have high tolerance for actions like withdrawal and transfer in a banking website, they don't get bothered by high response times because they know something's up in the server and they're aware it takes more than usual for such huge requests. But there are times where response time becomes unacceptable for them such as a 30 second response time for a simple search request.

[Oliver Lloyd]

It seems to me that what you are trying to do here is solve the symptoms of the problem rather than address the root cause. Assuming you are only seeing degradation in response times under load then the worst thing you can do in this scenario is to increase the timeout - it's just pointless and won't get you anywhere.

You need to design a test that realistically represents the level of load that you need to prove you system can handle, then, once you've done this, you begin to think about running tests - not before. Then, if at this level of load you experience a slow down then you can start to investigate why this is happening and begin to make the application better.

[James Pulley]

Seems like this discussion is skirting the nasty scary ‘R’ word, “Requirements…”

[Vivek]

Most of what has been discussed here revolves around the subject concerning user tolerance for a website/application's response. Business requirement was never an user concern.

[Oliver Lloyd]

I'm not sure that's really a true statement...

But I suppose you could say that business requirements are never a concern to some people. That would be true.

[Vivek]

I beg to differ that business requirements are never a concern to some people but the users. That would mean the users actually care about what the business requirements are for the site/application they're using. Meeting the requirements for a slow website does not really stop the users from abandoning it.

On Tue, Aug 16, 2011 at 11:06 PM, Oliver Lloyd <oliver...@hotmail.com> wrote:

I'm not sure that's really a true statement...

But I suppose you could say that business requirements are never a concern to some people. That would be true.

[Oliver Lloyd]

Actually the thing that I disagreed with was that most of what had been discussed here related to 'user tolerance'. I reckon this was a thread about Socket errors and whether or not these errors are a real concern or not - how long people wait is a random tangent. Also, I suspect you misunderstood my reference to 'some people', that's just me bemoaning the fact that requirements are so often ignored.

[Vivek]

I do glance at this thread topic once again and I can make sure it says "Sockets and WinInet errors during replay". The reason why I've said most of what has been discussed here related to user tolerance is because as you can see in most of the posts in this thread, people (including you) tend to stress on terms related to user tolerance and their behaviour for responding to a time out request. So I had to mention it all depends upon the user choosing to stay or leave and the type of request being sent when the word "Requirements" was involved.

 

On Wed, Aug 17, 2011 at 4:28 PM, Oliver Lloyd <oliver...@hotmail.com> wrote:

Actually the thing that I disagreed with was that most of what had been discussed here related to 'user tolerance'. I reckon this was a thread about Socket errors and whether or not these errors are a real concern or not - how long people wait is a random tangent. Also, I suspect you misunderstood my reference to 'some people', that's just me bemoaning the fact that requirements are so often ignored.

[Sergey Minaev]

Colleagues!

 

Please don't change the subject of question!

 

1. There are no question about business requirements and other administrative problem but technical only
2. This error appeares during debug under load by 1 (one!) user because of heavy request (search, report, other system redirect, it doesn't matter)
3. So actual question: is there any configuration for WinInet mode for timeout increase? Default is 30s...

Thanks!

[Oliver Lloyd]

Do you get 30sec response times if you copy and paste the same requests into a browser and run it manually?

If yes, raise a defect and chuck it back to your developers. There are very few cases where this would be acceptable - and you should get into the habit of demanding better.

If no, then you'll have to find out why and fix the problem. There are virtually zero cases where increasing the timeout in response to slow response times is a good idea.

Note. Requirements are not administrative; they are very technical indeed. You should probably spend some time thinking about them. For example, what are the requirements regarding response times for search requests?

[Vivek]

Requirement came into play as a reminder for you to validate the obtained response time against the set threshold for search request, to keep you from getting into a debate of good and bad response times. It was never meant to be given as an answer. However I'm sure there will never be a requirement that says 30 second response time looks okay for a search request no matter how much you justify regarding how big the request and how rough the path is for that request.

So there, you have a performance related bug that persists either in the application or in the architecture. You're suggested to bring this bug in spotlight, to take appropriate tuning measures or anything that will help solve this problem eventually but definitely not increasing the time out value more than 30 seconds as suggested earlier in this thread. That is not something considered as a part of the tuning process.

--

[Sergey Minaev]

Hi guys,

in spite of all discussions I've found and fixed the root problem of socket error.

It was bad certificate. IE have workarround for this situation (adding exception) but LR returns error.

So if smb faces such challenge check the first server certificate.

 

Nevertheless WinInet problem was not solved...

[Harish Gangasani]

How did you solved this issue? I am also facing the same problem with a request which is taking long time.

 

How do you get the right certificate?

[Sagar Mamidwar]

Hi Sergey,
I am also facing same issue with socket replay. could you please suggest how did you fix the "bad certificate" error?

If i use wininet replay, response time for my application increases by a large extent. so I have to use socket replay only.