getstream-io - getstream.io 的预期性能

Question

getstream.io 文档说人们应该期望在大约 60 毫秒内检索到一个提要。当我检索我的提要时，它们包含一个名为“持续时间”的字段，我采​​用的是计算出的服务器端处理时间。这个值稳定在 10-40ms 左右，平均在 15ms 左右。

问题是，我很少在不到 150 毫秒的时间内收到我的提要，平均时间大约是 200-250 毫秒，有时甚至高达 300-400 毫秒。这是单独获取提要的时间，没有丰富等，我已经用 tcpdump 验证了网络往返时间很低（大约 25 毫秒），并且时间实际上是在等待服务器响应。

我试图移动我的应用程序（eu-west 和 eu-central），但这似乎并没有太大影响（再次，网络往返稳定在 25 毫秒左右）。

我的问题是——我真的应该期待 60 毫秒并继续调查，还是 200-400 毫秒正常？在 getstream.io 网站上解释说开发人员帐户接收“低优先级处理” - 这在实践中意味着什么？我可以期望与另一个计划有多大的不同？

我正在使用节点 js 低级 API。

Answer 1

流 API 使用 SSL 加密流量。不幸的是，SSL 引入了额外的网络 I/O。通常您只需为增加的延迟支付一次费用，因为 Stream HTTP API 支持HTTP 持久连接（也称为保持活动）。

这是 2 个连续 API 请求的 TCP 流量的 Wireshark 屏幕截图，客户端保持活动禁用：

红色的 4 行突出显示 TCP 连接每次都会关闭。另一个有趣的事情是握手需要将近 100 毫秒，并且完成了两次（第一行）。

经过一番调查，事实证明，用于向 Stream 的 API（请求）发出 API 请求的库默认没有启用 keep-alive。此类更改将很快成为库的一部分，并在开发分支上可用。

这是启用了 keep-alive 的相同两个请求的屏幕截图（使用该分支中的代码）：

这次不再有连接重置，第二个 HTTP 请求也没有进行 SSL 握手。