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.
- 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.