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