A common question we hear from our customers is “What is the Blocked time in HttpWatch and why are we seeing some much of it?”

The Blocked time in HttpWatch is shown as a gray block at the start of a request:

We measure this time by looking at the time interval between these two events:

1. The point at which IE determines that it requires the resource at a certain URL. For example, it may have downloaded some HTML and encountered an <img> tag that refers to a GIF file.
2. At some later time IE peforms a network action required to download or validate a cached copy of the resource.

During this time interval, IE will check the cache to see if the resource is stored locally, determine what headers and cookies would have to be sent in a GET request to the server, and if necessary, wait for an existing connection to become available.

Although, IE is multi-threaded and could start downloading many resources in parallel it is subject to a connection limit per host name. The HTTP 1.1 specification (RFC2616) recommends that HTTP clients should have no more than two connections active per host name. Therefore, a web page that has all its embedded images, CSS and javascript files on the same hostname (e.g. www.example.com) will only be able to use a maximum of two connections to download content.

Here’s a screenshot from HttpWatch that shows what happens when you force a refresh (Ctrl+F5) of our home page using IE 7:

At any one time, only two HTTP requests are actively downloading content. The rest are in the blocked state waiting for their turn to use one of the two connections to the web server. The two yellow segments in the first two requests indicate that two TCP connections were made to the server (a yellow segment in an HttpWatch time chart indicates the TCP connect time).

For many web pages this has a major performance impact and is a strong motivator for reducing the number of round trips whenever possible.

Microsoft has just released IE 8 Beta 1. One of the most significant changes compared to IE 7 is that the maximum number of connections per host name has been changed. If you are on a fast, broadband connection it now uses a maximum of six rather than two connections per host name.

BTW, if you are going to use HttpWatch with IE 8 Beta 1 please make sure that you download and install version 5.3.

This screen shots shows the six connections being made with IE 8 and the increased concurrency during download:

The increase in the number of connections leads to a major reduction in blocked time. We found that the load time for our home page, with an empty cache, is on average 50% less in IE 8 Beta 1 compared to IE 7.

Steve Souders, author of ‘High Performance Web Sites’, has written a blog post entitled ‘Roundup on Parallel Connections’ that discusses the connection limits of other browsers and the possible effect on existing web servers.

Version 5.3 includes printing, print preview, support for IE 8 Beta 1 and several other fixes. The version history contains a detailed list of the changes.

The result column in HttpWatch may sometimes display the value (Aborted) instead of an HTTP status code:

(Aborted) is one of three pseudo status codes that are used in HttpWatch to display information about HTTP requests that did not receive a status code from the server:

• (Aborted)
• (Cache)
• ERROR_*

The last two values are fairly straight forward. The (Cache) result is displayed when content is read directly from the browser cache with no network round-trip. If there’s no network round-trip, there’s no HTTP status code returned from the server. And the ERROR_* result (e.g.  ERROR_INVALID_URL) is used when a request fails to complete because an error was detected by Internet Explorer.

The (Aborted) value is more complex in its origin. It occurs when IE has started to process the request for a URL (e.g. to download an image), but then decides to cancel the operation. Here are some examples of when this can occur:

1. If you click on a link or bookmark while a page is downloading, or click on IE’s Stop button, you will see that IE cancels any requests which are still active and HttpWatch shows the (Aborted) result.
2. A CSS rollover image on a page will start a request when the mouse pointer is moved into its active area. If the mouse pointer quickly moves away again, IE may abort the request if it has not already completed.
3. Sometimes javascript is used to fire off requests for background tasks or to gather statistics on a page. Often this can lead to aborted results if the javascript does not wait for the response to be received from the server.

A common question is “Will our server receive requests that ended up being aborted?”. The answer is that it depends when the request was aborted. By looking at the timing chart in HttpWatch you can determine how far the request was through its normally processing cycle before it was cancelled.

Here’s an example of a request that was aborted while a connection was being made:

The server would not have received the HTTP request message in this case, because the Send state was not reached.

The request shown below was aborted when IE was awaiting a response and therefore the request would have been delivered to the server:

The presence of an (Aborted) entry in an HttpWatch log file is often just a consequence of the way that the user is interacting with a web site, rather than an indication that something has gone wrong.