服务器可伸缩性 - HTML 5 websockets vs Comet [英] Server Scalability - HTML 5 websockets vs Comet

问题描述

许多像Caplin这样的Comet实现提供了服务器可伸缩的解决方案。

以下是来自 Caplin 网站：

Caplin解放器的单个实例最多可以支持100,000个客户端每秒消息的平均延迟小于7毫秒。

这是如何与任何网络服务器上的HTML5 websockets进行比较的？任何人都可以指向我的任何HTML 5 websockets统计信息？

解决方案

泄露 - 我为Caplin工作。 b

在这个页面上有一些错误信息，所以我想试着让它更清楚。

我想我们可以分割我们正在讨论的方法进入三个阵营。

1. Comet HTTP轮询 - 包括长轮询


2. Comet HTTP流 - 服务器到客户端消息使用单个持久套接字，初始设置后没有HTTP头开销


3. Comet WebSocket - 单双向套接字

我认为它们都是Comet，因为Comet只是一个范例，但是自从WebSocket出现以来，有些人想要对待它就像它不同或取代Comet - 但它只是另一种技术 - 除非你很高兴只支持最新的浏览器，那么你不能只依靠WebSocket。

就性能而言，m ost基准测试集中于服务器到客户端的消息 - 用户数量，每秒消息数量以及这些消息的延迟。对于这种情况，HTTP Streaming和WebSocket之间没有根本区别 - 两者都是在开放套接字上写消息，只有很少或没有标题或开销。

长轮询可以提供良好的信息如果消息的频率较低，则延迟。但是，如果您有两条消息（服务器到客户端）快速连续发送，那么第二条消息将不会到达客户端，直到收到第一条消息后发出新的请求。

我认为有人触及了HTTP KeepAlive。这显然可以提高长轮询 - 你仍然有往返和标题的开销，但并不总是创建套接字。

在WebSocket应该改进HTTP Streaming的情况下有更多的客户端到服务器消息。将这些场景与现实世界联系起来会产生一些更为随意的设置，与简单易懂的向许多客户端发送大量消息相比，每个人都可以理解。例如，在交易应用程序中，创建包含执行交易的用户（即客户端到服务器消息）的场景很容易，但结果比基本服务器到客户端场景的意义稍微有点低。交易者并没有试图做100次交易/秒 - 所以最终得出的结果是10000个用户每秒接收100条信息，同时每5分钟发送一次客户信息。客户端到服务器消息的更有趣的部分是延迟，因为与服务器到客户端消息相比，所需消息的数量通常是微不足道的。

有人做出的另一点以上，大约64k客户端，你不需要做任何聪明的事情来支持服务器上超过64k的套接字 - 除了配置数字文件描述符等。如果你试图从一台客户端机器做64k连接，那是完全的不同，因为他们需要每个端口号 - 在服务器端没问题，那就是监听端，你可以高于64k套接字。

Many Comet implementations like Caplin provide server scalable solutions.

Following is one of the statistics from Caplin site:

A single instance of Caplin liberator can support up to 100,000 clients each receiving 1 message per second with an average latency of less than 7ms.

How does this to compare to HTML5 websockets on any webserver? Can anyone point me to any HTML 5 websockets statistics?

解决方案

Disclosure - I work for Caplin.

There is a bit of misinformation on this page so I'd like to try and make it clearer..

I think we could split up the methods we are talking about into three camps..

1. Comet HTTP polling - including long polling
2. Comet HTTP streaming - server to client messages use a single persistent socket with no HTTP header overhead after initial setup
3. Comet WebSocket - single bidirectional socket

I see them all as Comet, since Comet is just a paradigm, but since WebSocket came along some people want to treat it like it is different or replaces Comet - but it is just another technique - and unless you are happy only supporting the latest browsers then you can't just rely on WebSocket.

As far as performance is concerned, most benchmarks concentrate on server to client messages - numbers of users, numbers of messages per second, and the latency of those messages. For this scenario there is no fundamental difference between HTTP Streaming and WebSocket - both are writing messages down an open socket with little or no header or overhead.

Long polling can give good latency if the frequency of messages is low. However, if you have two messages (server to client) in quick succession then the second one will not arrive at the client until a new request is made after the first message is received.

I think someone touched on HTTP KeepAlive. This can obviously improve Long polling - you still have the overhead of the roundtrip and headers, but not always the socket creation.

Where WebSocket should improve upon HTTP Streaming in scenarios where there are more client to server messages. Relating these scenarios to the real world creates slightly more arbitrary setups, compared to the simple to understand 'send lots of messages to lots of clients' which everyone can understand. For example, in a trading application, creating a scenario where you include users executing trades (ie client to server messages) is easy, but the results a bit less meaningful than the basic server to client scenarios. Traders are not trying to do 100 trades/sec - so you end up with results like '10000 users receiving 100 messages/sec while also sending a client message once every 5 minutes'. The more interesting part for the client to server message is the latency, since the number of messages required is usually insignificant compared to the server to client messages.

Another point someone made above, about 64k clients, You do not need to do anything clever to support more than 64k sockets on a server - other than configuring the number file descriptors etc. If you were trying to do 64k connection from a single client machine, that is totally different as they need a port number for each one - on the server end it is fine though, that is the listen end, and you can go above 64k sockets fine.

这篇关于服务器可伸缩性 - HTML 5 websockets vs Comet的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！