You've just deployed a Web 2.0 application that includes an AJAX-based real-time updating component. Maybe it's something like Twitter, or a stock chart, or sports scores. Whatever the content is, you've been hearing from users that sometimes those updates just ... fail.

Upon further investigation you might discover - will likely discover - that users for which the updates fail have high-latency or low-bandwidth connections. Or both. You don't want to penalize broadband users for whom the app works just fine, but you don't want to alienate those users stuck on dial-up or poor connections.

Worse, you can't know which users are which from within your application. But the answer clearly is to adjust the update interval based on the current network conditions experienced by each user. How the heck are you gonna do that?

iRules to the rescue.

Collaboration Required

First, you're going to need to collaborate. That means developers and network guys (or whomever administers your BIG-IP), working together. I know, that's nearly heretical, but believe me, doing so will likely solve your application performance problems.


All you need to do is extract the interval values into constants and let the BIG-IP admin guys know what those constants are. Something simple, but easy to find with a regular expression like SPORTS_SCORE_UPDATE_INTERVAL or APP_UPDATE_INTERVAL will do just fine.   

var UPDATE_INTERVAL = 3000; 

Of course you'll need to ensure that you're using this constant in the appropriate timeout function(s) that control the updates.

Network/BIG-IP Admin

What you have to do is write an iRule that determines the latency/connection speed of any given client and then adds code to change the update interval with a value appropriate for current network conditions. Basically you'll want to tack on the update to the end of the current response such that the script is evaluated upon being loaded into the browser. You will need to coordinate with the developers to ensure this will work with their application, which will depend heavily on what type of data is being returned and how the developers are using it in their application. If you can collaborate before the application is deployed, while still in development, you can work together to ensure this iRule will help your AJAX application's performance by making sure the application will parse out and evalute the update script.

If it is not possible to adjust the update interval using this technique, you may want to search and replace the update interval value on the first request only based on network conditions. This makes the update interval static for the duration of the user's session but has the advantage of being tailored to their specific connection conditions at the time they start the session. Basing the update interval primarily on bandwidth should alleviate most of the pain experienced by low-bandwidth AJAX application users.

You can use the TCP::bandwidth and TCP::rtt values to help determine what kind of update interval you want to set.

Let's say the client is clearly on a high-latency, low-bandwidth connection. You'll want to set the update interval with something more appropriate to their current network condition, say 15 seconds:

Remember that JavaScript based times are always in milliseconds, so use the number of seconds you want to wait multiplied by 1000.

For high speed, low-latency connections, you can either leave the code as is, or update it with a lower value, say 5 seconds:

I'd suggest the latter, as you can then rest assured that the update interval is being applied based on current network conditions. After all, you never know when even a traditional high-speed, low-latency connection might suddenly degrade.

There are a number of variables you might want to use to determine what the update interval should be, including current response time of servers dishing out the dynamic content, or time of day, or other quality of service and service level agreement type variables. The focus is really about adjusting the behavior of the AJAX application based on the real-time conditions of the network such that the application performs as well as it can without overloading servers or network connections.

Imbibing: Coffee