Let’s start with a question. What download speed would you expect in this scenario?

If you just think of network connections as a simple pipe, then you might expect the download speed to be approximately the same as the slowest network connection, i.e. 20 Mbps. When we tested this out using a local UK based website with a ping time of 13 ms we saw this:

The download speed of 1.57 MB /s or 12.56 Mbps (i.e. 1.57 x 8 for 8 bits per byte) was over 60% of the theoretical maximum for the internet connection. That’s quite respectable if you allow you the overhead of the IP and TCP headers on each network packet.

However, the situation was quite different with our own web site that’s located in Dallas. It has a ping time of 137 ms from our office in the UK:

This time the download speed was 372 KB/s or 2.91 Mbps – less than 15% of the advertised internet connection speed.

At first we thought this was some sort of bandwidth throttling of transatlantic traffic by our ISP. However, when we tried using other networks to perform transatlantic downloads we could never get more than about 3 – 4 Mbps. The reason for this behavior became clear when we saw Aladdin Nassar’s talk about Hotmail Performance Tuning at Velocity 2008:

Slide 7 of his talk shows that with standard TCP connections the round trip time between client and server (i.e. ping time) imposes an upper limited on maximum throughput.

This upper limit is caused by the TCP flow control protocol, It requires each block of data, know as the TCP window, to be acknowledged by the receiver. The sender will not start transmitting the next block data until it receives the acknowledgement from the receiver for the previous block. The reasons for doing this are:

• It avoids the receiver getting swamped with data that it cannot process quickly enough. This is particularly important for memory challenged mobile devices
• It allows the receiver to request re-transmission of the last data block, if it detects data corruption or the loss of packets

The ping time determines how many TCP windows can be acknowledged per second and is often the limiting factor on high bandwidth connections as the maximum window size in standard TCP/IP is only 64 KB.

Let’s try putting some numbers into the bandwidth equation to see if it matches our results. For large downloads in IE the TCP window starts at 16 KB but is automatically increased to 64 KB.

So for our remote download test:

Maximum throughput = 8,000 x 64 / ( 1.5 x 137) = 2, 491 Kbps = 2.43 Mbps

This value agrees fairly well with the measured figure. The 1.5 factor in the equation represents the overhead of the IP / TCP headers on each network packet and may be a a little too high explaining some of the difference.

In the past, with dialup connections the maximum throughput value was much higher than the 56 Kbps available bandwidth. But with today’s high bandwidth connections, this limit becomes much more significant. You really need to geographically position your web server(s) or content close to your users if you want to offer the best possible performance over high bandwidth connections.

There are two solutions to this issue but neither is in widespread use:

• IPv6 allows window sizes over 64 KB
• RFC1323 allows larger window sizes over IPv4 and is enabled by default in Windows Vista. Unfortunately, many routers and modems not support it

In the case of interplanetary spacecraft, the round trip time may be colossal. For example, the ping time to Mars can be up to 40 minutes and would limit TCP throughput to approximately 142 bits / sec! With this in mind an interplanetary version of TCP/IP has been designed:

http://www.cs.ucsb.edu/~ebelding/courses/595/s04_dtn/papers/TCP-Planet.pdf

Conclusions

1. Distance doesn’t just increase round trip times; it can also reduce download speeds
2. Don’t blame your ISP for poor downloads from distant web sites
3. Consider using a Content Delivery Network (CDN) or geo-locating your web servers

We’ve added a page to our HTTP Gallery that provides an introduction to Ajax and some simple working examples. The new page is available here:

http://www.httpwatch.com/httpgallery/ajax/

BTW, you can view the AJAX requests made by this page using the free Basic Edition of HttpWatch.

If you’re tuning a web page’s performance there are two types of visitors that you need to be concerned about:

1. A new visitor to your site who won’t have any of your pages, scripts, CSS or images in their browser cache.
2. An existing user of your site who will have your cacheable pages, scripts, CSS or images in their browser cache.

Visitor type 1) is said to be in the Empty Cache state and Vistor type 2) is said to be in the Primed Cache state. Optimizing for visitors with an empty cache is important as their initial impressions of your site will be affected by how quickly its pages are loaded.

