Application Acceleration
Sencilo believes networks are at the heart of the delivery chain of most business-critical applications, enterprises face performance challenges that are relevant to acceleration technologies. Some organizations have unsuccessfully deployed optimization or QoS techniques in hopes that every user of business critical applications gets a share of the WAN resources. In doing so, they've discovered that users located in long-distance sites often get shortchanged with response times. Other firms — after a modification of the IT environment, such as an upgrade of a business application — suddenly get complaints about the response time of the newly deployed application version. In general, users of bandwidth-hungry applications remain dissatisfied from the performance they obtain over the WAN.
Enterprises also try to simplify the management of key business applications through the consolidation of distributed servers. Server consolidation brings many benefits, including a dramatic reduction in management costs. However, consolidating servers means that end-users who are accessing applications today from the LAN will access them tomorrow from the WAN. By doing so, they may face performance degradations caused by higher network delay and decreased bandwidth. In all of those situations, a lower WAN delay and a higher bandwidth capacity would solve the performance issues. But bandwidth is a finite resource that has a cost, and delay is bound to physic constraints.
THREE APPLICATION PERFORMANCE BOTTLENECKS
Sencilo has identified three key areas where applications not performing well over the WAN? It is important to understand that the WAN behavior of each application can be very different. Similarly, the different acceleration technologies that exist on the market will not have the same impact on all applications. The simplest way of understanding what to expect when deploying an application over the WAN is to consider what resources it requires to work efficiently and what is preventing it from accessing these resources when it is deployed over the WAN.
Applications are typically implemented with a client and server architecture using the TCP protocol, the most common protocol used for reliable communication between two hosts in IP networks. A typical application task consists of a client sending some information and a server answering it. The way information is sent and received is not the same for each application, and it is intimately linked to the application design.
The notion of application protocol describes the way information is transmitted between clients and servers over the WAN. The application protocol relies on a succession of requests and responses (also called "turns") that take place between the client and the server to implement what is perceived by the user as a basic operation (the "task"). The key resource required to perform the task is the network bandwidth. The network delay is also a fundamental parameter to allow efficient execution of the application turns.
In this process that is taking place inside every business application, there are only three key bottlenecks that can cause application performance degradations, and these are linked to each other. An application will perform well if it has the bandwidth it requires, if TCP is not preventing the application from using this bandwidth and if the application protocol being used is not preventing the application from using the TCP-accessible bandwidth.
1. THE BANDWIDTH BOTTLENECK: The key resource required to perform the task is the network bandwidth. Bandwidth can be a very important bottleneck because the performance of all applications is in some way related to the available bandwidth. If the available bandwidth is higher, then the response time of the application will be lower to a certain point for most applications. The more applications are based on the transmission of a large amount of data, the more the available bandwidth will have an impact on response time. Applications that are dependant on bandwidth include file sharing, email and HTTP-based applications. Some applications are natively trying to minimize the amount of bandwidth they need using well-known techniques such as compression or differencing. For example, HTTP servers can be configured so that they transmit all the objects in a Web page in a compressed format understandable by the browsers. Backup applications are bandwidth hungry but are often minimizing their requirements using the notion of increments, where what is transmitted is only the difference or the "delta" over what was transmitted in an earlier backup.
2. THE TCP BOTTLENECK: The next bottleneck is TCP itself. TCP is designed to implement reliable communications between two hosts. It makes sure that the data transmitted from Point A reaches Point B. To do so, it uses the notion of segments of data that needs to be acknowledged by the receiver. The notion of acknowledgement makes TCP performance dependant on delay; the sender waits for the previous segment of data to be acknowledged by the receiver before sending another. The higher the delay, the lower the performance of protocols that rely on acknowledges. To prevent delay from having too great of an impact on performance, TCP is using the notion of windows that absorb the delay using data buffers at the emitting and receiving sides. But this mechanism is not perfect and does not always allow TCP to use all the available resources. This happens especially on links with a great deal of bandwidth and/or a high transit delay. This limitation is called the "bandwidth delay product" issue.
TCP has other characteristics that can lead to some performance limitations. In particular, the protocol is designed to work independently of the underlying network characteristics. To do that it tries to always discover the available bandwidth by progressively increasing the throughput of each session until it runs into congestion. The mechanism that tries to find the maximum available bandwidth is called the "slow-start." During the discovery phases, some available bandwidth can be left unused for a moment. With applications making an extensive use of the transmission of independent chunk of data over TCP (such as HTTP-based applications), the wasted resources can be huge, which inevitably leads to a sub-optimal response time. Modern TCP implementations such as the ones found in Linux or Windows Vista and Longhorn overcome a part of TCP limitations. The "bandwidth delay product" issue is solved, but the "slow-start" issue remains.
3. THE APPLICATION PROTOCOL BOTTLENECK: Application protocols define the way the information is transmitted between clients and servers over the WAN. The application protocol relies on a more or less complex succession of requests and responses ("turns") that take place between the client and the server to implement what is perceived by the user as a basic operation (the "task"). Some applications are not designed for the WAN, and their application protocols are relying on a number of turns that is too high. Those application protocols are designed as "chatty" protocols. As a result, the application's effective throughput is linked to the network transit delay. When the delay is increasing, the performance degrades. A few protocols used by Microsoft in its applications such as CIFS and MAPI are known to be "chatty" protocols. Not all applications are exhibiting those issues, since many software vendors have implemented some mechanisms that make the application efficient over the WAN. The first mechanism is to use the notion of windows in the same way as TCP. Such a mechanism allows the application to make full use of the available WAN resources if required. The second mechanism is called application caching, whereby the application minimizes the amount of data being transmitted by caching some server-provided data on the client side. In some cases, the application pre-populates the client cache asynchronously from user actions. Such a mechanism provides the ability to isolate the user experience from the constraints of the WAN.
ACCELERATION PITFALLS AND TIPS FROM Sencilo HealthIT Solutions
Beyond the notion of the three bottlenecks, network managers should be aware of a number of pitfalls and tips that can impact the design of an acceleration strategy:
1. Acceleration is not always the answer to bad response time
2. Acceleration makes optimization even more important
3. Compression is not a substitute for optimization
4. Not all acceleration mechanisms are equally transparent toward IT
5. Not all acceleration mechanisms are equally transparent toward the WAN
6. The solution may lie in the IT itself
1 . ACCELERATION IS NOT ALWAYS THE ANSWER TO BAD RESPONSE TIME
In a congested network, acceleration technologies will not have the same impact as they would in a network that is not fully utilized. Acceleration mechanisms working at the TCP or application protocol levels are typically useless when there are no free resources to grab.
In any case, optimization is a mandatory technology to ensure that the response time of critical applications is kept minimal. When congestions occur, the size of router FIFOs are increasing, the transit delay get higher and packets can be lost. As a result, the performance of applications that depend on bandwidth and/or depend on transit delay degrades rapidly. If you experience a bad response time, you should put in place proper QoS and optimization as a first step. Applications that are still not performing well are probably facing a limitation related to one or more of the three application performance bottlenecks.
2. ACCELERATION MAKES OPTIMIZATION EVEN MORE IMPORTANT
Many acceleration technologies rely on the ability to go beyond what network protocols can do to more effectively utilize available network resources. For example, they allow the flow to "fill the pipe" in situations were network protocols prevent them from doing so. Without a proper combination with optimization technologies, many acceleration techniques can actually worsen the delivered quality because they can create or reinforce congestion situations. This is especially true in MPLS networks with meshed topologies.
3. COMPRESSION IS NOT A SUBSTITUTE FOR OPTIMIZATION
Compression creates virtual "free" bandwidth, but the amount of bandwidth created varies over time depending on the amount of redundancy in the flows. Compression can maybe "make room" for some interactive or real-time traffic such as VoIP, but this varies over time and absolutely no guarantee can be given in terms of the amount of bandwidth created. In no way is compression a substitute for advanced QoS mechanisms.
4. NOT ALL ACCELERATION MECHANISMS ARE EQUALLY TRANSPARENT TOWARD IT
Acceleration mechanisms try to minimize the impact of the WAN for client/server applications. Some acceleration solutions preserve the communication between the client and the server and they do whatever is possible to optimize this communication. Some other acceleration solutions go further; they just break the communication between the client and the server. An edge device placed close to the clients answers to clients on the behalf of the servers. Nothing can be more optimal in terms of minimizing the impact of the WAN, since the WAN is not utilized at all.
Unfortunately, there is a dramatic drawback to such mechanisms: the edge device is no more than a cut-down version of the central server and as such must be closely managed. This is especially true for Authentication, Authorization and Accounting (AAA) policies. If an acceleration device answers to a client on the behalf of the server, it must be able to authenticate it, to check its credentials and report the access back to the logging system. It must also implement a tight synchronization with the origin server to be sure that the data served at the edge is fresh. If the device authorizes clients to write data without any connection to the server, then a distributed data locking and synchronization solution must be put in place.
5. NOT ALL ACCELERATION MECHANISMS ARE EQUALLY TRANSPARENT TOWARD THE WAN
Many acceleration solutions are not compatible with common WAN mechanisms. They always transform application sessions into something different over the WAN section. They also typically force the traffic to flow between a static pair of devices. As a result, they have a severe impact on firewalls, link load balancing, asymmetric routing and intrusion detection systems.
6. THE SOLUTION MAY LIE IN THE IT ITSELF
Acceleration is often used when enterprises decide to simplify the management of key business applications through the consolidation of distributed servers. Consolidating servers means that end-users who are accessing applications today from the LAN will access them tomorrow from the WAN. In such a situation, it is always possible to make use of Citrix Presentation Server technology or Windows Remote Desktop to minimize the distance between the client applications and the servers. Such a solution keeps the application flows at the datacenter, removing the need to address their potential intrinsic performance bottlenecks. This does not, however, remove the need to manage the performance of the Citric/RDP flows through optimization. In the case of a consolidation using the native application clients, the enterprise must be aware of the three key bottlenecks that can cause application performance degradations.
The enterprise must also be aware that software vendors are working on solving those bottlenecks, especially the application performance bottleneck. Microsoft has been doing this for many years. Exchange 2003, for example, is exhibiting vast performance improvements over its predecessors when used over the WAN thanks to the Outlook 2003 application cache. CIFS, a protocol known for bad WAN performance, has been completely redesigned to solve WAN performance issues as part of the Windows Vista and Longhorn operating system releases. An acceleration initiative is thus a good time to think about upgrading the application to benefit from the highest level of WAN compatibility.
CONCLUSION
Many enterprises face some application performance challenges. However, it is important to understand that the WAN behavior of each application can be different. Similarly, the different acceleration technologies that exist on the market will not have the same impact on all applications. In business applications, there are only three key bottlenecks that can cause application performance degradations. It is important to understand which among those three are actually causing performance problems.
Beyond the notion of the three bottlenecks, network managers should be aware of a number of pitfalls and tips that can have a strong impact in the design of their acceleration strategies. Optimization and acceleration are two different things and should each be well understood. The notion of transparency is also fundamental, since it drives a large portion of the Total Cost of Ownership (TCO) of acceleration. Understanding these issues is critical if enterprises are to avoid network bottlenecks and succeed at truly optimizing their business networks.
Related Products:
