CODEWITHSUNDEEP
ajaxhttpwebsocket
Vojtěch
Vojtěch

Reputation: 12416

Decision whether to use simple HTTP requests or WebSockets

We are implementing a service which is used by a lot of users in the same time. In peaks we can have tens of thousands of people online.

Critical part of our service needs reimplementation and so we try to think of new ways of doing it. At the moment we send simple and very short/small AJAX HTTP request based on user interaction:

At the same time, in some case (1 in 10) we have open EventSource from which we read some modifications on the server.

The question is whether this model is good enough or if it is better to open a WebSocket and pass everything via WebSockets.

What should be the decision for the right implementation?

It was noted that this question answers the same: WebSockets protocol vs HTTP – however I ask for specific use-case. The related question is rather asked in general.

Upvotes: 4

Views: 263

Answers (1)

cshu
cshu

Reputation: 5944

  • Disadvantage - when lots of people online, we would keep thousands of connections active

You can implement your service to close idle websocket connection after a timeout. That's probably the same way how EventSource works for you, so you don't keep too many active connections. (Similar performance characteristics.)

(But if you are relying on the automatic reconnection of EventSource provided by the browser, then switching to WebSocket means you need to write more code for the logic of reconnection.)

Typically WebSocket should have less network traffic overhead. But how much difference depends on how your current service is implemented. If you have already optimized your logic and squeezed out every bit of performance with AJAX and EventSource, using WebSocket might be a marginal improvement.

Upvotes: 2

Related Questions