Comments on: 20,000 Reasons that Comet Scales

By: Greg Wilkins

Greg Wilkins — Wed, 09 Jan 2008 01:44:46 +0000

Thomas,

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.

By: RyanDewsbury

RyanDewsbury — Tue, 08 Jan 2008 15:01:29 +0000

@Thomas
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.

By: zeank

zeank — Tue, 08 Jan 2008 07:38:24 +0000

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).

By: Thomas Hansen

Thomas Hansen — Tue, 08 Jan 2008 06:50:44 +0000

@Greg
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

By: Greg Wilkins

Greg Wilkins — Mon, 07 Jan 2008 23:00:50 +0000

Thomas,

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.

By: Thomas Hansen

Thomas Hansen — Mon, 07 Jan 2008 22:20:35 +0000

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

By: andytesti

andytesti — Mon, 07 Jan 2008 21:47:52 +0000

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

By: Mark Holton

Mark Holton — Mon, 07 Jan 2008 21:35:14 +0000

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.

cheers