Affects to the server from running EventSources

Long polling uses more resources than EventSource because it is constantly establishing and destroying connections. With EventSource, only a single connection is used, and the client is waiting for data, instead of checking the server for new data.

When using long polling, a client will disconnect under these conditions:

• the client doesn't want any more data
• the client has just received its data
• the client has timed out waiting for data

When the server has no data, a client will wait until its timeout until the server has data. If there is data, the client disconnects and creates another connection. If the client times out, the client will disconnect and establish another connection. Therefore you can see overhead from many places.

Long Polling

• the client will make a new connection if it wants data
• if the client times out, it recreates another connection
• if the client receives information, it recreates a connection

EventSource

• the client creates a single socket on connection with the server
• when the client receives data, the connection is maintained and reused
• initiated by client using a GET request with the Accept: text/event-stream header
• obeys same-origin restriction

WebSockets

• the client creates a single socket on connection with the server
• when the client or server receives data, the connection is maintained and reused
• initiated using an HTTP GET request with an Upgrade: websocket header
• can be made to any origin (cross-domain)

---

Resource Consumption:

The overhead of EventSource is mainly just the existence of a connection. It is similar to websockets in this sense, where a single connection is established and maintained. Therefore, you will receive the most overhead using long polling, due to the constant establish/destroy cycle, the second most overhead from websockets (since they are bidirectional), and the least from EventSource, which is one-way.

Better Options:

For realtime and bidirectional communication between a client and server, you don't really have anything better than a websocket. It is the one solution where the client and server are listening for data from each other, instead of prodding each other for data.

SSE Requests

I think you're asking this question on the assumption that you think what's displayed in Chrome are individual requests. Since EventSource establishes a socket with the server, you are actually reading the cumulative amount of data sent through an EventSource socket. Therefore, when you send data, you're reusing the same connection, and you don't need to worry about request size.

---

In conclusion, the reason most hosts suspend for polling is because of the large amount of requests that both short and long polling require. If you use EventSource or websockets, you are using real-time communication that uses sockets, which don't "spam" the HTTP server with requests. (if I sent 100 data payloads, EventSource and websockets will use the same connection, long polling will have reconnected at least 100 times) The only thing you will have to watch here is the maximum amount of concurrent connections your server can handle, because sockets use less CPU and resources than polling.

Things about EventSource/SSE to take into consideration:

• uses traditional HTTP protocol, websockets do not
• has less browser support than websockets, but has polyfills for unsupported browsers
• has built in support for reconnecting and events
• has a simpler protocol compared to websockets