Keeping the Real in Real Time
From speed to XML parsing, several factors must be addressed to improve a server’s ability to reliably serve real-time data. We explain what you need to know.
by Lori MacVittie
It is likely that you’ve interacted with an AJAX component and didn’t even know it. The ability to update real-time data on a Web page without forcing the reload of the entire page is a boon to just about every organization with a public-facing site, especially those in the financial, media, and service industries. Visiting sites that report current stock quotes today results in a continuous stream of updating data, constantly keeping the visitor up to date on the current price of their favorite stocks. Current headlines now stream across the tops of pages without requiring Flash or Java applets, and the latest and greatest promotions at retail sites are updated on a per-visitor basis rather than by scheduled Web site updates.
Consumers demand for real-time, up-to-date data in a browser has pushed developers to embrace Web 2.0 and AJAX technologies as fast as proponents can build libraries to support them. Unfortunately, the deployment of these technologies has been rushed into production without proper research into their effect on the network and servers providing the content and are thus at risk of turning real-time data into some-time data, eliminating the benefits originally intended by moving to AJAX in the first place.
The XMLHTTPObject in modern browsers enables a nearly continuous exchange of real-time data between client and server, affording developers the means to build highly interactive, always-fresh sites and applications, exactly what today’s highly connected and demanding users have been asking for. This functionality comes at a price, and that price is often paid by unsuspecting clients, servers, and their administrators.
The lure of AJAX in part is the ability to schedule updates to data displayed in a Web browser at specified intervals without user action. This seemingly simple value is actually quite complex to determine because of a number of factors including limitations on the browser, the fluctuating speed of dial-up and WAN connections, and the capacity of back-end servers.
Factors Affecting the Delivery of Real-Time Data
The malicious nature of some users has caused specific limitations to be placed upon browsers that may affect the responsiveness of an AJAX-based site. With a limited number of total connections per browser instance and the popularity of tab-based browsing, it is not only possible but likely that the number of connections allowed will be reached in relatively short order. This can cause both the complete failure of an update (typically with no indication to the user of the error) and delayed updates.
While LAN-connected clients will rarely be affected by congested or rate-limited links, those clients on mobile devices or connected via slower WAN links from remote offices may experience the effects of additional latency with time outs or poorly responding applications. This is due, in part to the “speed of light” problem. Based on the physical distance between the client and the server, there is a base amount of time required for data to travel from the client to the server that cannot be changed by any device or technology. Variable factors such as congestion and packet loss are also applicable to WAN and dial-up links and application developers should consider all these factors when determining the most appropriate update interval for real-time applications to reduce the possibility of out-of-order data and request failures due to time-outs.
The additional burden of an increased request rate over such links will cause the link to become congested more quickly, which has a deleterious effect on the performance of the AJAX-based application as well as all applications delivered over the connection. Not only does the increased request rate affect the performance of the physical link between clients and servers, but it increases the burden on the back-end server by keeping connections open for much longer periods of time. If the update interval is less than the TCP time out value on the server, the connection will remain open for as long as the client has the application open in the browser. This results in a decrease in the server’s ability to handle concurrent requests, and also consumes valuable resources, decreasing the performance of the server and increasing the possibility that it will respond more slowly to requests.
Additionally, the increased burden of parsing XML on the client adds to the total time need to load and render data, increasing the complexity of the equation used to determine the most optimal interval for data updates. Communication with the browser via AJAX and the XMLHTTPObject is asynchronous, so if the refresh interval is too short, updates may appear in the wrong order. This is exactly the opposite of the intention of the application, and can result in decisions being made based on stale data. Similarly, parsing of XML on the server is a compute intensive process, increasing the total time the server requires to respond to a request.
All of these factors must be considered when determining the best update interval for data in a Web 2.0 application, and should be adjusted to suit the time-sensitivity of the application and each individual user when possible.
There are a number of ways these factors can be addressed to reduce their impact on the ability of servers to reliably serve real-time data. The most obvious, “get a fatter pipe”, is not always feasible (or available) depending on the location of branch office locations. Therefore, it is necessary to apply other technological solutions to address these issues.
Web servers can be tuned to efficiently serve real-time data for AJAX-based applications. Increasing the time-out values to better match update intervals ensures that connections are maintained with the client, reducing the impact of opening TCP sessions on both the client and the server. This can negatively impact the capacity of the server, so care should be taken when tweaking configurations to ensure that improvements for real-time applications do not negatively impact performance of other applications deployed on the same server.
An application delivery controller (ADC) can address the impact of higher connection rates by mediating between the client and the server and managing those connections more efficiently than the server can. A full proxy-based application delivery controller can further improve performance by reducing the number of connections required to back-end servers while maintaining a high number of simultaneous connections with various clients. This architecture allows the ADC to essentially reuse connections with the servers. Similarly, encourage developers to reuse connections in the browser to reduce the number of connections required by their real-time application.
WAN optimization controllers, as well as advanced features of application delivery controllers, can address the issues introduced by clients connecting via WAN or dial-up links. Using data reduction techniques, quality-of-service features, and compression, these devices improve the performance of applications delivered over low-bandwidth links and increase the responsiveness of all applications they deliver.
Keeping real-time data real in a variably connected world is certainly a challenge. By addressing the underlying factors that can impede the delivery of that data, you can ensure that your real-time applications are fast, reliable, and up-to-date no matter where your clients may be.
- - -
Lori MacVittie is technical marketing manager at F5 Networks. You can reach her at firstname.lastname@example.org