The performance of any page is never going to worse for visitors with a primed cache, but minimizing the load on your site caused by existing users through the use of effective caching will reduce your bandwidth costs and server load.

Your can manually simulate these two scenarios with HttpWatch. For example, you could run an Empty Cache test on our home page (www.httpwatch.com) using these steps:

• Open a HttpWatch in IE and click on Tools->Clear Cache or use the keyboard shortcut Alt+C. If you haven’t cleared your browser cache recently this could take a few minutes:
  
• Click on Record and go to www.httpwatch.com
• HttpWatch will then display a time chart with the page load time:
  

To run the Primed Cache test you would first need to ensure that the page has already been visited and then re-visit it in a new instance of IE. You shouldn’t re-use the same instance of IE because there may some images held in memory from the first visit to the page. To perform the Primed Cache test you would need to:

• Visit www.httpwatch.com in IE to prime the cache
• Close down IE and start a new instance
• Open HttpWatch and click on Record
• Go to www.httpwatch.com
• HttpWatch will then display a time chart with the page load time:
  

Of course, with a test like this you really want to run it automatically. The HttpWatch Automation interface (document in the HttpWatch Help file) allows you to do this in a few lines of code. Here’s the code in C# for the Empty Cache test:

// Set a reference to the HttpWatch COM library
// to start using the HttpWatch namespace
//
// This code requires HttpWatch version 6.x
//
 
using HttpWatch;                
 
namespace EmptyCacheTest
{
    class Program
    {
        static void Main(string[] args)
        {
            string url = "https://www.httpwatch.com/download/";
            Controller controller = new Controller();
 
            // Create an instance of IE (For Firefox use
            // controller.Firefox.New("") )
            Plugin plugin = controller.IE.New();                
 
            // Clear out all existing cache entries
            plugin.ClearCache();                
 
            plugin.Record();
            plugin.GotoURL(url);                
 
            // Wait for the page to download
            controller.Wait(plugin, -1);                
 
            plugin.Stop();                
 
            // Find the load time for the first page recorded
            double pageLoadTimeSecs =
                plugin.Log.Pages[0].Entries.Summary.Time;                
 
            System.Console.WriteLine( "The empty cache load time for '" +
                url + "' was " + pageLoadTimeSecs.ToString() + " secs");                
 
            // Uncomment the next line to save the results
            // plugin.Log.Save(@"c:\temp\emptytestcache.hwl");                
 
            plugin.CloseBrowser();
        }
    }
}

and here’s the Primed Cache test. Notice how we use controller.IE.New() a second time to ensure that a new instance of IE is started:

// Set a reference to the HttpWatch COM library
// to start using the HttpWatch namespace
//
// This code requires HttpWatch version 6.x
//
using HttpWatch;               
 
namespace PrimedCacheTest
{
    class Program
    {
        static void Main(string[] args)
        {
            string url = "https://www.httpwatch.com/download/";
            Controller controller = new Controller();               
 
            // Create an instance of IE (For Firefox use
            // controller.Firefox.New("") )
            Plugin plugin = controller.IE.New();               
 
            // Visit the page to prime the cache
            plugin.GotoURL(url);
            plugin.Record();
            controller.Wait(plugin, -1);               
 
            // Shutdown IE and create a new instance
            plugin.CloseBrowser();
            plugin = controller.IE.New();               
 
            plugin.Record();               
 
            // Visit the page a second time with the cache primed
            plugin.GotoURL(url);
            controller.Wait(plugin, -1);               
 
            plugin.Stop();               
 
            // Find the load time for the first page recorded
            double pageLoadTimeSecs =
                plugin.Log.Pages[0].Entries.Summary.Time;               
 
            System.Console.WriteLine( "The primed cache load time for '" +
                url + "' was " + pageLoadTimeSecs.ToString() + " secs");               
 
            // Uncomment the next line to save the results
            // plugin.Log.Save(@"c:\temp\emptytestcache.hwl");               
 
            plugin.CloseBrowser();
        }
    }
}

BTW, everything we’ve mentioned in this blog post works with the free Basic Edition of HttpWatch as well as the Professional Edition.