我们控制客户端每 2 秒通过不同主题的扩散向客户端发送 100 个更新,每个大小为 200-250 字节(每个主题在 2 秒内更新一次)。问题是在发送这些大约 20-30 分钟后,流量控制开始,并且由于流量控制,更新在 1-2 小时后从 5 毫秒延迟到 100 毫秒。有什么方法可以避免在扩散中发布 Control Client 的流量控制?
maxqueuesize 设置为 10000 扩散 api 日志:压力 = 0.04622500000000004 => 睡眠 4 毫秒
我们控制客户端每 2 秒通过不同主题的扩散向客户端发送 100 个更新,每个大小为 200-250 字节(每个主题在 2 秒内更新一次)。问题是在发送这些大约 20-30 分钟后,流量控制开始,并且由于流量控制,更新在 1-2 小时后从 5 毫秒延迟到 100 毫秒。有什么方法可以避免在扩散中发布 Control Client 的流量控制?
maxqueuesize 设置为 10000 扩散 api 日志:压力 = 0.04622500000000004 => 睡眠 4 毫秒
流控制在 v5.1 中引入 Java 客户端,在 v5.5 中引入 .NET 客户端。它的存在是为了防止内部队列溢出,否则会关闭客户端会话。这是一种暴露更深层潜在问题的症状。
发生这种情况有几个原因:
你的 Diffusion 服务器跟不上它的工作量。这种情况会在一段时间后发生,这让我想知道您的服务器 JVM 是否花费了太多时间来收集垃圾。Java Missions Control擅长回答这个问题。
我们很少看到这种影响具有双重角色的控制客户端,例如创建和更新主题,以及对诸如Missing Topic Notifications之类的事件做出反应。流量控制是多项因素的函数,包括队列饱和度和未满足请求的数量。如果是这种情况,请考虑每个角色的离散会话。
在转向第二种之前,请考虑并探索第一种更简单的可能性。如果问题仍然存在,请通过 support@pushtechnology.com 联系我们,
马丁