将 WebSocket 移入工作线程的原因 [关闭]

Posted

技术标签:

【中文标题】将 WebSocket 移入工作线程的原因 [关闭]【英文标题】:Reasons to move the WebSockets into a Worker Thread [closed] 【发布时间】:2012-09-21 16:38:32 【问题描述】:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

那么最佳做法是什么?

【问题讨论】:

【参考方案1】:

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

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

【讨论】:

【参考方案2】:

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

【讨论】:

以上是关于将 WebSocket 移入工作线程的原因 [关闭]的主要内容,如果未能解决你的问题,请参考以下文章

django uwsgi websocket请即时关闭负线程

关闭旧的 php websocket

为啥我会收到“WebSocket 连接已关闭:代码 = 1000(OK),没有原因”

Websocket:是不是可以从程序中知道调用 onClose 的原因是啥

WebSocket - 关闭握手 Gorilla

mfc 关闭阻塞的socket监听线程 select怎么用