Hi Jean-Philippe, Sorry, that's one of these 'how long is a piece of string?' questions. :-) It's going to depend entirely on what your app is doing.
When you poll the server, you're trying to simulate a 'push' of data from server to client. The polling interval dictates the responsiveness of that push, and the overall load on the server. Responsiveness is going to be determined by the type of app - a server 'heartbeat' monitor might get away with once every five minutes, a stock trader might demand once a second. the only way to determine what sort of load your server can withstand is by measuring it. If you really do require a very fast response time, then polling is maybe not the best way to achieve it. You might want to look at Comet/Reverse Ajax, in which a single HTTP connection is held open long term on the server, and data pumped down it on demand. This is still very much bleeding edge, and full of hidden bear traps - the best implementation that I'm aware of is in the DWR toolkit. Depends how much effort you're willing to invest in figuring out all the issues. HTH Dave On Thursday 14 June 2007 09:46, Jean-Philippe Encausse wrote: > Hi, > > Is there best practices about how to setup Ajax Periodical Updater ? > > Well I mean if you set on a user webpage a Periodical Updater to pull > information there is 2 sides effects: > > 1. The session is never timeout because a request is performed > periodicaly. (When users go to lunch with opened browser) > > 2. If 500 browsers open the same webpage then 500 requests are done > periodicaly that could get down the application server. > > > So is there well knwown, good period configuration for the side effect 2. ? > I know that depends of server(S) but juste a little idea ? Should it > be in seconds, minutes ? > > Regards, > Jp -- Author: Prototype & Scriptaculous in Action, Ajax in Practice, Ajax in Action --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
