John Dickinson wrote: > Not only that, it consumes a webware thread that could be used for > other requests.
Yes, this won't scale too well if you have large numbers of concurrent users. You could probably handle hundreds of users with a large thread pool though. Nevow/Twisted solves this problem by using async event-driven methods instead of threads. I think Twisted's architecture is a better fit for this type of application than Webware's thread pool. I wonder if there is some way to combine the two -- use standard Webware threads for "normal" short-lived requests but have some way to handle the ajax_response-type requests without tying up threads. It would probably require reworking the ThreadedAppServer architecture significantly. > > All in all, that implementation was flawed. > > I've got a new implementation that solves both of these problems, but > I can't seen to get in to the wiki to post it. The basic idea, > though, is > to move the work from the server to the client. The client, running > the javascript, will wait for some amount of time and then call > ajax_response() on the server. The server will see if anything is > available for that client. If not, ajax_response() can return > immediately and wait for the next connection from a client. To avoid > any synchronization of client connections to the server, the wait > period on > the client side is not constant (random between 3 and 8 seconds). > Also, > the server can send back what the timeout should be until the next > connection. This will allow the server control how often the client > connects (maybe depending on the page the user is looking at). > > In the short term, by adding a time.sleep(2) to the current > implementation of ajax_response(), you can avoid all CPU cycles being > consumed. I can see 2 gotchas with this method though. First, you introduce several seconds of latency between the time the server wants to send information to the client and the time the client receives the information; that may be unacceptable depending on the application. Second, this actually increases the amount of traffic between client and server because of the polling every few seconds. - Geoff ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Webware-discuss mailing list Webware-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
