Comet techniques are advocated when your application needs low latency events to be delivered from the server to the browser. Comet can deliver sub-second latency for messages making possible web applications like chat, games and real-time monitoring of prices and states.

It is often asserted that for applications that don’t need low latency (e.g. email readers), traditional polling is a better alternative. However, some rudimentary analysis shows this assertion to be wrong, and that Comet techniques can be applied to all required latencies and event rates to provide improved data rates and average latencies.

For this analysis, I have considered polling vs. the long-polling technique where a server may hold a poll request for a period of time while waiting for events/messages to be delivered to the browser. In order to ensure that we are comparing apples with apples and oranges with oranges, I have compared configurations that provide the same maximum latency. For example, for a maximum latency of 10s, the polling technique must issue a poll every 10s and the average latency is half that. For the Comet technique long polling, a long poll needs to be issued 10s after the last long poll completes, but the server may hold the long poll for up to 300s while waiting for an event.

The attached spreadsheet contains the calculations, which I have graphed for 1s, 10s and 100s maximum latency for message rates of 1, 10, 100 and 1000 messages per second for 1000 users. The results show that the Comet long polling technique uses less bandwidth than polling in all situations, and uses significantly less bandwidth when the average period between messages is longer than the maximum latency:

Not only does Comet long-polling provide superior data rates, it also provides superior average latency. The Comet technique allows the average latency to be lower than the maximum latency because once the pause between polls is complete, the long poll is ready to respond immediately to events.

This analysis shows that for the worst case, when the message rate is high, load and latency for Comet long-polling are identical to traditional polling, and for most cases the load and latency are significantly better than traditional polling.

The calculations for these graphs are in this Comet vs Polling spreadsheet. The assumptions made are that all messages are equal in size (150Bytes) and that the message arrival times are randomly but uniformly distributed. A maximum long poll timeout of 240s is assumed. The Y axis of the graphs is logarithmic so larger differences appear smaller.

17 Responses to “Comet is Always Better Than Polling”

[...] have at explaining the value of Comet for building low-latency interactions. Greg Wilkins has an excellent post outlining the load and latency benefits of going with a Comet server vs. traditional [...]

This is interesting information about how polling and Comet compare, but it seems like a missing component in this analysis is how many clients at a time the server (even just what your sever with it’s specs) can handle. If a Comet server falls over at lets say 1000 clients then for some use cases it won’t make sense, but for others it would. Can you point to any test(s) that take into account multiple clients using a comparison similar to the one outlined in this article (ideally using a variety of client load from the tens through hundreds and thousands even through tens of thousands)?

I find it probable that your research is wrong, however to say that “Comet is always better” is like saying; “A car is better than a bike”…
Comet for one requires at least a “billion” times the resources for your server not to mention that it breaks the HTTP standards if you want it to actually _work_ (due to the 2 connections per IP towards the same server thing)
I love Comet form a conceptually viewpoint but I think it’ll end up just like the flying car did; everybody wants one, but no one can make one without bending over backwards fifty four times the speed of light. (or unless their name starts with G and ends with oogle…

OK the “always better” claim is an attention grabbing headline and I agree it is a bit much to claim. But in the scope of the article, which is about data rates and latency, I think I show that long polling at worst case can fall back to be just normal polling, and thus can always equal polling for data rate and latency and often better it.

With regards to you comments about breaking 2 connection limits, server resources and breaking the rules of HTTP - I don’t disagree that some (many?) comet implementations do these things.
But they all can be addressed:

+ long polling (unlike forever frame) comet does not break the rules of HTTP as a fully formed and complete response is sent for every event.

+ Using Asynchronous techniques on the server will bring the resources needed to around the
same order of magnitude as web-1.0 applications.

+ The two connection limit is difficult, but with some work it can be dealt with reasonably today (by detecting multiple long-polls and falling back to polling or telling the user) and should be able to be well resolved in future with the work of the openAjax alliance.

@Greg
Thank you for a detailed reply on my comment, it’s nice to see there still exists grownups around even in the comment fields of blogs …
I agree in that Comet doesn’t really break the rules of HTTP, and also to some extent also the Asynchronous parts of your comment. Though I still think that the most important reason as to why HTTP and HTML “took off” was due to the very features of that it was a “disconnected protocol” and therefore took really small amount of resources on the server. To some extent Asynchronous efforts on WebServers will fix this and actually have for Asynchronous Pages for ASP.NET, but far from “all the way” since the very nature of a constantly connected client relies on larger resources on the server by itself. The two connections thing will probably get solved, but until it has been solved _several years ago_ (meaning earliest in 2-4 years if it were to be solved _TODAY_) it’s still going to haunt us due to old browsers and such…
(Not to mention IE which has no intention what-so-ever to support _anything_ that’ll create a “better web” for our children)
Also I think there are not that many applications that require Comet, sure you have chatting systems and other systems where you require “instant communication” but I think that probably the largest market for Comet will not be public applications but rather Enterprise Systems using Comet for e.g. WebServices or that can force it’s users into changing the settings for the browser and so on…
I have in fact implemented Comet a couple of times and the only time I did so with the intention of creating something that was not “throw away code” and I succeeded to get production code out of Comet was for a Pocket PC Client using WinForms (smart client) and WebServices (**!**) to get Comet support…!
At least for the next 2-5 years I wouldn’t dream about implementing it for a public website expecting large user base to hit my servers…

(A drawback may be if you already have many subdomains for your site, there could be a small delay in this extra DNS lookup, and I think Yahoo’s performance team has written that there should be a trade off on how many DNS lookups you do, suggesting 4 to 6 seems optimal.)

[...] Why do we need Orbited? With our existing arrangement (once we install Ejabberd and xmpp4r gem) we could get a basic messaging system ready. We could have users send messages and receive messages. The problem would be to receive those messages on the browser. There is no way we can display those messages without having to poll our server to fetch this information and we know polling could cause scalability issues. Orbited fills this void by acting as a web router that routes the incoming messages to the appropriate user’s browser using a technique called as long-polling. And long-polling is more scalable than polling. [...]

Im using comet tomcat java ajax call for server push.
problem is the browser is continously making ajax call.
whether server pushes fresher data or not.
i want the browser make a fresh call only if server pushes new data.if not so browser should not make any call to server.please helpme. im using this link for poc http://www.ibm.com/developerworks/web/library/wa-cometjava/

Recent Musings

NASA's Undergraduate Student Research Program recently published an interesting paper by Matthew Noyes and Robert Hirsh: Rendering Flight Telemetry in Platform-Independent Three-Dimensional Touch-Interactive Simulations.

The new major release of Lightstreamer, codenamed Duomo, is now generally available. The package includes version 4.0 of Lightstreamer Server, and updated versions for all the client SDKs, plus brand new client SDKs for mobile platforms.