Cloudonomics Journal

Scaling applications that include AJAX and non-AJAX components may require more than just tuning your web server

A common problem after deploying a Web 2.0 AJAX-based application shows itself through poor performance or lower capacity on the server, often both. Web serving tuning is almost always the first step in improving performance and capacity, but the inherently competing behavior of AJAX-requests and “normal” HTTP requests quickly becomes problematic as well. Tune for the AJAX requests and performance of regular old HTTP requests suffers. Tune for regular old HTTP requests, and performance of AJAX-requests suffer.

This is primarily because of the way in which the client-side application, the browser, interacts with the server. “Regular old HTTP requests” are typically those that GET a piece of content, static or dynamic, and that’s it. There may be many of these requests whenever a page (URI) is requested – all the images, client-side scripting files, style sheets, etc… – but they are not interactive. The browser requests them, receives them, and that’s it. AJAX-based requests, however, are inherently interactive. They are often automatically refreshed on an ongoing basis, on a prescheduled interval, or invoked by the user as they interact with the application. These requests are not “load and forget” like their traditional staticesque counterparts, but rather they are expected to be made often.

The overhead associated with opening and closing connections is well understood, and it is often the case that the web server configuration will  be adjusted to meet the more demanding nature of the AJAX-based requests in an application. This is often accomplished by ensuring the KeepAlive setting (in Apache) is “on” and that the KeepAliveTimeout (in Apache) is high enough that AJAX-based requests occur before the timeout closes the connection. This allows the continued reuse of an existing connection between the browser and the server and improves performance. But it also ties up resources on the server keeping that connection open, which reduces the overall capacity of the server in terms of its ability to serve users. Optimally a short KeepAliveTimeout, if any, is best for non-interactive requests and often disabling KeepAlive actually improves performance for non-interactive applications.

Obviously these two behaviors are completely at odds with one another.

There are a number of ways in which the competing needs and interests of the interactive (AJAX) and non-interactive portions of your web application can be addressed.

1. Configure two different servers: one to serve interactive content, i.e. AJAX-based requests, and one to serve non-interactive requests, i.e. everything else. This way, each server can be specifically tuned (and sized) according to the application behavior. This is beneficial for several reasons, including the ability to “scale out/up” only the interactive-serving functions when or if it becomes necessary. This can be achieved simply by using specific host names for specific requests. If you do not have a public IP address that can be assigned to each host, however, you’ll need a proxy, like a Load balancer, to sit in front of the servers and handle the direction of requests appropriately or you could use mod_rewrite to achieve a similar architecture. When a mediating solution like a load balancer is used to implement this solution, there are a several ways to achieve the behavior. One method is to rewrite requests directed at a specific URI, for example: http://www.example.com/ajax/request1.php would be redirected to the server designated as the “interactive” server while other requests would be forwarded to the non-interactive server. An application aware load balancer, i.e. application delivery controller, can examine the request itself and base the same decision on the actual data being exchanged. For example, many AJAX frameworks (XAJAX, SAJAX, Prototype, etc…) often use the HTTP POST method to send a request and use specific parameters such as “xjxfun” to indicate which function is being invoked on the server side. By examining the data being exchanged an application aware proxy (load balancer) can use that information to send the request to the appropriate server.

2. A second means of addressing the problem of resource depletion and performance with AJAX-based applications is to use a load balancing solution to mediate for the clients and employ the use of TCP multiplexing on the server-side to optimize resources. Because a load balancer is almost certainly capable of simultaneously handling a significantly higher volume of connections than a single web server, the competing behavior of interactive and non-interactive HTTP requests in a web application do not impede performance or impact its capacity. By allowing a load balancer to mediate for those requests, it can better manage the resources on the server and ensure that both capacity and performance are maintained. For every X client connections, the load balancer maintains only a fraction of X connections to the server and reuses them as the means to optimizing the server-side resources. This method is actually likely to increase overall capacity because it will reduce the number of connections required to be in use at any given time on the server(s) and eliminates the performance overhead associated with opening and closing TCP connections.

3. A third solution might be found in scaling up (beefier hardware) and leveraging virtualization. For web applications, specifically, it may be the case that virtualization of the application will actually improve performance. This is particularly true of I/O intensive web applications, but is also likely true of high-connection oriented applications as well. This is  because as a web server begins to reach its capacity in terms of connections it requires more processing to “find” a given connection. Nearly all TCP-based applications exhibit similar performance characteristics and, upon reaching a certain threshold of connections, performance degrades. By finding the “sweet spot” ,i.e. the highest number of connections that retains acceptable user response time, and deploying multiple instances of that application, each tuned for that upper bound, it may be possible to squeeze out better performance and higher capacity of your web applications. Multiple instances will require a proxy, i.e. load balancing, solution as well, but this would allow for a “scale up” solution that takes advantage of a single, beefy physical server that eliminates the IT management and maintenance overhead of additional hardware in the data center.

In all three cases the solution to the problem of competing resource utilization between interactive and non-interactive components of a web application involve architecture. Some might believe that simply moving the application to “the cloud” would address the problems and, in some ways, it will. Cloud computing environments can indeed be managed such that applications are automatically scaled out to maintain performance and increase capacity, but the interesting thing about that is the environments are essentially implementing a combination of the three solutions heretofore presented. The bad news is that such a solution does not optimize resource utilization, and thus the costs associated with a cloud computing solution to the problem may be surprising and even prohibitive depending on your IT budget. And the cloud computing solution, of course, is ultimately also about architecture, as it is the architecture that allows for automated scalability.

In most cases involving web applications the answer to scalability challenges is going to end up being architecture, and that architecture is increasingly requiring the use of application network components such as load balancers to implement. This is why it is often advised that applications are architected to take advantage of application networking components from the beginning, even if such solutions will not be necessary to address capacity and optimization on day one. By architecting a solution that includes application networking as part of its design and deployment model, there is far less disruption later when such a solution does become necessary.