Affects to the server from running EventSources

Question

I'm currently building a Chat just for fun. I've never done it before, and I did in in general to try out the EventSource API (Server-Sent Events) in JavaScript. I just heard of it about 3 days ago and I thought it was interesting and far easier than setting up a WebSocket.

I knew that long polling uses up a lot of resource. However, since I've never heard of an EventSource, how does it affect the server? Does it use up the same amount of resource?

I've noticed that in the Networks Tab of the Google Chrome Developers Tool, the EventSource does creates a request with a large content size (over time). Is it better have 1 request with a large content size?

My chat currently is running two EventSource's. One for the chat itself (running every 2500ms) and for the "is typing.." mechanism on the chat (running every 250ms).

After about a minute of being on the chat, the combined content size of the two requests is about 150kb. This will increase the more messages there are though.

I'm afraid that my host will suspend my account. This is what happened to a friend of mine who used polling or long polling (I forgot). I'm not sure if an EventSource uses as much resources as polling or long polling does though.

Main Question: How does an EventSource affect a server?

• How does it use resource?
• Is there anything better other than using a web socket?
• Is it better to have 1 request that will create a large content or having multiple requests carrying small amounts of data?

Answer 1

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

Answer 2

To understand the impact of SSE on your server you need to understand how they work. I will start by explaining a bit about long polling since it is the closest alternative.

Long Polling

With long polling, the client sends a request to the server and the server holds on to it; it doesn't send a response if it has nothing to say. For your chat example, you can send a request with the ID of the latest message you received and the server will delay sending the response until there are new messages they need to send you, at which point the response is released.

The drawbacks are that a connection is kept alive even though it isn't used and the script is running (probably polling the DB for new messages) constantly. You still need a new connection each time the server sends something to the client.

The advantages over regular polling are that the traffic is much reduced because the response is only given when there is something to say.

Server Sent Events

SSE works very much like long polling, in that it requires a connection from the client and only sends messages if there is something to say, but the big difference is that the connection is not closed with the first message. Obviously, not having to establish a new connection for each message is a win, unfortunately the negative efects on the server are similar: connection is kept alive and the server script is kept running. The advantage is that the client only ever sends one request.

Web Sockets

Web sockets provide real two-way communication, but the principle of keeping the connection open is the same. The advantage you can get from here is that you can package your information any way you wish.

One thing to note is that different servers can handle these situations differently. With it's focus on asynchroneous events, NodeJS seems more suited as the server component of your chat system no matter if you use long polling, SSE or Web Sockets.

As for your final question, it depends a lot on the situation you're in and what you mean by "better". If by better you mean less network traffic, then a large response should have a lot less overhead than multiple short ones.

So to sum it up:

• not a very big advantage/disadvantage over long polling or web sockets in terms of CPU, some advantage over long polling in terms of network usage
• web sockets are still the best if you have the time to deal with the extra complexity
• probably 1 request will be better