将WebSockets移动到工作线程的原因

Question

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

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

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

我对服务器必须发送很多的高负载情况特别感兴趣 向客户发送事件，以反映实时更新。我希望GUI能够完全响应，并以实时用户体验在网格和图表中显示数据。

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

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

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

据我所知，WebSocket是异步的，不会阻塞。我读到了某个地方 它在浏览器内部的线程中实现，这是有道理的。

我考虑将WebSocket移动到一个worker中，允许worker在将其移动到主窗口之前缓冲或聚合一些数据。如果事件率很高，我会看到以下方法：

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

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

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

工作线程的另一个问题似乎是数据重复，可以通过较新的可转移对象解决，不确定它在所有浏览器上的支持程度。

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

那么最佳做法是什么？

Answer 1

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

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

Answer 2

DOM操作以及可能在画布上绘制也会影响websocket包。我在localhost上平均测量了0.2ms的平均延迟，但是使用同一线程，我有固定间隔的4-9ms峰值。如果我不更新频繁访问的DOM或将WebSocket移至工作程序，它们就会消失。从这个角度来看，Chrome受影响最大，Firefox更好。对于在线游戏，这可能意味着某种滞后或停顿。对我来说，它只是稍微影响TCP延迟测试。我需要将邮件发送频率从1ms增加到100ms，以获得清晰的图表。