Server-Sent Events costs at server side

Question

If I understand the Server-Sent Events principle correctly, each time a client registers to an EventSource, it actually opens a new HTTP connection to the resource managing the event. Contrary to other HTTP requests, the connection stays alive so the server process/thread dedicated to this client keeps running until the client disconnects.

What if we have 1000 clients connected to an application using SSE? Would we have 1000 processes/threads (doing the same thing) running concurrently just to handle the SSEs? I guess I'm wrong but if I'm not, is it really more efficient than the usual AJAX polling method where at least the server doesn't need to run that many processes/threads concurrently?

Answer 1

Yes, each client keeps the connection open as long as it can. With 1000 concurrent users you'd have 1000 TCP/IP connections open.

However, whether each connection uses a thread depends on the server.

Apache typically keeps a thread running for each connection, so it's pretty expensive. With Apache it's best to disable KeepAlive and use polling.

OTOH with event-based servers like node.js you can have just one process that manages all connections, so cost of each connection is much lower and you should be able to keep thousands of connections open easily.

The cool thing about SSE is that you can use it to do polling as well. It has retry: directive that specifies how long client should wait before reconnecting (polling) again. Just send that and close the connection when you want polling.

Answer 2

It depends on the threading model of the server. Apache defaults to one thread (or process) per connection so, even if the threads aren't doing very much (as is expected with an SSE connections), they sit there using up resources.

Servers like Nginx have a slightly different model, each thread handles multiple requests asynchronously. So stuff like SSE and WebSockets is far more efficient.

Apache can be made to perform more like Nginx and similar servers.