> > 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 -