Deep-Dive on Performance Measurement

Observer Effect

The Observer Effect describes the phenomenon where behavior changes when it is under observation.  Most browser performance-measurement tools are subject to some amount of observer effect.

About Fiddler

Fiddler is implemented as a HTTP proxy; this gives it the flexibility to work with any application or device that supports a proxy, even platforms that cannot themselves run the Fiddler proxy. 

One downside of running as a proxy is that a client application may behave somewhat differently if it knows a proxy is in use.  Most of these effects are very minor and will not meaningfully impact your measurements.  Known impacts include:

• The browser may emit new headers (specifically Proxy-Connection) when making requests.
• The browser may order requests differently or limit the number of connections to the proxy.
• The proxy (rather than the browser) will perform the DNS lookup for the site's hostname.

Keep in mind that a very significant percentage of web users are behind a proxy server anyway, so Fiddler's impact will often mimic the real-world impact of proxies on your site.

Tips for minimizing the observer effect

• Enable Streaming Mode.
• Enable both client and server connection reuse inside Tools / Fiddler Options.
• Increase IE's connections-per-host limit (to unblock connections-per-proxy).

Alternative HTTP Traffic Monitoring Strategies

Instead of implementing a network proxy, there are several other architectures that are commonly used for performance measurement:

• Packet Tracing -- Using Network Capture tools (e.g. Netmon3, WireShark) these tools reassemble low-level TCP/IP traffic into higher-order traffic like HTTP.  Pros: Accurate; application agnostic; lowest Observer Effect.  Cons: Difficult to author; difficult to reconstruct higher-level scenarios (e.g. page navigation) from low-level captures.
  
  
• Detours / Thunks -- Induce target process to load your DLL, which then wraps/overwrites functions in the target process.  Those "thunk" functions then emit timing information to enable performance measurement.  Pros: Highly accurate for a given process.  Enables viewing traffic that is pulled from cache rather than hitting the wire.  Cons: Difficult to write; usually application specific; often unstable.
  
  
• Protocol Wrapping -- Replace the HTTP/HTTPS protocol implementations with your own wrapped version.  Pros: Relatively straightforward compared to thunks.  Cons: Usually application specific; very often unstable; Internet Explorer 6 and 7 use the network differently when they detect wrapped protocols in use. 
  
  
• Browser Event Trapping -- Browser raises events when certain events occur (e.g. DownloadComplete, DocumentComplete).  Pros: Easy to implement.  Cons: Application specific; poor granularity.