>  > 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,
Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to