Question

I am building a dynamic search (updated with every keystroke): my current scheme is to, at each keystroke, send a new AJAX request to the server and get data back in JSON.

I considered opening a WebSocket for every search "session" in order to save some overhead. I know that this will save time, but the question is, is it really worth it, considering those parameters: 80ms average ping time 166ms: time between each keystroke, assuming the user types relatively fast A worst-case transfer rate of 1MB/s, with each data pack that has to be received on every keystroke being no more than 1KB. The app also takes something like 30-40ms to weld the search results to the DOM.

I found this: HTTP vs Websockets with respect to overhead, but it was a different use case.

Will websockets reduce anything besides the pure HTTP overhead? How much is the HTTP overhead (assuming no cookies and minimal headers)?

I guess that HTTP requests open a new network socket on each request, while the WebSocket allows us to use only one all the time. If my understanding is correct, what is the actual overhead of opening a new network socket?

Was it helpful?

Solution

It seems like WebSockets provide a better performance in situations like yours.

Web Socked

  • small handshake header
  • full duplex communication after the handshake.
  • After the connection is established, only 2 bytes are added per transmitted request/response

Http

  • Http headers are sent along with each request

On the other hand, WebSocket is a relatively new technology. It would be wise to investigate web browser support potential network related issues.

Ref:

http://websocket.org/quantum.html

http://www.youtube.com/watch?v=Z897fkPn7Rw

http://en.wikipedia.org/wiki/WebSocket#Browser_support

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top