Link to home
Start Free TrialLog in
Avatar of Julian Hansen
Julian HansenFlag for South Africa

asked on

HTTPSendRequest with WinINet delays on first call

This came up at one of our clients - have not seen it anywhere else.

Setup
IIS server
C++ application makes a call to IIS server using HTTPSendRequest.

Problem
Request can take up to a minute to respond on first call only. Subsequent calls are in ms - and not all users have the same first call delay.

InternetOpen called with AccessType set to INTERNET_OPEN_TYPE_DIRECT to bypass Proxy - tried with INTERNET_OPEN_TYPE_PRECONFIG as well to see if there is a difference.

IIS Application Pool set to never sleep.

I have done a fair amount of googling and found others who have had this issue but not definitive solutions.

Hints at DNS and Proxy being the cause - which we have checked.

I am looking for ideas from the community as to what else we can potentially look at to try and determine why we get this delay on first call for some users.
ASKER CERTIFIED SOLUTION
Avatar of Dan McFadden
Dan McFadden
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Julian Hansen

ASKER

Fantastic answer Dan, thank you. We are going to try this. I think this has already been done but as I am not on site I am going to send them these instructions and see what happens.

Thanks again for the detailed answer - I appreciate it.
Thanks again Dan - we have implemented the above but still get a delay on first request - up to 90 seconds - second request is milliseconds later and takes < 100ms to complete.

Anything else you can suggest that might be causing the delay?
Was the <applicationInitialization> element in the application's web.config added and configured after Application intialization setting was turned on?

Reference link:  https://www.iis.net/configreference/system.webserver/applicationinitialization?showTreeNavigation=true

Sorry for the question...  I ask only because often the App Init feature is installed, enabled but not set at the application level, so the App Init function doesn't know what to preload after a recycle event on the AppPool/work process.

Dan
I will have to check - playing monkey in the middle here as server is remote and I don't have access but circumstances have dictated that I be involved in solving this issue.

Thanks again for the response.
Has there been any feedback from your client about their situation?

Dan
Yes - they are still experiencing the problem. We have developed a diagnostic app that just does the HTTP request to the server with some tracing in to see if it yields any information but so far they are still getting delays of up to 40 seconds  - which is down on what it was but still way above the 70ms average we are seeing on the second request.
I have another suggestion to investigate.  I came across it while reading thru HTTP Acceleration tech.

Wound up reading this article:  https://www.iispeed.com/blog/windows-server-2012-and-tcp-slow-start, which lead me to this one:  https://technet.microsoft.com/en-us/library/hh826132(v=wps.620).aspx.

Maybe another avenue to investigate.  Goes into the optimization of the TCP stack.

Dan
Thanks Dan,

Appreciate it - will pass it on.
Just wondering:

I've had a similar problem - extremely slow HTTP answering time - a couple of months ago, which popped up whithout any change the system. Interestingly only HTTP requests were slowed ... RDP sessions and even local HTTP requests went thru as blindingly fast as expected.

The qintessence of a long and hard search: The IT guys had moved the DNS servers to other IP's, and forgot to update that in the server's (static) IP settings. Therefore the server process waited for the DNS to time out some seconds on each and every response ...

If the final address resolution results get cached, the symtoms would look like yours: An initial, extremely slow response and  subsequent quick answering.
This problem is still not resolved but I don't believe it is because advice here was not valid. My feeling is the client has an unstable server running too many services. We have been unable to replicate this issue so this would appear to be specifically environmental.
For anyone wanting to know more about this problem here is some more information.

After several months of debugging it was found that the client was redirecting the Cookies folder for their users.

When the first WinINET call was made IE was triggered to read the cache and in so doing caused a delay for users with a large IE cache / cookies. Once this had been done however subsequent calls were quick as the cache / cookies had already been read.

Checking to see if the same happens with a WinHTTP call.