IIS logs, time taken, substatus and ASP.Net

[Mark]

Hi...

I've been doing some log analysis from one of our websites and I'm seeing
some peculiar things.

Specifically, I'm seeing that the time-taken column for some requests is
running into multiple minutes, sometimes as high as 20 minutes - obviously
far outside the limit of the ASP.Net timeout limit.

My presumptions on why/how this is happening boil down to bad network
connections to the client - lots of packet resends. ASP.Net hands off the
bytes to IIS for transmission but who knows how long that will take? Either
a patchy network or a patchy client or an intentional tweaking by someone
malicious could drag it out a long time ("Eh? What's that? Couldn't hear
what you said.")

If I'm anywhere in the ball park, it leads to a few questions:
1) Is there any setting to govern how long IIS will try to send the bytes?
A number of the requests in the log have substatii of 64, 121, or 1236 (all
network errors) but a bunch of the really long ones were eventually
successful. I'd just rather not take a half hour to get there.

2) Once ASP.Net hands the bytes to the transport layer, does the request
stay active in the ASP.Net queue until it hears the request is done? That
might also explain some instances where I see requests (even small ones) that
have sat on the queue 4+ seconds before even getting to start.

3) We're using IIS 6 with the Blowery compression module... Does adding a
custom module in on the back end complicate the transmission section of
delivery?

Thanks
Mark

 

[Allen Chen [MSFT]]

Hi Mark,

Specifically, I'm seeing that the time-taken column for some requests is
running into multiple minutes, sometimes as high as 20 minutes - obviously
far outside the limit of the ASP.Net timeout limit.

Does it happen for a particular site? Are you sure the executionTimeout
(http://msdn.microsoft.com/en-us/library/e1f13641.aspx) setting of that
site is less than 20 mins and that site is an ASP.NET web site?

Regards,
Allen Chen
Microsoft Online Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Mark]

Hi Allen...

I've seen these outliers (about .5% of the requests in a log) in a
semi-random sampling of the IIS logs from our 60 web servers. We white-label
for a bunch of our customers, so we have different web pages being served
from different domain hosts on a lot of our servers, but there always seem to
be some of these ridiculously long outliers.

We never change executionTimeout at the ASP.Net level, which is what got me
hypothesizing about what happens to the bytes *after* ASP.Net does a
Response.Write and washes its hands of it.

I could envision scenarios where the rest of the IIS infrastructure is then
faced with trying to shove the bytes down a leaky, unreliable pipeline with
lots of naks or lost packets, leading to incredibly long service times.

My question is there any way to control how long the rest of IIS tries to
battle through the network crap? It's a waste of a socket to spend 20
minutes trying to spoon-feed a single client.

Thanks
Mark

 

[Allen Chen [MSFT]]

Hi Mark,

My question is there any way to control how long the rest of IIS tries to
battle through the network crap? It's a waste of a socket to spend 20
minutes trying to spoon-feed a single client.

Could you try to enable connection timeout of IIS to see whether it works?

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/3
1a2f39c-4d59-4cba-905c-60e7af657e49.mspx?mfr=true

Regards,
Allen Chen
Microsoft Online Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

 

[Allen Chen [MSFT]]

Hi,

My question is there any way to control how long the rest of IIS tries to
battle through the network crap? It's a waste of a socket to spend 20
minutes trying to spoon-feed a single client.

Have you resolved this issue?

Regards,
Allen Chen
Microsoft Online Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

 

[Mark]

Hi Allen...

I still had some questions in my last reply; if you had answers for those,
it would be
great.

Thanks
Mark

 

[Allen Chen [MSFT]]

Hi,

My question is there any way to control how long the rest of IIS tries to
battle through the network crap? It's a waste of a socket to spend 20
minutes trying to spoon-feed a single client.

Thanks
Mark

Is connection timeout of IIS help on this?

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/3
1a2f39c-4d59-4cba-905c-60e7af657e49.mspx?mfr=true

Regards,
Allen Chen
Microsoft Online Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

 

[Mark]

Hi Allen...

Yes, this article was very helpful, but in my 7/16 response, I had some
specific questions about how MinFileBytesPerSec is applied.

240 bytes/sec
a) still lets large files take many hours to download; it even lets today's
average html page (~50k) take longer than you might want.
and
b) is much more granular than the network. Packet sizes are much bigger
than 240 bytes.

So my questions were:

But tcp packet sizes are much bigger than 240 bytes (say in the 10k range)
and between packet shipment and ack/nack there is an arbitrary amount of
time. So if a packet is 10k that's 42x 240. Does IIS send off a packet and
wait 42 seconds for the ack?

And say your connection is being used for HTTP/1.1, so the actual socket
connection is expected to be reused for multiple requests. Presumably
MinFileBytesPerSec is only applied on a request by request basis, correct?
I.e. if one request fails the MinFileBytesPerSec, IIS just stops serving that
request; it doesn't chop the connection?

Thanks
Mark