2

I am prototyping an application using nodejs. But this question refers to hypothetical large scale roll out. What is more demanding on a server and/or bandwidth: WebSocket stay alive connections or repeated client HTTP GET requests?

For example (maybe an extreme example), is it more efficient for Twitter to allow its clients to send GET requests to its API every 20 secs, or have each client connected on an HTTP1.1 websocket? What about every 1 minute or greater, or less?

BTW, maybe it does not matter, but presuming GET requests will be handled by nginx as supposed to node, would this make a difference?

  • What are you rolling out? Are the GETs keep-alive's themselves or are they checking for updated info? – Rob Olmos Nov 30 '10 at 1:30
  • Just checking for updated info. In the prototype it returns a json response. – Ross Nov 30 '10 at 9:35
  • 1
    More elaborative answers: stackoverflow.com/questions/14703627/… – Anton Tarasenko May 26 '18 at 9:29
1

WebSockets are better because you keep connection open and don't send extra protocol headers and other stuff after each request and response. Look at this article:

During making connection with WebSocket, client and server exchange data per frame which is 2 bytes each, compared to 8 kilo bytes of http header when you do continuous polling.

2

websockets is a better option but it isn't in all browsers yet. If you go that route you'll want to use SocketIO on the client and node.js side. That will provide a failover to flash sockets if the browser does not support websockets yet.

You gain on websockets since the data that gets sent back to the server isn't as big as a get request.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.