AJAX and Application Performance
The network guys have a secret they don't want you to know: The computational cost of TCP session setup and teardown is high, second only to application processing time in terms of its effect on the overall response time of your application. Every connection made by a web browser to the server requires an underlying TCP session, and it is time consuming to both client and server.
HTTP 1.1 dealt with this issue by introducing pipelining of HTTP requests over an existing TCP connection, ostensibly reducing the number of connections necessary to load a web page. In a sort of Moore's Law like phenomenon, as performance improved pages again grew even fatter, requiring even more requests and more bandwidth.
But HTTP 1.1 says that clients should not open more than two connections to a server, and by default Internet Explorer adheres to the specification. While pipelining of HTTP requests is advantageous in terms of minimizing the impact of connections on the server, it isn't so great for the end-user and the "slow" rendering of large pages within Microsoft's browser is primarily due to the limitation on connections and not any specific deficiency with the underlying code. The specification was written with the performance of servers, not clients, in mind.
AJAX is exciting because it provides the means by which developers can limit the initial amount of data transferred to the client, pre-fetch data and images to enable a more responsive experience, and silently load data during the session that is unique to the user's interaction. AJAX-based applications are not page-centric, they are component centric. This allows browser-based clients to act more like their fat-client counterparts, offering an interactive experience that doesn't require a constant refresh.
This does result in fewer total page refreshes, but requires a great deal more application logic on the client to manage additional connections to the server and exchange data at the appropriate times, such as when the value in a list box changes or a new tab is selected.
The problem with this model begins to manifest itself in the communication channel underlying AJAX requests. Developers taking advantage of libraries like Dojo or Zimbra rely upon these toolkits for the basic format of data being exchanged - and rarely have control over that format. The toolkits are great for enhancing developer productivity but poor at enabling developers to understand and control the exchange of data. The data is usually exchanged using XML, with no defined schemas against which messages can be validated, leaving applications vulnerable to a set of XML-borne web attacks that are easily prevented simply by tightening and enforcing a well-defined schema.
Also problematic is the refresh rate of AJAX-based components. AJAX makes it a simple task to not only build interactive interfaces, but to provide a near real-time experience for the user. AJAX doesn't solve the inability of the server to push data to the client, therefore applications remain reliant on polling to update data.
The refresh rate can impede performance in multiple ways. First, it maintains an intermittent flow of data between the client and server. Depending on the refresh rate this can cause any number of performance problems. If it's too high and exceeds the browser's default idle time out value (1 minute for Internet Explorer), then the additional performance penalty incurred by establishing a new TCP session with every request drives up response time. This is also true of normal requests made via JavaScript -- if the user is idle too long, a new connection will need to be established. If it's too low and the user is on a WAN or slow link, the requests can begin to overlap and the client will be constantly sending and receiving requests at ridiculous rate.
In addition to the performance implications on the client, the server also has to maintain more connections for longer periods of time and it may not be optimally tuned to handle the additional burden. Web servers were meant to serve content in a request-reply paradigm. Although AJAX complies with the paradigm, it does so in ways that were not anticipated by those who penned the HTTP specification by reusing the connection over long periods of time.
To address the potential performance pitfalls you'll need to tune your web server accordingly. There are a limited number of parameters you can tune to assist in improving performance of AJAX-based applications and they are tactical, stop-gap solutions rather than strategic, but they might tide you over while you search for long-term solutions.
- Increase the TCP time out to a value in-line with the rate of requests in your client. If you anticipate a request every 3-4 minutes, you may want to raise the TCP timeout to 5 minutes to eliminate the overhead of initiating a new connection. (Connection Timeout for IIS, KeepAliveTimeout for Apache)
- Validate that the maximum number of requests per connection is high enough to support your application. Consider the number of requests in a typical user session and set this value high. (MaxKeepAliveRequests in Apache, no equivalent in IIS)
Even after tuning your web server you may find that your users experience inconsistent performance and your web server may be experiencing undesirably high CPU utilization rates. You may run into an artificial simultaneous connection limitation set by the web server or you might know that additional AJAX-based applications are coming and you need a more robust and widely applicable solution. If that's the case, you'll need to turn to an external solution such as application delivery controller.
An application delivery controller addresses these performance issues by providing optimized TCP and HTTP stacks capable of handling the higher request rate in a more efficient manner. Such devices provide a more consistent user experience because they are capable of optimizing communication between the client and server as well as providing better management of the resources available on the server by being aware of the state of the server and managing requests and responses appropriately. One such feature provided by these devices is request throttling, which limits the number of times per session, per user, or per second that a request can be made.
Application delivery controllers that act as a full proxy are also capable of servicing more clients while maintaining a lower number of connections to back-end servers, essentially cutting the number of connections to servers in half. This feature lets you provide consistent application performance to more clients without deploying additional servers.
These devices are also aware of the bandwidth available to the client and can adjust the rate of delivery accordingly while allowing the server to deliver content at the highest rate possible. This means the server can deliver content as fast as possible and does not need to tie up a connection while it waits for a client on a slow link or device (WAN, dial-up, mobile devices) to receive the data. This can also eliminate the possibility of needing a second, third, or even fourth web server to handle the increase in requests created by AJAX and Web 2.0 applications.
