-
-
Save averas/01c00259465a6f66d1212dd3d4617c57 to your computer and use it in GitHub Desktop.
var stream = require('getstream'); | |
client = stream.connect('key', 'secret', 'id', { location: 'eu-central' }); | |
var feed = client.feed('user', 'foobar'); | |
var counter = 20; | |
var results = []; | |
function fetchFeed() { | |
var start = new Date().getTime(); | |
feed.get({limit:20}).then(function(data) { | |
results.push(new Date().getTime() - start); | |
process.stdout.write("."); | |
if (counter-- > 0) | |
fetchFeed(); | |
else | |
console.log((results.reduce(function(a, b) { return a + b; }) / results.length) + "ms"); | |
}); | |
} | |
fetchFeed(); |
If you have a chance can you attach tcpdump pcap file and add some interval between api calls?
With 4s intervals:
http://firefly.ibk.se/~racer/getstream.pcap
The average for the captured run was actually lower though:
.....................212.85714285714286ms
seems like keep-alive is not used; can you try running the same code from this branch? https://github.com/GetStream/stream-js/tree/keep-alive
Yes! That took me down to ~120-130ms per call. Given a network roundtrip delay of 30-40ms I guess the actual call is close to a 100ms now..
yep that sounds better. unfortunately SSL handshaking is very expensive in terms of I/O and keep-alive really saves the day because you only pay that cost the first time. We are probably going to merge that change in the master branch and release to NPM (some investigation is due).
Alright. But this is relevant for all of your client libraries I guess? Have you looked at some of the ways to decrease SSL latency, such as false start and resumption (https://istlsfastyet.com/)? I imagine many of your clients being returning clients (as long as we're talking backend servers) meaning such approaches could be quite beneficial.
we already support this server side and on some clients. The Python client for instance does false start and reuses the connection making the SSL only free. We should be able to get similar results with the node client (researching on this right now)
Cool! Great job identifying the issue so fast!
Average is almost always around ~330-340ms...
.....................334.4761904761905ms