by Martin TylerDecember 13th, 2007

Bandwidth is very important when a website is serving a large number of users, as small changes can have a big effect.

To cover some old ground on Ajax and Comet: depending on the site/application, these techniques can lower the bandwidth used. For a site that has frequently updating data, such as a sports website, the traditional method of the page refreshing can be a huge waste of bandwidth.

For low scoring sports, you could be refreshing the page every 30 seconds just to see 1 or 2 changes in an hour. Obviously if the page hasn’t changed and attention has been paid to caching, you only have the overhead of the HTTP request and response headers. In this low scoring sport example using Ajax techniques to poll a server doesn’t help, because you still have the HTTP headers overhead. However, in a sport where things are happening all the time, or another application which updates faster, and each poll to the server fetches new data, the Ajax technique will help a lot since you will just be getting the updated information rather than the whole page each time.

Going to the next level we have Comet. Long polling transports will not help much with the slow updating site if the same poll period is used since you still have the HTTP header overheads. However, you will get your updates as soon as they happen, which means longer poll times can be used and therefore lower bandwidth. Full streaming transports mean only the updated data is sent, so this is the best solution with regards to bandwidth.

Those are the basics, but there is more. When the site/application in question is sending lots of small updates, which is common in financial applications, the protocol used can have a significant effect on the overall bandwidth usage. When a Comet message is sent to a client it usually contains some data that is application specific, the payload, and some other data which wraps this up in a way for the client to understand what it is, e.g. a message type, a channel name etc. When the payload is fairly small for each update the header information becomes a significant part of the overall size of the message.

Making a Comet protocol less verbose can make it less readable and often harder to debug, but for some applications every byte counts. Some of the solutions that have looked at this, such as Caplin Liberator, are very bandwidth friendly. There are a number of things that can be done, for example:

  • Not sending the channel name on each update, instead a much shorter id is assigned at subscription time.
  • Using short codes for message types instead of longer strings.
  • Having built in data types for commonly used structures. This means sending field names can be avoided in a field/value based payload.

When it comes to applications with a high frequency of small payload updates to a large number of users, every byte counts!

Comments are closed.

Copyright 2015 Comet Daily, LLC. All Rights Reserved