以下是Caplin网站的统计数据之一：
Caplin解放器的单个实例可以支持多达100,000个客户端，每个客户端每秒接收1个消息，平均延迟小于7ms。
如何与任何Web服务器上的HTML5 websockets进行比较？任何人都可以点我任何HTML 5 websockets统计数据？
解决方法
在这个页面上有一些错误的信息，所以我想尝试，使它更清楚。
我想我们可以把我们谈论的方法分成三个阵营。
> Comet HTTP轮询 – 包括长轮询
> Comet HTTP流 – 服务器到客户端消息使用单个持久套接字，初始设置后没有HTTP头开销
> Comet WebSocket – 单双向插座
我看到他们所有的彗星，因为彗星只是一个范例，但自从WebSocket一些人想要对待它，因为它是不同的或替换彗星 – 但它只是另一种技术 – 除非你只是支持最新的浏览器那么你不能只依靠WebSocket。
就性能而言，大多数基准测试集中在服务器到客户端消息 – 用户数量，每秒消息数量和这些消息的延迟。对于这种情况，HTTP Streaming和WebSocket之间没有根本的区别 – 两者都是在一个打开的套接字上写入消息，只有很少或没有头或开销。
如果消息的频率低，长轮询可以给出良好的延迟。但是，如果您快速连续地有两个消息(服务器到客户端)，那么第二个消息将不会到达客户端，直到在接收到第一个消息后发出新的请求。
我认为有人触及HTTP KeepAlive。这显然可以改善长轮询 – 您仍然有往返和头的开销，但不总是套接字创建。
其中WebSocket应该在有更多客户端到服务器消息的情况下改进HTTP流传输。将这些场景与真实世界相关联，创建了稍微更多的任意设置，相比之下，简单地理解“向许多客户端发送大量消息”，每个人都可以理解。例如，在交易应用程序中，创建包含执行交易的用户(即客户端到服务器消息)的场景很容易，但是结果远比基本的服务器到客户端场景有意义。交易者没有尝试做100次交易/秒 – 所以你最终得到的结果像’10000用户接收100个消息/秒，同时还发送客户端消息每5分钟一次。客户端到服务器消息的更有趣的部分是延迟，因为与服务器到客户端消息相比，所需消息的数量通常是微不足道的。
上面的另一个点，大约64k客户端，你不需要做任何聪明的支持服务器上的超过64k套接字 – 除了配置数字文件描述符等。如果你试图从单个客户端机器64k连接，这是完全不同的，因为他们需要一个端口号为每一个 – 在服务器端很好，虽然，这是听端，你可以超过64k套接字罚款。