On 4 Jul 2009, at 08:34, Michał Pasternak wrote:
Hi,
as you can see here: http://www.divmod.org/trac/browser/trunk/Nevow/nevow/athena.py#L800 , if incomingMessages is a very, very long list, chances are, that it will block for a small amount of time. Also, if you happen to run the web server interactively, calling a lot of log.msg(…) functions will print out a lot of stuff on the console, which will also take some CPU cycles and GUI resources[1]. I think the best approach would be first to remove lines 803 – 806 (“else: log.msg(…)”) and test if the problem of browser lagging still exists – of course if you run server and browser on the same machine.
There are some cases, which may lead to accumulation of the messages on client, which then lead to lags on the client side (and a lots of log messages on the server). Those may be bugs in the application code, but I think some of those cases are browser-dependent too (for some code I tested, Google Chrome sent a lot of duplicate messages, while Firefox sent none). Some people say, that duplicate messages phenomenon may be even extension-dependent, as in case of Firefox with FireBug enabled.
Unfortunately, it seems that none of us is able to provide a minimal code sample of described misbehavior. Maybe it would be better just to disable those log messages in the release builds or make them optional?
I'll certainly look into this, but I believe that the system causing concern was run without a controlling terminal - and I have a suspicion that the offending log was even removed. The system is IO intensive though (hence using twisted in the first place) and we have had instances in the past of accidentally using blocking calls. I'll report back in a few weeks if we get some real tests going.