Polling or Long Polling
We now have two ways to get new messages to Marcus’s client.
- With polling, the client sends a request every few seconds. The server sends a response to each one right away, even when there is nothing new.
- With long polling, the client sends a new request as soon as it gets a response. The server sends a response only when there is something new, or when the time limit of 30 seconds is reached.
With polling, a new message sits on the server until the client’s next request comes. With long polling, a request is already waiting, so the server sends the message right away.
How they compare
They differ in three ways.
- How soon the user sees a change. With polling, up to one interval later. If the client polls every 10 seconds, a change can take 10 seconds to show. With long polling, right away.
- How many requests the client sends. With polling, one every interval, whether or not anything changed. With long polling, one after each change. When nothing changes, one every 30 seconds, because of the time limit.
- What the server keeps. With polling, nothing. The server sends the response and is done. With long polling, one waiting request for every open client.
With long polling, the client sends at least one request every 30 seconds. So if a delay of a few minutes is fine, polling every few minutes sends fewer requests than long polling.
Making frequent polls cheaper
There is another way to make polling every second cheaper. Most polls get an empty response. To send that response, the server needs only the identifier of the room’s last message. It can keep that identifier for each room in an in-process cache: a map in the server’s memory. Then, when a poll asks for messages after the room’s last message, the server can send the empty response without a query on chat_messages. When a message is posted, the server writes the new identifier into that room’s entry. This works only if every poll and every post go through the same map. So it assumes the server runs as one process.
The cache removes only the database query. Every poll still reaches the server with its headers and credentials, and still goes through authentication and the membership check. A long poll that is waiting takes memory, but the server does no work for it while it waits. So long polling still does less work than polling every second with a cache.
Which one to use
Ask two questions.
First, how soon must a change show up? If a delay of a minute or more is fine, poll at that interval.
Second, if it must show up within seconds, how often does it change? If most of the time nothing changes, use long polling. If it changes all the time, poll at a fixed interval. With long polling, there would always be something new by the time a request arrives. So the server would send a response at once, and the client would send a request after every change. Polling still sends only one request per interval, however often the data changes.