8

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?

Community
  • 1
  • 1
Ivo
  • 1,673
  • 3
  • 19
  • 28
  • 3
    websockets are worth it when server pushes messages to client – Raynos Jan 17 '12 at 22:53
  • I've done a similar thing before and found that to make it quicker you might want to delay the Ajax request for a few ms then cancel it if the user types another key. Then if the user types quickly you make one request instead of many. (although that doesn't actually answer you question on websockets!) – Mark Rhodes Jan 17 '12 at 23:12
  • That's what I'm doing right now. It works flawlessly, but I'm concerned that when I deploy it, the app might start struggling on slower ping times. Check out the actual app: http://77.70.33.151:8233/ You can search something like "firefox", "chromium" or "mozilla". – Ivo Jan 17 '12 at 23:15
  • HTTP requests do *not* open a new network socket on each request. – Julian Reschke Sep 08 '15 at 05:37

1 Answers1

3

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

xtrem
  • 1,737
  • 12
  • 13
  • Thanks, the video answered specifically my question (pure overhead of HTTP). As for browser support, it's not hard to implement fallback mechanisms or to use a library that does it for you (e.g. socket.io). – Ivo Jan 17 '12 at 23:50