20,000 Reasons that Comet Scales

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.

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.