使用getstream.io預期性能

getstream.io文檔指出，應該預計在大約60毫秒內檢索一個Feed。當我檢索我的提要時，他們包含一個名爲'duration'的字段，我所計算的是服務器端處理時間。這個值穩定在10-40ms左右，平均約爲15ms。使用getstream.io預期性能

問題是，我很少在150毫秒內得到我的飼料，平均時間大約在200-250毫秒，有時高達300-400毫秒。這是單獨獲取Feed的時間，沒有豐富等，我已經通過tcpdump驗證了網絡往返時間很短（大約25ms），並且實際上花了時間等待服務器響應。我嘗試過移動我的應用程序（歐盟西部和歐盟中央），但似乎並沒有太多的影響（再次，網絡往返穩定在25毫秒左右）。

我的問題是 - 我真的應該期待60ms並繼續調查，或者是200-400ms正常嗎？在getstream.io網站上解釋說，開發者帳戶收到「低優先級處理」 - 這在實踐中意味着什麼？我可以用另一個計劃預期多少差距？

我正在使用節點js低級API。

來源

2016-09-14 averas

您可以分享您正在測試的API請求嗎？ –

當然！ https://gist.github.com/averas/01c00259465a6f66d1212dd3d4617c57 – averas

Stream API使用SSL來加密流量。不幸的是，SSL引入了額外的網絡I/O。通常您只需支付一次延遲時間，因爲Stream HTTP API支持HTTP persistent connection（又名保持活動狀態）。

這裏有2所連續的API請求的TCP流量與永葆禁用客戶端的Wireshark的截圖：

的4行紅色突出顯示的TCP連接時，每次越來越封閉。另一個有趣的事情是握手需要幾乎100ms，並且它已經完成了兩次（第一批線）。

經過一番調查後，事實證明，用於向Stream的API（請求）發出API請求的庫默認情況下未啓用保持活動狀態。這種變化將很快成爲圖書館的一部分，可在development branch上找到。

下面是與保活啓用相同的兩個請求（使用該分支的代碼）的截圖：

這個時候有沒有連接重置了與第二HTTP請求不做SSL握手。

來源

2016-09-14 16:09:04

太棒了！我嘗試了開發分支，現在我從我的服務器平均檢索到120毫秒的提要，其中25-40毫秒可能歸因於「正常」網絡延遲。您是否查看了一些減少SSL延遲的方法，除了您修復的保持活動狀態？如假啓動和恢復（https://istlsfastyet.com/）？我想很多客戶都是「回頭客」（只要我們正在談論後端服務器），這意味着這種方法可能會非常有益。 – averas

使用getstream.io預期性能

回答

相關問題