4

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

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

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

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

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

问题是将 WebSocket 移动到工作线程是可取的还是推荐的。阅读有关工作线程的信息，我在用例中看到了在线程中处理 I/O 的建议。

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

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

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

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

将 WebSocket 留在主线程上也不理想。在来自服务器的高负载的情况下，GUI 不会优先考虑 WebSocket 传入消息事件。

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

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

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

那么最佳实践是什么？

4

2 回答 2

1

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

  • JSON.parse 是阻塞操作，在大数据的情况下会导致 FPS 丢失。从 worker 克隆数据会增加约 1% 的开销，但 99% 的解析是在后台线程中完成的。
  • 使用 SharedWorker 只与服务器保持一个连接。
于 2014-12-23T10:27:50.570 回答
0

DOM 操作和可能在画布上绘图也会影响 websocket 包。我在 localhost 上测量了大约 0.2 毫秒的平均延迟，但使用相同的线程我会定期出现 4-9 毫秒的峰值。如果我不更新频繁的 DOM 或将 websocket 移动到工作人员，它们就会消失。Chrome 受到的影响最大，目前从这个角度来看，Firefox 更好。对于在线游戏，这可能意味着某种滞后或口吃。对我来说，它只是在一定程度上影响了 TCP 延迟测试。我需要将消息发送频率从 1 毫秒提高到 100 毫秒才能获得干净的图表。

于 2020-04-14T14:13:53.513 回答