Search
Lori MacVittie - Two Different Socks
You are here: DevCentral > Weblogs

posted on Monday, November 19, 2007 9:26 AM

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.

Developers

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:

<script>UPDATE_INTERVAL = 15000;</script>

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:

<script>UPDATE_INTERVAL = 5000;</script>

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



Feedback

No comments posted yet.

Let Me Know What You Think


Please use the form below if you have any comments, questions, or suggestions.

Title:
 
Name:
 
Email: (so we can show your gravatar)
Website:
Comment: Allowed tags: blockquote, a, strong, em, p, u, strike, super, sub, code
 
Please add 3 and 3 and type the answer here:

Blog Stats

Posts:979
Comments:1685
Stories:0
Trackbacks:583
  

Image Galleries

  

Application Delivery

  

Cloud Computing

  

Random

  

Security

  

Chat Catcher

82,243 Members in 102 Countries and Growing!

Join DevCentral Today!

About DevCentral

DevCentral has been a successful, thriving community for many years. We have always strived to bring you the best technical documentation, discussion forums, blogs, media and much more that we can.

So dive in, get familiar with DevCentral. We hope you like it, we hope it makes your job easier, and lets you get that much more power out of the community. To learn more, make sure to check out the Getting Started section. And if you have any problems, or think something could be easier to use, drop us a line to let us know.

Got It !

We've received your comment and transmitted it directly to DevCentral HQ.

Thanks for taking time to let us know what's on your mind. At DevCentral | Community Matters!

Get In Touch With Us

Have questions, suggestions or just want to get something off your chest?

Use our handy form below to Direct Connect with DevCentral Mission Control.

Send Us Feedback       or