Polling and long polling

With polling, the client asks the server for new data on a timer. The server does not need to know the client exists between requests. Polling works through every proxy and firewall. It scales with ordinary stateless HTTP servers. It is also slow and wasteful, and the numbers show why.

The big idea

There are two versions. In short polling, the server answers at once, even when nothing is new. In long polling, the server holds the request open until it has data or a timeout passes. Short polling is simple, and long polling is almost instant for the client.

Walking through it

Short polling at scale:

1,000,000 clients polling every 5 seconds:
  requests per second = 1,000,000 ÷ 5 = 200,000 req/s
  if 1% of polls find new data, 198,000 req/s do nothing useful
  average delay before seeing an update = 5 ÷ 2 = 2.5 seconds

Halve the interval and you double the load. Cutting the delay is expensive, which is the core weakness of short polling. It suits dashboards that refresh every 30 to 60 seconds. It is a poor fit for chat.

Long polling changes the shape of each request:

client → GET /updates?since=1041      (server holds the request)
server …  message 1042 arrives
server → 200 [1042]                   (answer immediately)
client → GET /updates?since=1042      (client asks again at once)

Updates arrive almost instantly, and empty responses happen only once per timeout, such as every 30 seconds. Early Facebook chat and many first-generation real-time systems used long polling, because it works over plain HTTP.

Its costs are real. Every message needs a new HTTP request, with headers, authentication and routing. Messages that arrive between one response and the next request must be buffered on the server. The server also holds one open request per client.

Common mistakes

• Using short polling for chat. Most requests return nothing, and the delay still depends on the interval.
• Forgetting the gap in long polling. A message that arrives between responses must be buffered, or it is lost.
• Holding requests longer than proxies allow. Load balancers drop idle connections, so keep the timeout well inside their limits.

Check yourself

1. How many requests per second do 1 million clients polling every 5 seconds create?

   Answer: 200,000 requests per second (1,000,000 ÷ 5).

2. Why does halving the polling interval double the load?

   Answer: each client makes twice as many requests per second, so total load doubles.

Key takeaways

• Short polling is simple, but most of its requests return nothing, and delay depends on the interval.
• Long polling holds each request until there is news, so delivery is near-instant.
• Long polling needs server-side buffering between requests, and it still costs a full HTTP request per message.

Further learning

Next, see the push transports that avoid the per-message request, in SSE and WebSockets.