Monday, January 7th, 2008

20,000 Reasons that Comet Scales

Category: Comet

Greg Wilkins is marching a long with better and more performant Comet support as shown in his piece 20,000 Reasons Why Comet Scales:

After some recent optimizations, the Dojo Cometd implementation of the Bayeux protocol running on the Jetty web server can now handle up to 20,000 simultaneous users per server while maintaining sub-second latency.

20000 Reasons Comet Scales

This was done on “mid-sized Amazon EC2 virtual servers: 7.5 GB of memory, 2×2 EC2 Compute Units, 64-bit platform running Ubuntu 7.10 and Sun JVM 1.5.0_13. A single virtual machine was used as the Cometd server and between 1 and 3 virtual machines were used to generate the load of 20,000 clients.”

Zimbra recently posted about how they switched to Jetty and why continuations was a major reason:

Jetty uses the Continuation pattern to suspend a blocked polling request and free the worker thread. By using Continuation, Jetty keeps impact on existing Web applications and Servlet related technologies to a minimum. Applications written according to the current Servlet specs can take advantage of Comet with trivial changes, and the Continuation mechanism for suspending and resuming of a request is most straightforward. Although Continuation is hardly the only way to implement Comet support, it’s worth noting that other approaches typically will require writing asynchronous code at the application level which carries a signification application development cost.

In summary, we chose Jetty not only because it supports Comet in a scalable manner, but also because the Continuation implementation of Comet is least disruptive to existing Servlet based technologies.

Posted by Dion Almaer at 2:14 pm

4 rating from 23 votes


Comments feed TrackBack URI

great information. Many thanks.

…if building a Comet server from scratch (i.e. not scaling up as seems to be the use-case here) is it fair to say that there is a sweet spot for Erlang-based Comet implementations?… would think Erlang inherently solves some of these concurrency items.


Comment by Mark Holton — January 7, 2008

@Mark Holton:
I agree. Also Scala’s Actors are a good choice for Comet.

Comment by andytesti — January 7, 2008

Great, so now we only need 50 times as many servers to run COMET compared to traditional request/response apps… ;)

Comment by Thomas Hansen — January 7, 2008


While some some web-1.0 apps can achieve more than 20,000 users per node in a cluster, your 50x is a bit of an exaggeration. Can you tell me any server that can have 1,000,000 simultaneous users? Besides if you have a webapp with 1,000,000 simultaneous users, then you probably can afford to buy a few more servers.

So while comet applications probably do require larger server farms, on these numbers the growth is certainly not 50x, 10x or even 2x. If you can create the killer app in your field that grows your market and your share in it, then it may well be worth a few extra servers!

Note: The diagram above has been cropped, so you can’t see the 20,000 connections response. Click through to the article to see the full diagram.

Comment by Greg Wilkins — January 7, 2008

You’re off course right and I was exaggerating as you say, still scaling still is a problem all though it’s due to new threading architecture in newer web servers a SMALLER problem. It still IS a problem. And Comet has other problems too in addition. The very beauty of HTTP was the response/request thing which made it not only extremely easy to use but also user friendly and very scaling. If you took an “average application” and wanted to create it into a Comet application you would first of all have to increase the complexity of the app by magnitudes. Second of all you would have to increase the amount of web servers too a LOT. Though maybe not by 50, but still a VERY high number.
The last time Ajaxian had something about Comet I wrote a blog about it in fact to explain my views, read up on it here

Comment by Thomas Hansen — January 8, 2008

There’s already a COMET-like implementation for Erlang. It’s called mod_http_bind and it’s a module for Ejabberd implementing BOSH over XMPP (formerly called HTTP Binding).

Comment by zeank — January 8, 2008

You’re right that the beauty in HTTP is the response/request simplicity and Comet is pushing things in a direction not intended by the spec. But similarly Ajax is doing the same thing with JavaScript and HTML so you are probably on the wrong website.

We don’t use Ajax and Comet because they are cool new technologies but because they provide the users of our applications with a much better experience. Sometimes it makes sense to make things a bit more complex on the server to make the app easier to use.

Also, you probably wouldn’t convert an “average application” to a Comet application. You use Comet to improve performance of an event based application because the alternative, polling with regular Ajax, doesn’t perform well. If you need an event based application in a browser, with the exception of a plug in, you don’t have another option.

Comment by RyanDewsbury — January 8, 2008


there is nothing in long polling comet that is against the HTTP spec. It is all completely legal. There are other comet techniques that do push the boundaries, but long polling as used by Cometd/Bayeux (and BOSH) is not one of them.

If comet lets you grow your business or create new ones, then it is probably worth some growth in your server farm. I dispute your suggestion that is is a VERY large increase.

Comment by Greg Wilkins — January 8, 2008

Leave a comment

You must be logged in to post a comment.