|
customer login | partner login |
|
|
 |
 |
||
 |
|||
|
|
 
|
|||
|
|
|
|
How to improve Web performance with application delivery networks Service providers using a technology called application delivery networks (ADN) are offering Web site managers a new option to increase Web performance. When Web content is delivered over the Internet, delays occur at three main points:
Figure 1 shows the time to download a search results page from computerworld.com from several cities, as measured by Keynote Systems Inc.'s network of distributed agents. Computerworld servers are located in the Boston area, where response time is very fast --about a second. But even for these well-connected Keynote agents, response time increases dramatically as the distance from Boston increases. These additional delays are associated with the middle mile, but how? Figure 1: Global download time for Computerworld.com search page 
A fundamental problem with Internet performance
The standard measure of network latency is round-trip time (RTT) -- the time it takes for an IP packet to travel from one location to another and for a response packet to travel back. RTT encompasses lower-level causes of latency such as indirect routing, hop count and the speed of light. However, backbone round trip times are generally small. RTT between two well-connected locations in the U.S. is generally well under one tenth of a second (100ms) and, unless there is serious congestion, RTT between the U.S. and Europe or Asia is generally less than 200ms. So RTT by itself cannot explain the rapid response degradation seen in Figure 1. Nor is the explanation packet loss or congestion: Figure 1 only plots samples when all relevant network paths were clear. The resolution of the disparity between small RTT and multisecond latency impact lies further up the protocol stack than IP; specifically within the TCP and HTTP protocols. During the course of a typical full-page Web download, TCP and HTTP together force numerous back-and-forth exchanges. For example, each new TCP connection requires a delay of one round trip to simply establish a new connection (the "handshake") and then additional round trips to "warm-up" the transfer. The result of all such effects is that there is a large RTT multiplier. When downloaded through Keynote, the Computerworld search page has a multiplier of 38 so that if RTT is 200ms then the total latency impact is 38x200ms=7.6 seconds. In general, the multiplier depends on many factors including page size and composition, as well as fine-details of the client and server technologies used. A secondary penalty occurs if IP packets get dropped. Because of how TCP and HTTP interact, it's common to see a TCP "timeout" if a packet is lost during a Web page download. This is usually a multisecond penalty on top of the latency created by RTT and the multiplier. So the middle-mile Web performance problem is not just RTT: it's the combined effect of RTT and the multiplier. It's not just packet loss: it's packet loss together with costly TCP timeout-based recovery. Optimizing for application delivery Familiar Web acceleration technologies view the middle-mile problem as a network layer issue. Replication and Web caching reduce RTT by placing content closer to the end user; advanced routing technologies reduce RTT and packet loss by choosing better backbone paths. But these technologies do not address the multiplier or loss recovery. In contrast, ADNs tackle HTTP/TCP inefficiencies directly. Application delivery networks transparently reduce the response time and increase the availability of dynamic Web applications hosted at a centralized data center. ADNs do not distribute content or application code, but instead utilize a specialized protocol across the middle-mile to make the transmission more efficient. Distance-induced delay is minimized by utilizing this special purpose protocol, which is designed to deal with high latency networks and the request response nature of Web applications while maintaining all the beneficial features of standard protocols. Figure 2 illustrates the significant impact of the protocol on global end user response times. Without the use of an ADN, users in Singapore experience more than an eight-second response time when accessing a search result page on the Computerworld site near Boston. With an ADN, the response time is 3x faster, much closer to the same time as for local Boston users. Figure 2: Measured download time for Computerworld search page, with ADN 
To use an ADN, companies contract with a managed service provider. An ADN need not modify protocols on an end-to-end basis. Rather, a service provider's ADN can comprise geographically dispersed points of presence (POP) of two types: those on the "edge" of the Internet near application clients, and those near the Web servers. Client traffic using standard protocols -- such as HTTP and TCP -- is directed via Domain Name Service to a service provider's ADN POP near the client, where the traffic is repackaged to use protocols optimized for long-haul communication across the Internet. When the optimized traffic reaches the server-side POP, it is relayed to the Web server using standard protocols. The same thing happens in reverse as the Web server responds to user requests. In this way, optimization techniques can be used across the backbone and yet the ADN offers fully transparent acceleration with no client or server upgrades or modifications. Such an ADN enables sub-second response for users around the world. When Web performance is critical, using a managed ADN service may be an attractive new option. (Adam Grove is the CTO and founder of Netli Inc.) He earned his PhD in computer science from Stanford University in 1992, and has a BS in mathematics from the University of Auckland, New Zealand. Source: Computerworld |
|
|
|
||
|
||
|
||
|
|
||
|
|
||
|
||