像Caplin这样的许多Comet实现都提供了服务器可扩展的解决方案。
以下是来自Caplin网站的统计信息之一：
Caplin解决方案的单个实例最多可支持100,000个客户端，每个客户端每秒接收1条消息，平均延迟小于7毫秒。
如何与任何网络服务器上的HTML5网页框进行比较？有人能指出任何HTML 5 websockets统计数据吗？
答案 0 :(得分：42)
披露 - 我为Caplin工作。
此页面上有一些错误信息，所以我想尝试让它更清晰..
我认为我们可以把我们谈论的方法分成三个阵营。
我认为它们都是Comet，因为Comet只是一个范例，但是自从WebSocket出现后，有些人想把它视为不同或者取代Comet - 但它只是另一种技术 - 除非你乐意只支持最新的浏览器，你不能只依靠WebSocket。
就性能而言，大多数基准测试都集中在服务器到客户端的消息上 - 用户数量，每秒消息数量以及这些消息的延迟。对于这种情况，HTTP Streaming和WebSocket之间没有根本区别 - 两者都是在开放式套接字上写入消息，只有很少或没有标头或开销。
如果消息的频率很低，长轮询可以提供良好的延迟。但是，如果快速连续有两条消息（服务器到客户端），则在收到第一条消息后发出新请求之前，第二条消息将不会到达客户端。
我认为有人触及了HTTP KeepAlive。这显然可以改善Long轮询 - 你仍然有往返和头文件的开销，但并不总是创建套接字。
在有更多客户端到服务器消息的情况下，WebSocket应该改进HTTP Streaming。将这些场景与现实世界联系起来会产生稍微更加随意的设置，与简单易懂的“向大量客户发送大量消息”相比，每个人都可以理解。例如，在交易应用程序中，创建包含执行交易的用户（即客户端到服务器消息）的场景很容易，但结果与基本服务器到客户端场景的意义不大。交易者不会尝试进行100次交易 - 因此您最终得到的结果是“10000个用户每秒接收100个消息，同时每5分钟发送一次客户端消息”。客户端到服务器消息的更有趣的部分是延迟，因为与服务器到客户端消息相比，所需的消息数量通常是无关紧要的。
上面提到的另一点，大约64k客户端，你不需要做任何聪明的事情来支持服务器上超过64k的套接字 - 除了配置数字文件描述符等。如果你试图从一个64k连接单个客户端机器，完全不同，因为它们需要每个端口号 - 在服务器端它很好，但是听取端，你可以超过64k套接字。
答案 1 :(得分：8)
理论上，WebSockets可以比HTTP更好地扩展，但也有一些警告和一些方法来解决这些警告。
HTTP与WebSockets的握手头处理的复杂性大致相同。 HTTP（和初始WebSocket）握手很容易超过1K的数据（由于cookie等）。重要的区别是HTTP握手再次发生每条消息。建立WebSocket连接后，每条消息的开销仅为2-14个字节。
@David Titarenco的答案（1，2）中发布的优秀Jetty基准链接表明，WebSockets在比较时可以轻松实现超过数量级更好的延迟彗星。
有关扩展WebSockets与HTTP的详细信息，请参阅this answer。
<强>注意事项：
与短连接的HTTP连接不同，WebSocket连接是长期存在的。这显着降低了开销（没有套接字创建和管理每个请求/响应），但它确实意味着要将服务器扩展到64k以上的单独的同时客户端主机，您将需要在同一服务器上使用多个IP地址等技巧。
由于Web中介的安全问题，浏览器到服务器WebSocket消息的所有有效负载数据都被屏蔽了XOR。这会为服务器增加一些CPU利用率来解码消息。但是，XOR是大多数CPU架构中最有效的操作之一，并且通常提供硬件辅助。服务器到浏览器的消息没有被屏蔽，因为WebSockets的许多使用不需要从浏览器发送到服务器的大量数据，这不是一个大问题。
答案 2 :(得分：6)
很难知道这与任何东西相比如何，因为我们不知道（平均）有效载荷大小有多大。在引擎盖下（就像服务器的实现方式一样），HTTP流和websockets实际上是相同的 - 除了初始握手，这显然是在使用HTTP时更复杂。
如果你用C（ala Caplin）编写自己的websocket服务器，你可能会毫不费力地达到这些数字。大多数websocket实现是通过现有的服务器包（如Jetty）完成的，因此比较实际上并不公平。
一些基准：
http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/
http://webtide.intalio.com/2011/08/prelim-cometd-websocket-benchmarks/
但是，如果你看一下C事件lib基准测试，比如libev和libevent，这些数字看起来更加性感：
http://libev.schmorp.de/bench.html
答案 3 :(得分：4)
忽略任何形式的轮询，如其他地方所述，在更新率较高时会引入延迟，这是JavaScript流式传输的三种最常用的技术：
WebSocket是迄今为止最干净的解决方案，但在浏览器和网络基础设施方面仍然存在问题，而不支持它。越早可以依靠它就越好。
XHR / XDR＆amp; Forever IFrame可以很好地从服务器向客户端推送数据，但需要各种黑客才能在所有浏览器中一致地工作。根据我的经验，这些Comet方法总是比WebSockets慢一点，因为需要更多客户端JavaScript代码才能使其工作 - 从服务器的角度来看，通过线路发送数据的速度相同。
以下是我们的产品WebSocket benchmark graphs的更多my-Channels Nirvana。
跳过多播和二进制数据图表到页面上的最后一个图表（JavaScript高更新率）
总结 - 结果显示Nirvana WebSocket向2,500k用户提供50个事件/秒，延迟为800微秒。在5,000个用户（总流量为250k事件/秒）中，延迟为2毫秒。