0

我正在使用 EventMachine 开发一个实时应用程序。两个客户端A和B，通过标准 TCP 或通过带有 em-websocket 的 WebSocket 连接到 EventMachine 服务器。

每次数据通过 EventMachine 时，代码执行需要 95 毫秒。与服务器对话时A，有 95 毫秒的延迟。当A与 交谈时B，会有 190 毫秒的延迟。

如果许多请求快速连续发生，则延迟消失，但序列中的最后一个请求除外。所以，如果我发送 10 个快速请求，每个大约 5 毫秒后我会收到 9 个响应，但第 10 个响应又需要 95 毫秒。

我推断这与EventMachine.set_quantum 有关。从文档：

方法：EventMachine.set_quantum

对于高级用户。该函数设置默认的定时器粒度，默认略小于 100 毫秒。调用此函数可设置更高或更低的粒度。该函数影响 add_timer 和 add_periodic_timer 的行为。大多数应用程序不需要调用此函数。

避免将量程设置为非常低的值，因为这可能会降低某些极端条件下的性能。我们建议您不要使用低于 10 的值。

好吧，这就解释了 95ms 的来源。果然，调用改变了延迟EventMachine.set_quantum，但由于文档中的警告，我对调整这个值持谨慎态度。

set_quantum实际在做什么？我找不到有关量子变量含义的任何文档或解释。

我能做些什么来减少这些延迟？我想了解将量子减少到 10 毫秒的潜在影响。

EventMachine 是否是正确的选择？我基本上将它用作美化的 TCP 连接。也许我应该坚持使用原始套接字进行进程间通信，并找到一个不使用 EventMachine 的 WebSocket 服务器 gem。

4

1 回答 1

2

EventMachine 不断运行一个循环，它会检查：

  1. 是否触发了任何计时器。
  2. 如果任何文件描述符与它们有关。

第二步涉及底层的适当机制，例如select(..)调用。这就是量子价值的所在。所以基本上循环看起来是这样的：

  1. 是否触发了任何计时器？
  2. 任何文件描述符都与它们有关吗？等待他们，直到quantum毫秒。
  3. 除非有关闭请求，否则请转到第一步。

因此，设置quantum为较低的值将使该循环更频繁地迭代，从而消耗 CPU 周期。我不认为这真的是一个问题。

令我惊讶的是，您完全有这种通信延迟，因为如果文件描述符上有事件（例如数据），所有这些查询机制（ select、 或或其他）都会立即返回。epoll这基本上意味着您根本不应该招致这些延误。如果这种延迟是有意为之，那么许多瘦用户已经对此感到非常不满。

所有这一切都让我觉得你的代码中有些地方有点不对劲，使它以这种方式工作。不幸的是，除非我看到它，否则我不能说更多。

希望能帮助到你！

于 2015-05-31T17:35:21.660 回答