4

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:

  • Ping: I am still active
  • Activity: I have done this and please write it to the database
  • Finishing: I have finish my activities so close my requests

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.

  • Advantage – for each user we would maintain only one connection instead of sending multiple requests.
  • Disadvantage - when lots of people online, we would keep thousands of connections active

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.

Community
  • 1
  • 1
Vojtěch
  • 11,312
  • 31
  • 103
  • 173
  • Possible duplicate of [WebSockets protocol vs HTTP](http://stackoverflow.com/questions/14703627/websockets-protocol-vs-http) – Jack jdeoel Mar 16 '17 at 08:16

1 Answers1

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

cshu
  • 5,654
  • 28
  • 44
  • He can open a web socket and close it after a timeout as you said. With that he can send a ping via web socket when the user does a particular action eg: click, mouse move, or keyboard press. otherwise the connection is closed. it's better than opening and closing connection a lot IMHO. He can solve the issue of many opened connections by scaling horizontally his BackEnd, that an extra ~65000 connections per instance. – Fabrice Kabongo Mar 27 '17 at 21:15