From: Geoffrey T. <GTalvola@Parlancecorp.com> - 2006-03-29 22:16:22
|
I just tried out the AjaxSuggest example servlet that was added to Subversion last month. It works, but unfortunately it seems to gobble up 100% of the CPU. It looks to me like the problem is in the ajax_response method of AjaxPage. It uses an inefficient polling loop; instead, it needs to use a threading.Event or Queue or something along those lines that it can efficiently wait on. - Geoff |
From: John D. <jdi...@te...> - 2006-03-30 14:23:32
|
Not only that, it consumes a webware thread that could be used for other requests. 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. --John Geoffrey Talvola wrote: > I just tried out the AjaxSuggest example servlet that was added to > Subversion last month. It works, but unfortunately it seems to gobble up > 100% of the CPU. > > It looks to me like the problem is in the ajax_response method of AjaxPage. > It uses an inefficient polling loop; instead, it needs to use a > threading.Event or Queue or something along those lines that it can > efficiently wait on. > > - 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 > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > > ______________________________________________________________________ > This e-mail has been scanned by MCI Managed Email Content Service, using Skeptic(tm) technology powered by MessageLabs. For more information on MCI's Managed Email Content Service, visit http://www.mci.com. > ______________________________________________________________________ > > > |
From: John D. <jdi...@te...> - 2006-03-30 14:32:50
|
and, of course, as soon as I sent my message, I could get in to the wiki and update it. wiki.w4py.org/ajax_in_webware.html wiki.w4py.org/ajaxpage.html wiki.w4py.org/ajaxjavascript.html --John John Dickinson wrote: > Not only that, it consumes a webware thread that could be used for > other requests. > > 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. > > --John > > Geoffrey Talvola wrote: >> I just tried out the AjaxSuggest example servlet that was added to >> Subversion last month. It works, but unfortunately it seems to >> gobble up >> 100% of the CPU. >> >> It looks to me like the problem is in the ajax_response method of >> AjaxPage. >> It uses an inefficient polling loop; instead, it needs to use a >> threading.Event or Queue or something along those lines that it can >> efficiently wait on. >> >> - 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 >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/webware-discuss >> >> ______________________________________________________________________ >> This e-mail has been scanned by MCI Managed Email Content Service, >> using Skeptic(tm) technology powered by MessageLabs. For more >> information on MCI's Managed Email Content Service, visit >> http://www.mci.com. >> ______________________________________________________________________ >> >> >> > > > ------------------------------------------------------- > 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 > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > > ______________________________________________________________________ > This e-mail has been scanned by MCI Managed Email Content Service, > using Skeptic(tm) technology powered by MessageLabs. For more > information on MCI's Managed Email Content Service, visit > http://www.mci.com. > ______________________________________________________________________ > > ______________________________________________________________________ > This e-mail has been scanned by MCI Managed Email Content Service, > using Skeptic(tm) technology powered by MessageLabs. For more > information on MCI's Managed Email Content Service, visit > http://www.mci.com. > ______________________________________________________________________ > > |
From: Christoph Z. <ci...@on...> - 2006-03-31 13:53:15
|
John Dickinson wrote: > 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. Thanks a lot. I have already checked it in to the SVN repository. BTW, I have restarted the Wiki and let it use the current Webware 0.9. Should be better now. Your new implementation of ajax_response() looks good to me. However, I'm actually wondering whether you really always need to run this background polling. If requests are always answered within the timeout interval (which is set to 100 seconds), that mechanism should be never needed. For instance, in the "AjaxSuggest" example, it will be surely not needed. You will only need it if you have long-running queries or computations where getting the result is crucial. So I was wondering whether AjaxPage should provide a parameter that allows disabling and enabling the polling mechanism. In the AjaxSuggest example, I would like to disable it from the beginning. -- Christoph |
From: sophana <so...@zi...> - 2006-03-31 14:16:30
|
> However, I'm actually wondering whether you really always need to run > this background polling. If requests are always answered within the > timeout interval (which is set to 100 seconds), that mechanism should > be never needed. For instance, in the "AjaxSuggest" example, it will > be surely not needed. You will only need it if you have long-running > queries or computations where getting the result is crucial. So I was > wondering whether AjaxPage should provide a parameter that allows > disabling and enabling the polling mechanism. In the AjaxSuggest > example, I would like to disable it from the beginning. I agree with you that webware is not designed for doing this kind of stuff. If you want to do long running queries, I suggest that you bypass apache and webware, and implement a separate dedicated (python) server that supports these very long running queries, without the timeout problem, without polling. |
From: Christoph Z. <ci...@on...> - 2006-03-31 15:24:26
|
sophana wrote: > I agree with you that webware is not designed for doing this kind of stuff. > If you want to do long running queries, I suggest that you bypass apache > and webware, and implement a separate dedicated (python) server that > supports these very long running queries, without the timeout problem, > without polling. Anyway, you need to somehow inform the client that your result is ready. For VERY long running queries, you can expect the client to look at a certain result page. But John's solution is nice in that it informs the client automatically when the server is ready, even if it takes longer than the usual timeout of 90 seconds. However, this is really not the normal use case, therefore I have made the polling part now optional. The timeout for long-running queries is now an attribute of the AjaxPage class that can be overridden by servlet instances. If it is set to 0, not polling takes place. I have also split up the Javascript file in two parts, separating the functions used for polling. If timeout is set to 0, the second part is not loaded. The AjaxSuggest example works now with a timeout of 0, i.e. without any polling. It is already checked in to the SVN repository. -- Christoph |
From: sophana <so...@zi...> - 2006-03-31 19:06:09
|
I am still not convinced that polling is a good solution for long queries. One good reason for this is that you can't implement real time application anymore: a chat board, real time stock quotes, etc... Isn't it better to store the tcp socket file handles left open in a connection pool? As soon as a new event is to be sent, the tcp connection is retrieved from the pool, then simply written. If apache limit connection time, isn't it simpler to use another port and let the javascript contact directly the webware application server bypassing apache? I don't know how many tcp connections can a single linux server can handle, probably tens of thousand? Maybe a persistant connection handler could be implemented in webware? > Anyway, you need to somehow inform the client that your result is > ready. For VERY long running queries, you can expect the client to > look at a certain result page. But John's solution is nice in that it > informs the client automatically when the server is ready, even if it > takes longer than the usual timeout of 90 seconds. |
From: John D. <jdi...@te...> - 2006-03-31 15:09:19
|
> However, I'm actually wondering whether you really always need to run > this background polling. If requests are always answered within the > timeout interval (which is set to 100 seconds), that mechanism should > be never needed. For instance, in the "AjaxSuggest" example, it will > be surely not needed. You will only need it if you have long-running > queries or computations where getting the result is crucial. So I was > wondering whether AjaxPage should provide a parameter that allows > disabling and enabling the polling mechanism. In the AjaxSuggest > example, I would like to disable it from the beginning. Instead of turning the polling off, would setting the client polling interval to some big number be good enough? I added an ajax_clientPollingInterval to AjaxPage so that a child page can easily set the polling interval (long if it doesn't need it, short if it does). Also I added an auto_connect flag to the javascript that will prevent the client from connecting to ajax_response on the server at all. It could be set to false for a site that would never need the ajax_response mechanism. There are two uses I can see for ajax_response. One is for long running requests (in my case, generating reports). The other is sending javascript commands to the client without the client first triggering an event (perhaps a chat application). The servlet can use ajax_cmdToClient for this second use. --John |
From: Christoph Z. <ci...@on...> - 2006-03-31 15:41:15
|
John Dickinson wrote: > Instead of turning the polling off, would setting the client polling > interval to some big number be good enough? I added an > ajax_clientPollingInterval to AjaxPage so that a child page can easily > set the polling interval (long if it doesn't need it, short if it does). Sorry, I should have waited for your response before doing it on my own. That looks good. However, I really would like to be able to switch off the polling completely. This spares loading and running the Javascript for the polling mechanism, and the shutdown, with all possible Javascript errors. > Also I added an auto_connect flag to the javascript that will prevent > the client from connecting to ajax_response on the server at all. It > could be set to false for a site that would never need the ajax_response > mechanism. But it is not so easy to set it to false from the Webware servlet (you have to make two versions of the Javascript file). > There are two uses I can see for ajax_response. One is for long running > requests (in my case, generating reports). The other is sending > javascript commands to the client without the client first triggering an > event (perhaps a chat application). The servlet can use ajax_cmdToClient > for this second use. Ok, I see. In the latter case, I would probably want to set the ajax_clientPollingInterval lower than in the former case, and make it less random. So I will implement the ajax_clientPollingInterval in a similar way. I will also add more comments and docstrings to the AjaxPage class in the Example context. By the way, I just saw the ajax_cmdToClient() method still uses the remote address instead of the session identifier. -- Christoph |
From: John D. <jdi...@te...> - 2006-03-31 15:52:15
|
> Sorry, I should have waited for your response before doing it on my > own. That looks good. However, I really would like to be able to > switch off the polling completely. This spares loading and running the > Javascript for the polling mechanism, and the shutdown, with all > possible Javascript errors. I like the idea of splitting the javascript up rather than a global flag. >> There are two uses I can see for ajax_response. One is for long >> running requests (in my case, generating reports). The other is >> sending javascript commands to the client without the client first >> triggering an event (perhaps a chat application). The servlet can use >> ajax_cmdToClient for this second use. > > Ok, I see. In the latter case, I would probably want to set the > ajax_clientPollingInterval lower than in the former case, and make it > less random. So I will implement the ajax_clientPollingInterval in a > similar way. I will also add more comments and docstrings to the > AjaxPage class in the Example context. Right. It still needs a little randomness, though. You don't want to get in a situation where somehow the clients become synchronized and make all of their polling requests at the same time. A little randomness will avoid that. > > By the way, I just saw the ajax_cmdToClient() method still uses the > remote address instead of the session identifier. oops. fixed in the wiki. --John |
From: Christoph Z. <ci...@on...> - 2006-03-31 16:23:04
|
I have now incorporated your ajax_clientPollingInterval() to AjaxPage as well and separated the responseTimeout parameter from the clientPolling flag. Adding some more docstrings and splitting the Javascript in two parts now makes the whole thing much better understandable. -- Christoph |
From: John D. <jdi...@te...> - 2006-03-31 17:36:42
|
I have also updated the wiki with similar changes (splitting the javascript, allowing polling to be disabled and stopped once it is going). It's probably slightly different than your changes in svn, so we should probably figure out which is better suited to the necessary tasks and go with that one. --John |
From: Christoph Z. <ci...@on...> - 2006-04-02 20:00:28
|
John Dickinson wrote: > I have also updated the wiki with similar changes (splitting the > javascript, allowing polling to be disabled and stopped once it is > going). It's probably slightly different than your changes in svn, so we > should probably figure out which is better suited to the necessary tasks > and go with that one. I have added your code for telling the client to stop polling once it is going and they are essentially the same now. If you think anything else should be changed in the SVN version, let me know. -- Christoph |