On Mon, 2011-10-10 at 22:34 +1100, Greg Wilkins wrote:
> If you look at the results we have got with jetty+cometd of HTTP vs
> Websockets:
>
>
> http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/
>
> You will see that we already have gone way beyond scalability parity
> with HTTP, even with a blocking API for websockets.
Ok, so this test is about the old comet model in your specific
implementation, placed in an ideal usage scenario. Nice, but how is this
relevant ?
The main problem is that without non blocking controls on output, your
websocket server can be easily taken down by a handful of slow clients.
Either because it uses a single thread to send data back (it would
become unresponsive), or because the unwritten data will need to be
fully buffered across all clients (it would OOM). This is actually a DoS
class security issue for any application that needs to send back
sizeable amounts of data.
BTW, I also continue to believe having control over frames is useful,
but this is not the place to discuss this.
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc