我们正在实施一项服务,许多用户同时使用该服务.在峰值,我们可以在网上有成千上万的人.

我们服务的关键部分需要重新实现,因此我们尝试考虑新的方法.目前,我们根据用户交互发送简单且非常短/小的AJAX HTTP请求：

>平：我还活跃
>活动：我已经这样做了,请把它写到数据库中
>完成：我已经完成了我的活动,所以请关闭我的要求

同时,在某些情况下(十分之一)我们打开了EventSource,我们从中读取了服务器上的一些修改.

问题是这个模型是否足够好,或者是否更好地打开WebSocket并通过WebSocket传递所有内容.

>优势 – 对于每个用户,我们只维护一个连接而不是发送多个请求.
>缺点 – 当很多人在线时,我们会保持数千个连接活跃

正确实施的决定应该是什么？

有人指出,这个问题答案相同：WebSockets protocol vs HTTP – 但我要求具体的用例.一般而言,相关的问题是有问题的.

最佳答案

• Disadvantage – when lots of people online, we would keep thousands of connections active

您可以实现服务以在超时后关闭空闲websocket连接.这可能与EventSource为您工作的方式相同,因此您不会保留太多活动连接. (类似的性能特征.)

(但如果您依赖于浏览器提供的EventSource的自动重新连接,那么切换到WebSocket意味着您需要为重新连接的逻辑编写更多代码.)

通常,WebSocket应该具有较少的网络流量开销.但是,差异取决于当前服务的实施方式.如果您已经优化了逻辑并使用AJAX和EventSource挤出了所有性能,那么使用WebSocket可能是一个微不足道的改进.