[Zope] Threading, dtml and performance?!
Oliver Bleutgen <firstname.lastname@example.org>
Wed, 24 Oct 2001 22:16:11 +0200
> Sorry the Script might not do what it should. But that's not the important
> thing. Just select a script, that occupies Zope quite some time (e.g. long
> running <dtml-in>). The try to call another page on the site. Does ist
> Below I've changed the script a little. It might work (sorry can't test
> because my home implementation of Zope isn't up & running yet). Please
> it in a Folder with manny Subfloders (big site).
Well, you also could use
Just for fun I tested this on a linux machine, with a result
which confuses me, here's what I did (Zope 2.3.3):
Lets call the above method "stopper", for brevity.
(-1.) Restart zope
0. Create stopper
1. Start top on a console.
2. start one stopper-thread by "view"ing it in a new window.
3. top shows one python thread at 99% CPU
4. try some "innocent" pages on this server, they work seamlessly
5. start another stopper-thread by "view"ing it again in a new window
6. top shows two python threads at 50% CPU
7. zope ceases answering any other request
8. stop the "downloading" of stopper created in step 2
9. zope works again, but top shows 2 CPU-consuming threads as before
10. press reload in the browser you stopped in step 8.
11. zope ceases to answer any requests, top shows 3 CPU-consuming threads
12. repeat 8, zope works again, the 3 threads remain
13. repeat 8 again, we now see 4 threads in zope, zope reaches the default
thread limit and won't answer until restarted or the threads stop.
What happens at 7.?
Why isn't it possible for zope to stop the processing when it looses
I tested the same with a perl cpu-hogging cgi:
print "Content-type: text/html\n\n";
$b = sin $i*$a;
print "$b <BR>";
This script runs plenty enough on the command line, but stops
after around 5s when I hit the stop button on the browser
when it's run as a cgi.
Heck I even pulled the network cable on the client after
zope ignored me closing all browsers - no effect, the
4 threads still run on (12min CPU per thread).
Bonus question: Why is there a limit on range? ;-)