Erwartete Leistung mit getstream.io

Question

Die Dokumentation von getstream.io besagt, dass man erwarten sollte, einen Feed in etwa 60 ms abzurufen. Wenn ich meine Feeds abrufe, enthalten sie ein Feld namens "duration", das ich für die berechnete serverseitige Verarbeitungszeit verwende. Dieser Wert liegt konstant bei etwa 10-40 ms, mit einem Durchschnittswert von etwa 15 ms.

Das Problem ist, ich bekomme selten meine Feeds in weniger als 150ms und die durchschnittliche Zeit ist eher um 200-250ms und manchmal bis zu 300-400ms. Dies ist die Zeit für das Erhalten des Feeds allein, keine Bereicherung usw., und ich habe mit tcpdump verifiziert, dass der Netzwerk-Roundtrip niedrig ist (etwa 25 ms) und dass die Zeit tatsächlich darauf gewartet wird, dass der Server antwortet.

Ich habe versucht, um meine Anwendung (eu-West und EU-Central) zu bewegen, aber das scheint nicht viel zu beeinflussen (wieder, Netzwerk-Roundtrip ist stetig um 25ms).

Meine Frage ist - sollte ich wirklich 60ms erwarten und weiter untersuchen, oder ist 200-400ms normal? Auf der Website getstream.io wird erklärt, dass Entwicklerkonten "Low Priority Processing" erhalten - was bedeutet das in der Praxis? Wie viel Unterschied könnte ich mit einem anderen Plan erwarten?

Ich benutze den Knoten js Low-Level-API.

Answer 1

Stream-APIs verwenden SSL zum Verschlüsseln des Datenverkehrs. Leider führt SSL zusätzliche Netzwerk-E/A ein. Normalerweise müssen Sie die erhöhte Latenz nur einmal bezahlen, da Stream HTTP APIs HTTP persistent connection (aka keep-alive) unterstützt.

Hier ist ein Wireshark Screenshot des TCP-Datenverkehrs von 2 aufeinanderfolgenden API-Anfragen mit alive deaktiviert Client-Seite halten:

Die vier Linien in rot-Highlight, dass die TCP-Verbindung wird jedes Mal geschlossen zu werden. Eine weitere interessante Sache ist, dass das Handshaking fast 100ms dauert und es zweimal gemacht wird (der erste Zeilenstrang).

Nach einigen Untersuchungen stellt sich heraus, dass die Bibliothek, die API-Anfragen an Stream-APIs (Request) stellt, standardmäßig nicht Keep-Alive aktiviert hat. Eine solche Änderung wird bald Teil der Bibliothek sein und ist unter development branch verfügbar.

Hier ist ein Screenshot von den gleichen zwei Anfragen mit Keep-Alive aktiviert ist (den Code aus diesem Zweig mit):

Dieses Mal einer Verbindung nicht mehr zurückgesetzt wird und die zweite Anforderung HTTP nicht SSL-Handshake durchführen