IIS time-taken vs Firebug Net panel vs Fiddler

Hi...

We're running IIS 6 on W2003 boxes. We've been trying to replicate and
track down some complaints of slowness on some requests. In gathering info,
we've had a hard time getting a real sense of how long things take.

We turned on logging in IIS and have been looking at the time-taken column.
Some support docs say that as of IIS 6, this value is supposed to include
time to the client's final ack.

We also installed Firebug 1.0.5 on the firefox clients and tried to use
Fiddler 2 to examine things from the client perspective. Fiddler seems very
iffy. It gets hung, drops connections, and interposes all kinds of flakiness
that make the results pretty much impossible to trust.

The difference between Firebug and the IIS log times though has me
scratching my head. All of the requests in question are returning 304 (not
modified) after the first page view but while IIS always reports the
time-taken as 10-60 milliseconds, Firebug is reporting up to 5 seconds for
those same requests. The huge gap has me wondering which is more accurate.

Is IIS really including time to the client's last ack in the 60 ms? Is
Firebug tacking on all kinds of client-side script execution? Dunno.

What tools do people usually use to try and sort out these kinds of things?

Thanks
Mark

On May 5, 2:07*pm, Mark <mmodr...@nospam.nospam> wrote:
> Hi...
>
> We're running IIS 6 on W2003 boxes. *We've been trying to replicate and
> track down some complaints of slowness on some requests. *In gathering info,
> we've had a hard time getting a real sense of how long things take.
>
> We turned on logging in IIS and have been looking at the time-taken column.. *
> Some support docs say that as of IIS 6, this value is supposed to include
> time to the client's final ack.
>
> We also installed Firebug 1.0.5 on the firefox clients and tried to use
> Fiddler 2 to examine things from the client perspective. *Fiddler seems very
> iffy. *It gets hung, drops connections, and interposes all kinds of flakiness
> that make the results pretty much impossible to trust.
>
> The difference between Firebug and the IIS log times though has me
> scratching my head. *All of the requests in question are returning 304 (not
> modified) after the first page view but while IIS always reports the
> time-taken as 10-60 milliseconds, Firebug is reporting up to 5 seconds for
> those same requests. *The huge gap has me wondering which is more accurate.
>
> Is IIS really including time to the client's last ack in the 60 ms? *Is
> Firebug tacking on all kinds of client-side script execution? *Dunno.
>
> What tools do people usually use to try and sort out these kinds of things?
>
> Thanks
> Mark


Using client-side tools like Firebug or Fiddler is useful if you are
looking at things at the application level -- such as contents of the
HTTP request/response. Anything else about the request/response, such
as encryption, encoding, content-length, timing, etc -- are simply
unreliable from such client-side tools because it requires you to
dissect the entire request/response stack and look at values/timing at
each level -- and client-side tools simply do not have that
granularity nor is it something 95% of people are interested in.

In other words, Firebug/Fiddler will not replace profiling and other
detailed tracing tools while give detailed view of the entire request/
response stack but often overwhelms you with detail.

I use Network Monitor 3.0 from Microsoft.com and ETW Traces (requires
WS03SP1+) to completely profile from request to response, all the way
through HTTP.SYS/IIS/ASP/ASP.Net/COM+ portions of the stack. And
depending on the application, there may be additional counters that
can be enabled to dissect the time taken within the application layer
running on IIS.

IIS6 time-take starts from when HTTP.SYS first receives the request to
when the client sends the final ACK. Note this does not include time
when client sends request to when web server first receives the
request. I don't know what Firebug's measurement of "time taken"
means.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Hi Mark,

On IIS 6.0, usually the time-taken field includes the network time. However
for a response size is less than 2K and is from memory, the network time
will not be included. Due to 304 not modified response is a short
notification for clients to keep using cached file, its time-taken usually
doesn't include network time.

The detailed info can be found in below KB article:

944884 Description of the time-taken field in IIS 6.0 and IIS 7.0 HTTP
logging
http://support.microsoft.com/default...b;EN-US;944884

Please let me know if you have any further question.

Thanks.

Sincerely,

WenJun Zhang

Microsoft Online Community 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:
msdnmg@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 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 or complex
project analysis and dump analysis issues. 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/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi,

Just wonder if you still have any further question on this?

Thanks,

Sincerely,

WenJun Zhang

Microsoft Online Community 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:
msdnmg@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 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 or complex
project analysis and dump analysis issues. 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/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi WenJun...

Thank you for being dilligent on this. So far I haven't found anything that
gives me consistent results for measuring the timing.

At the moment I don't have a qa test bed, so what I'm doing involves mostly
hitting live servers and log analysis. Once I get a test system, I can use
WAST; that reports time-to-first-byte, last byte, avg, etc in ways that I
think are fairly concrete.

I'm also having trouble making sense of some of the log numbers. We're
trying to use System.Web.Caching.Cache as much as we can. When there's a
cache miss, we go to a database, so I can understand why that would take a
lot of time.

But I've instrumented our code quite a bit and I'm finding there are
requests that get the result from Cache and simply write it out - yet it's
taking 20 seconds according to the [time-taken] in the log. I can't figure
out what would take so long.

We have an ISAPI in our system, so I added a pseudo-HTTP header to capture
the time the request is handled by the ISAPI. Then I derived from the Page
object and capture when the Page is constructed. Then I log the number of
milliseconds between ISAPI arrival and Page construction to see if I'm
getting stuck behind a slow boat. I do see requests that are queued for up
to a second but nothing to account for the 20+ second response times serving
from System.Web.Caching.Cache.

I was watching the stats on the server the entire time; it's a dual dual
core. w3wp.exe never got above 750Mg memory nor ~40% cpu.

I don't have any explanation why some requests take a huge amount of elapsed
time when all the stats say they should have been as instant as possible.

Any suggestions would be appreciated.

Thanks
Mark

""WenJun Zhang[msft]"" wrote:

> Just wonder if you still have any further question on this?
>
>
> WenJun Zhang
>

Hi Mark,

I think a thorough way to turn up the root cause of these unexpected delay
is capturing hang dump to debug into the IIS worker process. See which
threads encounter the delay symptom and what they are suspending on.

You can consider use one of your MSDN Free Technical Support Incidents to
work with us via telephone based support for the debugging scenario. This
will be the most effective way to assist you on complicated and project
based issue. Also you won't even need to spend the incident account if the
problem is finally confirmed to be a product issue or can be simply fixed
by applying hotfix. Please refer to the support note below.

About the information of free incident support for MSDN subscribers, please
look at:
http://msdn.microsoft.com/subscripti...t/default.aspx.

To obtain the phone numbers for Microsoft Customer Service and Support
services technology request, please take a look at the web site listed
below.
http://support.microsoft.com/default...S;PHONENUMBERS

If you want to perform the debugging task by yourself first, the DebugDiag
tool will be helpful. Please check its help file for the section about
troubleshooting hang symptom.

Debug Diagnostic Tool v1.1
http://www.microsoft.com/downloads/d...941-c458-46f1-
b24d-f60151d875a3&displaylang=en

Please let me know if you need any help.

Thanks.

Sincerely,

WenJun Zhang

Microsoft Online Community 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:
msdnmg@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 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 or complex
project analysis and dump analysis issues. 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/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.