In AJAX applications that need to poll the server in regular intervals (like a chat applications), what is the recommended minimum time between two calls, so that the update is done as quickly as possible? What times are considered as hogs for the server and the client?
The answer to this question is very much dependent on:
- How much data is sent in each poll
- How many users you will have online at a time
- How much bandwidth your server can handle
- How "fresh" the data on your client needs to be
Without knowing any of these specifics for your app, it's going to be hard to give a good recommendation. Have you looked into a method where the client connects to the server, and the server holds the connection open until there is data available? Then the server delivers the data, and the client immediately reconnects and waits again. That can be tricky to get working, but you might be able to maximize both efficiency of bandwidth AND responsiveness that way.
It depends on the application, but for chat you probably want to poll pretty often - 1 to 4 seconds I'd say. What you can do is dynamically change the polling interval to decrease your server load - if nobody has said anything for a minute, increase to 10 seconds... after 5 minutes increase to 30 seconds - that kind of thing.
There is no real limit, other than the number of simultaneous users you expect to burden your server load with. You can probably dynamically tune this on the client end by keeping track of average response times.
In order to do this properly, under a decent load, you're betting off using Comet.
We have a different solution for AJAX polling in our chat:
The request is sent to the server and polls for the data on the server side in cycle with very short delay intervals (like 0.5 sec). Ones data is get, the request returns. Then next request is sent immediately to the server. All requests' timeout is set to something like 60 sec, when it expires without getting data, next request replaces it.