websocket实现的性能比较
Performance comparison of websocket implementations
编辑： 为了防止关闭这个问题，我将把它缩小到基本问题。
Can someone share a performance test in MB/s between the two websocket implementations listed below? Application or hardware details are irrelevant, just two crude numbers for a simple common scenario will suffice.
原题
是否有人针对 node.js 测试了这两个 websocket 实现的性能？
我找不到最近的任何内容（只有 2012-2013 年的一堆文章）。我想看到的是：
- 开销（如果有的话，考虑到实际的 网络 延迟更相关，我猜它们都收敛到 0）
- 吞吐量（相同 application/hardware 的简单 MB/S 数字会很棒）
- ws 真的可以 广播 网络级别的数据（尽管有底层 TCP？这完全可能吗？）或者它是只是一个被滥用的方法名称（它实际上在
for() 循环中向许多客户端发送相同的消息）？
更好：
- with/without Nagle 算法的比较
- JSON 与二进制消息的比较
编辑：更新了有关更新、更快实施的信息
我在这里整合 NiCk Newman 的 2016 年 6 月 17 日在 20:08 的评论以避免它丢失任何方式。
更新更快的 websockets 实现是 uWS。一些开发人员报告了有希望的结果。对于简单的情况，这几乎是显而易见的。因此，下面的讨论在某种程度上被取代了。
我想知道为什么没人能回答这个问题。因此，经过更多小时的搜索之后，我终于来到了这个给出了一些答案的页面。
我post在这里回答我自己的问题，以便其他人搜索它更容易。
页面是benchmark comparison of ws。是的，它非常简单，但不知何故被掩埋了。
相关结果如下：
在我的例子中，我想发送 4-16KB JSON 的消息（即使 4KB 也有点夸张，大多数消息只有 100-200 个字符）。第一张图显示，对于高达 64KB 的数据，根本没有明显的差异。仅对于较大的消息（大约 16MB），ws 比 websocket-node 更快变得越来越明显。
对于二进制消息，两者是相同的（如果不相同的话）。这让我想知道他们是否以某种方式在 GitHub 上互相借用了代码。顺便说一句，这很好，因为 GitHub 上的 ARE 可以共享和分叉等等。
下图显示了消息碎片，这与流式传输有关，但我对此不感兴趣。所以以上回答了我的问题：
- performance is identical for non-fragmented text messages (up to 16MB)
- performance is identical for non-fragmented binary messages (no size limit)
编辑： 为了防止关闭这个问题，我将把它缩小到基本问题。
Can someone share a performance test in MB/s between the two websocket implementations listed below? Application or hardware details are irrelevant, just two crude numbers for a simple common scenario will suffice.
原题
是否有人针对 node.js 测试了这两个 websocket 实现的性能？
我找不到最近的任何内容（只有 2012-2013 年的一堆文章）。我想看到的是：
- 开销（如果有的话，考虑到实际的 网络 延迟更相关，我猜它们都收敛到 0）
- 吞吐量（相同 application/hardware 的简单 MB/S 数字会很棒）
- ws 真的可以 广播 网络级别的数据（尽管有底层 TCP？这完全可能吗？）或者它是只是一个被滥用的方法名称（它实际上在
for()循环中向许多客户端发送相同的消息）？
更好：
- with/without Nagle 算法的比较
- JSON 与二进制消息的比较
编辑：更新了有关更新、更快实施的信息
我在这里整合 NiCk Newman 的 2016 年 6 月 17 日在 20:08 的评论以避免它丢失任何方式。
更新更快的 websockets 实现是 uWS。一些开发人员报告了有希望的结果。对于简单的情况，这几乎是显而易见的。因此，下面的讨论在某种程度上被取代了。
我想知道为什么没人能回答这个问题。因此，经过更多小时的搜索之后，我终于来到了这个给出了一些答案的页面。
我post在这里回答我自己的问题，以便其他人搜索它更容易。
页面是benchmark comparison of ws。是的，它非常简单，但不知何故被掩埋了。
相关结果如下：
在我的例子中，我想发送 4-16KB JSON 的消息（即使 4KB 也有点夸张，大多数消息只有 100-200 个字符）。第一张图显示，对于高达 64KB 的数据，根本没有明显的差异。仅对于较大的消息（大约 16MB），ws 比 websocket-node 更快变得越来越明显。
对于二进制消息，两者是相同的（如果不相同的话）。这让我想知道他们是否以某种方式在 GitHub 上互相借用了代码。顺便说一句，这很好，因为 GitHub 上的 ARE 可以共享和分叉等等。
下图显示了消息碎片，这与流式传输有关，但我对此不感兴趣。所以以上回答了我的问题：
- performance is identical for non-fragmented text messages (up to 16MB)
- performance is identical for non-fragmented binary messages (no size limit)