3 ms·
Out of curiosity, I implemented the same using websockets. You'll obviously need a real implementation of a request-response interface, but this will do for the
by ricardobeat 7y ago
Out of curiosity, I implemented the same using websockets. You'll obviously need a real implementation of a request-response interface, but this will do for the test:
// server
ws.on('message', msg => {
switch (msg) {
case 'collection':
return ws.send([...generate 500 links ...])
case 'item':
return ws.send(...generate item...)
}
})
//client
ws.send('collection');
ws.onmessage = e => {
const msg = JSON.parse(e.data)
switch (msg.type) {
case 'collection':
collection.forEach(item => ws.send('item'))
case 'item':
items.push(item);
}
}
It finishes in 140-150ms, around the same time as the best HTTP version. That's without any caching and the client requesting each of the 500 items, when in fact the server could just push them. I'm surprised WS is not used more often for data exchange.
EDIT: actually ~50ms after removing the console.log() I added for each message...
- maxpert 7y agoWould be nice if you can put up a demo page some where.
- hliyan 7y agoDo load balancers and reverse proxies play well with websockets?
- slamb76 7y agoYes but only if they are at layer 3 implementation support is variable
- londons_explore 7y agoLoad balancing websockets can be tricky because an individual socket could last many hours. That means when you do a software update, you need to leave the old version running for many hours. Same applies with http, but an individual request tends not to take many hours.