Re: [hybi] Call for interest: multiplexing dedicated for WebSocket

[Simone Bordet <[e-mail]>]

Hi,

>>> On Wed, May 22, 2013 at 1:32 PM, John A. Tamplin <[e-mail]> wrote:
>>> Servers don't handle tons of long-lived connections very well
>>
>> On 22/05/2013 12:00 PM, Zhong Yu wrote:
>> Is that still true today? Recent server implementations all boast they can handle tons of connections.
>
>On Wed, May 22, 2013 at 9:31 PM, Bruce Atherton <[e-mail]> wrote:
> Tons of short, HTTP Request/Response type connections. John is talking about long-lived WebSockets connections, the kind that might hang around for days, weeks, even months. It is a different problem.

Well I am not sure.
I have seen the TCP Linux stack collapsing due to usage of HTTP 1.0 by
a proxy. Opening and closing connections at a high rate it's a killer.
Long lived connections, on the other hand, not so problematic, at
least in my experience, so Zhong Yu's question still stand for me.

Another point not addressed by the article linked by Tobias is the
type of usage of the protocol.
The HTTP protocol has a typical 1 request followed by 10-200 requests
in a burst, that can be performed concurrently.
In a non-mux protocol (like HTTP/1.1) browsers open 6 connections, so
to serve the burst you need multiple "passes" at using those 6
connections, which leads to the well known ziggurat profile: 6 out,
pause, 6 out, pause, etc.
In SPDY, which is muxed, the 100 requests go out at once, with a flat profile.
Roberto Peon and us (Jetty) have showed demos where this effect is
*eye visible*. SPDY is faster than HTTP just because of mux
(http://webtide.intalio.com/2012/10/spdy-push-demo-from-javaone-2012/).

Now, HTTP has a semantic which benefits clearly from multiplexing.
Does this hold true for WebSocket, which does not have semantic, but
just framing ? I think it depends.
If you use WebSocket to transport HTTP (i.e. the opposite that
HTTP/2.0 is working on) then perhaps mux would be very important.
But if you use WebSocket for chat messaging, perhaps that's not that
important to have mux.
The difference here is between a request/response model versus a
messaging model.
The model changes the need for mux.

Since WebSocket does not define a model (just framing), perhaps mux is
less important.
Application protocols may implement mux if they need to.

> Think of it this way. Say your server can handle 10K simultaneous connections to serve web pages and it takes about 330ms to serve them.
> If every one of those opens a websocket connection, you'll need 30K WebSocket connections just to handle a single second of traffic.
> If on average the page is kept open for only an hour, that is 108M connections.

That's under the assumption that WebSocket connections are closed
after a "request", which is wrong.
WebSocket connections are persistent.
If you want to serve HTTP resources via WebSocket, you better open 1
connection per client (like SPDY does), and your server will only be
able to handle 10k clients at any time.
But then you'll need mux, or you go back to HTTP/1.1, just with a
different framing (WebSocket).

--
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.