getstream-io - getstream.io

getstream.io文档说人们应该期望在大约60ms内检索一个feed。当我检索我的Feed时，它们包含一个名为＆＃39; duration＆＃39;我采取的是计算的服务器端处理时间。这个值稳定在10-40ms左右，平均大约15ms。

问题是，我很少在不到150毫秒的时间内获得我的饲料，平均时间大约是200-250毫秒，有时高达300-400毫秒。这是获取Feed，没有增加等的时间，我已经通过tcpdump验证网络往返很低（大约25ms），并且实际花费的时间等待服务器响应。

我试图绕过我的应用程序（欧洲西部和欧洲中部地区），但这似乎并没有太大影响（再次，网络往返稳定在25ms左右）。

我的问题是 - 我真的应该期待60毫秒并继续调查，还是200-400毫秒正常？在getstream.io网站上，解释了开发者帐户收到＆＃34;低优先级处理＆＃34; - 这在实践中意味着什么？我对另一个计划有多大的期望？

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

Stream API使用SSL加密流量。不幸的是，SSL引入了额外的网络I / O.通常，您只需要为增加的延迟付费一次，因为Stream HTTP API支持HTTP persistent connection（也称为keep-alive）。

这是一个Wireshark屏幕截图，显示了2个连续API请求的TCP流量，其中保持活动状态为禁用客户端：

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

经过一番调查后发现，用于向Stream的API（请求）发出API请求的库默认情况下没有启用keep-alive。此类更改将很快成为图书馆的一部分，并可在development branch上找到。

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

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