服务器可扩展性 - HTML 5 websockets 与 Comet [英] Server Scalability - HTML 5 websockets vs Comet
问题描述
Caplin 等许多 Comet 实现提供服务器可扩展解决方案.
Many Comet implementations like Caplin provide server scalable solutions.
以下是来自 Caplin 站点的统计数据之一:
Following is one of the statistics from Caplin site:
Caplin liberator 的单个实例最多可支持 100,000 个客户端，每个客户端每秒接收 1 条消息，平均延迟小于 7 毫秒.
这与任何网络服务器上的 HTML5 websockets 相比如何?谁能告诉我任何 HTML 5 websockets 统计数据?
How does this to compare to HTML5 websockets on any webserver? Can anyone point me to any HTML 5 websockets statistics?
推荐答案
披露 - 我为 Caplin 工作.
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..
- Comet HTTP 轮询 - 包括长轮询
- Comet HTTP 流媒体 - 服务器到客户端的消息使用单个持久套接字，初始设置后没有 HTTP 标头开销
- Comet WebSocket - 单双向套接字
我把它们都看作 Comet，因为 Comet 只是一个范式，但是自从 WebSocket 出现以来，有些人想把它当作不同的东西来对待或取代 Comet——但这只是另一种技术——除非你很高兴只支持最新的浏览器，那么你不能仅仅依赖 WebSocket.
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.
就性能而言，大多数基准测试都集中在服务器到客户端的消息上——用户数量、每秒消息数量以及这些消息的延迟.对于这种情况，HTTP Streaming 和 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.
我认为有人触及了 HTTP KeepAlive.这显然可以改善长轮询 - 您仍然有往返和标头的开销，但并不总是套接字创建.
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.
在有更多客户端到服务器消息的场景中，WebSocket 应该改进 HTTP Streaming 的地方.与每个人都可以理解的简单易懂的向许多客户端发送大量消息"相比，将这些场景与现实世界相关联会创建更随意的设置.例如，在一个交易应用程序中，创建一个包含用户执行交易的场景(即客户端到服务器消息)很容易，但结果的意义比基本的服务器到客户端场景要少一些.交易者不会尝试每秒进行 100 次交易 - 因此您最终会得到类似10000 个用户每秒接收 100 条消息，同时每 5 分钟发送一次客户端消息"这样的结果.客户端到服务器消息更有趣的部分是延迟，因为与服务器到客户端消息相比，所需的消息数量通常微不足道.
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.
上面有人提出的另一点，关于 64k 客户端，你不需要做任何聪明的事情来支持服务器上超过 64k 的套接字 - 除了配置数字文件描述符等.如果你试图从一个单个客户端机器，这是完全不同的，因为每个客户端都需要一个端口号 - 在服务器端它很好，那是监听端，你可以超过 64k 套接字.
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 与 Comet的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
