Short-polling vs Long-polling for real time web applications?

Question

I'm building a real-time web application As far as I know, the most popular choices are short-polling and long-polling. What are the advantages and disadvantages might there be for measuring one over the other?

Adenoid

@metrobalderas Long poling is here, just not as websockets. You can still use an iframe/script/xhr and keep the server from closing the connection. – Measureless

For anyone else researching this topic, here's another question on the topic of short-polling vs long-polling. – Stratify

Answer 1

• Short polling (a.k.a. AJAX based timer):

  Pros: simpler, not server consuming (if the time between requests is long).
  Cons: bad if you need to be notified WHEN the server event happens with no delay. Example (ItsNat based)

• Long polling (a.k.a. Comet based on XHR)

  Pros: you are notified WHEN the server event happens with no delay. Cons: more complex and more server resources used. Example (ItsNat based)

Apperception

Specifically for long polling the main limiting server resource is maximum number of open sockets. Different OS have different limits but there are limits and the limits are much lower than available memory. Short polling get around this because each connection is only open for a short period of time therefore many connections can be time-multiplexed. – Incubation

Long polling does not use more resources, in fact it uses much less. An idle socket connection basically uses no resources other than keep-alive packets (if enabled/configured) and an open file descriptor. – Interrelate

Examples are not available anymore. – Piliform

Answer 2

Just for the sake of argument.

Both are http request (xhr), and its at least partially untrue it uses more server resources (depends totally on technology, will explain later).

Short polling.

Lot of request that are processed as they come on server. Creates a lot of traffic (uses resources, but frees them as soon as response is send back):

00:00:00 C-> Is the cake ready? 
00:00:01 S-> No, wait.
00:00:01 C-> Is the cake ready?
00:00:02 S-> No, wait.
00:00:02 C-> Is the cake ready? 
00:00:03 S-> Yes. Have some lad.
00:00:03 C-> Is the other cake ready? ..

Long polling

One request goes to server and client is waiting for the response to come (its unresolved). In case of Server with php/apache would mean a spawned thread to handle, that reserve resources, till its done. So the traffic is smaller, but you eat up your resources fast (or rather you block resources). But if you use for example Node (or any other async approach - c++ qt for example), you can potentially minimize the resource usage a lot (store response object for http request and use it when the work is ready)

12:00 00:00:00 C-> Is the cake ready? 
12:00 00:00:03 S-> Yes.Have some lad.
12:00 00:00:03 C-> Is the cake ready? 

If you compare that to short polling, you will see that potentially in short poll you used more transfer, but during those 3s you actually take 1,5s of processing time (means something could execute in between your calls). In case for long poll the same resources were used all the time. Now usually php with all libs starts with 4MB memory - then you have a framework 4-20MB. Assume you have 1024MB RAM available (free). Say lets be pessimistic and assume that you will use 25 MB per one php instace. It means you can get only as much as 40 long polled connection scripts.

Its precisely the reason why you could serve potentially a lot more with Node, as node would not spawn its instances (unless you want to use workers etc), so with same memory you could probably get easily to 10k connections hanging. You would get a spike in the CPU as they will come, and when they will potentially be released, but when they are idle its like they are not there (you pay only for the memory structures you would keep in node/c++).

Websocket

Now if you want to send few things, whenever they are in or out of client, go for the websockets (ws protocol). First call is size of http request, but later you send just the messages, from the client to server (new questions) and server to client(answers or pushes - can even do broadcast for all connected clients). There are php websocekts libs but again, use some different technology - node or c++ preferably.

Some libs, like socket.io have a hierarchy of its own, so when websocket fails, it goes back to long or short polling.

When to use.

Short polling - well, never ^^.

Long polling - potentially when you are exchanging single call with server, and server is doing some work in background. Also when you won't query server on the same page anymore. Also when you are not using php as layer to handle the long polled connection (node/c++ can be a simple middle layer). Note long polling can be really beneficial, but only when you make it so.

Websocket - you potentially will exchange more then one or two calls with server, or something might come from server you did not expected / asked, like notification of email or something. You should plan different "rooms", depend on functionalities. Embrace the event based nature of javascript ;]

Laurenelaurens

So essentially, long-polling is a persistent connection that can be asynchronous open socket, while short-polling is typically perpetual requests of a synchronous process? – Birkenhead

Its not persistent as such - its that you do not send response right await from server - and as soon as you do it closes - in other word its waiting (hanging). Same behaviour you would get with some long cron scripts - that will send only stuff when ready to browser after 10 minutes. Principle is the same - its just usage that changes. So its very much sync. This also brings you to second problem with long polling that I have not mentioned - browser limitations for number of open connections ( its around 8 now I think - there is no limit for websocket connections atm in browsers). – Laurenelaurens

Another serious limitation of long polling is the session locking, unless you close the session or using non blocking session manager (like db), the session file for the user will be locked and won't accept requests from the user even from a different browser window. – Ganister

Short polling has it's place, for example in dashboard applications, due to architectural and UX benefits of batching UI updates. – Lujan

Which is the easiest to scale? – Barnette

Answer 3

If you want to get real time application based on database you can use ajax long poll and comet combination. Long poll is really good for your bandwith and also it is really useful for user MB.Because when user send request user will pay for it like MB or some kind of internet connection.For example for Short poll when you do something like sending request per second user internet usage will be more because each connection user will pay for it(It means that user loose Mb )but in the long polling user only will pay just for new messages.

Websocket is really good thing but when you use it you should think about one big problem that a lot of people cannot use chat sistem because Websocket is for just new version of browsers

Vivien

A lot of people should update their browsers... Websockets were already supported on IE11. Microsoft is pushing everyone into Windows 10, and that means Edge by default. Unless you are using Opera Mini, but then that is your fault :P – Mcavoy

and that is why you should use something like socket.io that handles this for you when websockets are not avaible ;] yet codebase stays the same – Laurenelaurens

@Laurenelaurens Socket.io is a scalability nightmare. – Corin

@Corin how so? you can load balance, now you can also share the socket between different processes. You can always fall back to pure websocket implementation but the core stays the same. Well you can do socket implementation yourself but why invent the wheel when for webdev it is a good standard? If you have problems with distributed communication of the processes that handle socket connections you can always explore the redis pub/sub. The real advantage socket.io got over websocket is the fallback protocol, that makes it vaibale for old browsers. – Laurenelaurens

@Laurenelaurens I am happy to hear that, will I be able to use socket.io in shared hosting?because websocket has also disadvantage like it is not working on shared hosting plans – Vivien

a lot of stuff doesn't work on shared hosting ;] You can load balance websockets in general without problem. – Laurenelaurens

@Laurenelaurens what kind of hosting I need to use Websocket?VPS? – Vivien

anything that gives u access to console really. I m personally using Linode for my private stuff (20$ a month for a box with 4 cores). There are other providers with similar prices thou – Laurenelaurens