> > I'm finding that once a user requests a page which runs a > particularly slow sql (say up to 5 minutes), > any other > subsequent requests seem to take the hit as well, and return > very slowly. > Take a look at DadlockDebugger product - you'll see what is > happening with your Zope threads. >
Thanks, this looks quite handy, I am going to give it a whirl (I assume that threadframe module dependency hasn't yet hosed anyone's Linux machine - funny how a disclaimer can inspire paranoia) > Isn't it better idea to execute long running query outside of > zope - external method or sth, and only check for results > even with simple page reload? We did something like this with > pdf generation and this worked as expected, but of course you > need some additional work to create such thing. > Yes I agree, in my case those SELECTs aren't *supposed* to be taking 5 minutes. That's a separate problem. However when such a problem bites I don't want all of my users to suffer, just the unlucky one who requested the doomed sql to be run. > > So is this blocking effect just expected behavior for zope? > We are using Zope and Oracle too, and even 10 threads... and > I didn't noticed something like this. What is your processor > doing then? What is the CPU(s?) load. The single CPU isn't loaded at all. But if DeadlockDebugger doesn't turn up any good clues I will do some investigating at the system level. Thanks for advice, Jim _______________________________________________ Zope maillist - [email protected] http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
