将 WebSocket 移至工作线程的原因

Question

我正在使用 WebSockets 运行一些测试。

对于测试，我使用了基于 Alchemy-Websockets .NET 的服务器。

Web 应用程序打开多个窗口，用于监视不同的服务和系统。

我对高负载情况特别感兴趣，在这种情况下，服务器必须向客户端发送大量事件，以反映实时更新。我希望 GUI 能够完全响应并在实时用户体验中以网格和图表形式呈现数据。

我在主窗口线程中创建了 WebSocket，并在每条传入消息上添加了一个条目到网格用于显示的数组 (SlickGrid)。为了使 GUI 正常工作，我添加了 20ms 的 setInterval 来渲染网格更新，一切都工作正常，速度非常快。

问题是是否需要或建议将 WebSocket 移至工作线程。在阅读有关工作线程的内容时，我在用例中看到了在线程中处理 I/O 的建议。

我认为只有在阻塞时这才有意义。

据我所知WebSocket是异步的并且不会阻塞。我在某处读到它是由浏览器内部的线程实现的，这是有道理的。

我考虑将 WebSocket 移动到工作线程中，允许工作线程在将数据移动到主窗口之前缓冲或聚合一些数据，如果事件发生率较高，我会看到以下方法：

1. 主窗口线程定期（每 20 毫秒左右）轮询工作线程并获取所需的数据。
2. 工作线程定期发送更大的数据块。
3. 每次网络套接字接收数据时，都会将其发送到主线程 - 但我认为它会引入相同的固有问题。（这是我开始测试的地方，我在工作线程中创建了一个无限循环，并且在每一步中我都向主线程发送一条消息，GUI 冻结了，这是有道理的）。

将 WebSocket 留在主线程上也并不理想。如果服务器负载较高，GUI 将不会优先考虑 WebSocket 传入消息事件。

在工作线程中收集数据，似乎我可能会错过高负载期间的实时更新，因为工作线程正在缓冲。

工作线程的另一个问题似乎是数据重复，这可以通过较新的可传输对象来解决，但不确定所有浏览器对它的支持程度如何。

为什么不在主窗口上托管 WebSocket？

那么最佳实践是什么？

Answer 1

将 WebSocket 迁移到 Worker 只有两个原因。

• JSON.parse 是阻塞操作，在大数据情况下可能会导致 FPS 损失。从工作线程克隆数据会增加约 1% 的开销，但 99% 的解析是在后台线程中完成的。
• 使用 SharedWorker 只维护与服务器的一个连接。