Re: Threading, dtml and performance?!
Well I've tested your script with an old backup of Zope 2.3.2 on an Win NT SP 5 machiene. There are no problems. The script runs in one window and in the other I can surf the management screen. My Solaris can't do that. On Solaris and on NT I could see your second problem. When I press cancel on the Browser the process/thread doesn't stop. Thats really a problem. I started your script twice and the machiene (NT) is nearly not usable anymore. But thats better than Solaris - there I can't start the process twice! For me I've prooven that there is something VERY WEIRD with the Solaris Zope. OK it might not be Zope but Python. As for me I need an answer / solution desperately! Any ideas anybody? My primary guess is, that Solaris doesn't relese the threads after using them. I've tried a threaded Python script on my Solaris machiene and that had no problems. But I must confess I have no clue on how Zope Threading works. Therefore my test doesn't proove anything really. By the way...it also shows how fast Zope really is because if I run "singlethreaded" and Zope can still serve a few thousand requests a day thats really not bad. Oliver Erlewein -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
AFAIK, such a beast does not exist where you can stop a transaction from pressing a browsers stop button. Web is stateless, so a stop button on a browser cannot be connected to the servers understanding of finish the request or don't. Zope threading process is a mysterious thing to me as well, but keep in mind that ITS threading is separate from SQL threading, so the speed I'm sure depends on how your system is setup. I personally prefer to use all SQL with Zope, and just put up with slower creation. The SQL calls are at least fully threaded, seeming to take much of the work of Zope allowing for other requests. But if tis test that slows down Zope to a crawl (on my dual-proc linux box its very tolerable) makes you uncomfortable, then check out ZEO... I'm doing the same now on Chris McD's advice. Cheers, Paul Zwarts -----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org] On Behalf Of Oliver Erlewein Sent: Friday, October 26, 2001 9:43 AM To: zope@zope.org Subject: [Zope] Re: Threading, dtml and performance?! Well I've tested your script with an old backup of Zope 2.3.2 on an Win NT SP 5 machiene. There are no problems. The script runs in one window and in the other I can surf the management screen. My Solaris can't do that. On Solaris and on NT I could see your second problem. When I press cancel on the Browser the process/thread doesn't stop. Thats really a problem. I started your script twice and the machiene (NT) is nearly not usable anymore. But thats better than Solaris - there I can't start the process twice! For me I've prooven that there is something VERY WEIRD with the Solaris Zope. OK it might not be Zope but Python. As for me I need an answer / solution desperately! Any ideas anybody? My primary guess is, that Solaris doesn't relese the threads after using them. I've tried a threaded Python script on my Solaris machiene and that had no problems. But I must confess I have no clue on how Zope Threading works. Therefore my test doesn't proove anything really. By the way...it also shows how fast Zope really is because if I run "singlethreaded" and Zope can still serve a few thousand requests a day thats really not bad. Oliver Erlewein -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Paul Zwarts]
AFAIK, such a beast does not exist where you can stop a transaction from pressing a browsers stop button. Web is stateless, so a stop button on a browser cannot be connected to the servers understanding of finish the request or don't.
Yes and no. When you stop the browser, the socket connection closes. The next time the server tries to use that socket it gets an exception. Ideally in handling the exception the server should stop the thread in question, but who is to say that really happens? Cheers, Tom P
Thomas B. Passin wrote:
[Paul Zwarts]
AFAIK, such a beast does not exist where you can stop a transaction from pressing a browsers stop button. Web is stateless, so a stop button on a browser cannot be connected to the servers understanding of finish the request or don't.
Yes and no. When you stop the browser, the socket connection closes. The next time the server tries to use that socket it gets an exception. Ideally in handling the exception the server should stop the thread in question, but who is to say that really happens?
As I wrote before, it happens in mod_perl, it doesn't happen in zope2.3.3 on linux 2.2.13. And I would still be interested in an explanation why two long running methods (not four) seem to be able to stall zopes http server on linux. cheers, oliver
Oliver, I'm a bit confused. What version of things are you running? I remember that this thread changed quickly to specify Solaris with the problem. I tested this problem on my linux box (note, dual processor) without any problems at all.... Mind you of course it slowed the response down a bit, but it was stable... And what is the significance of 2 methods and 'not 4'? Paul Zwarts -----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org] On Behalf Of Oliver Bleutgen Sent: Tuesday, October 30, 2001 5:13 PM To: zope@zope.org Subject: Re: [Zope] Re: Threading, dtml and performance?! Thomas B. Passin wrote:
[Paul Zwarts]
AFAIK, such a beast does not exist where you can stop a transaction from pressing a browsers stop button. Web is stateless, so a stop button on a browser cannot be connected to the servers understanding of finish the request or don't.
Yes and no. When you stop the browser, the socket connection closes. The next time the server tries to use that socket it gets an exception. Ideally in handling the exception the server should stop the thread in question, but who is to say that really happens?
As I wrote before, it happens in mod_perl, it doesn't happen in zope2.3.3 on linux 2.2.13. And I would still be interested in an explanation why two long running methods (not four) seem to be able to stall zopes http server on linux. cheers, oliver _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Paz wrote:
Oliver,
I'm a bit confused. What version of things are you running? I remember that this thread changed quickly to specify Solaris with the problem. I tested this problem on my linux box (note, dual processor) without any problems at all.... Mind you of course it slowed the response down a bit, but it was stable...
And what is the significance of 2 methods and 'not 4'?
Linux 2.2.13, Python 1.5.2 both from the suse dist (7.0?). zope 2.3.3 compiled from source. The problem is described here: http://lists.zope.org/pipermail/zope/2001-October/102360.html Basically, I can stop zope from responding by opening two browser windows which point to a long running zope dtml-method (the 2 methods) OTOH, pressing stop on one browser window makes zope responsive again while zope won't stop the respective thread (observable via top). The 4 is zope's default maximum number of python threads, which I can reach by using the above "hit-stop-and-reload" trick. cheers, oliver
Ah... ok. I HAVE had something similar, but it wasn't zope (after MUCH hair pulling, upgrading, reading, jumping up and down). The hit-stop-and-reload trick stalled my postgresql. In RH7.2 when you do a ps -ef, you can see the thread status now. Sometimes if a zsql method is going and you do that, it stalls. The ps-ef reveals the thread with an indicator saying UPDATE waiting. Perhaps this is what you get as well? Paul Zwarts -----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org] On Behalf Of Oliver Bleutgen Sent: Tuesday, October 30, 2001 6:56 PM To: zope@zope.org Subject: Re: [Zope] Re: Threading, dtml and performance?! Paz wrote:
Oliver,
I'm a bit confused. What version of things are you running? I remember that this thread changed quickly to specify Solaris with the problem. I tested this problem on my linux box (note, dual processor) without any problems at all.... Mind you of course it slowed the response down a bit, but it was stable...
And what is the significance of 2 methods and 'not 4'?
Linux 2.2.13, Python 1.5.2 both from the suse dist (7.0?). zope 2.3.3 compiled from source. The problem is described here: http://lists.zope.org/pipermail/zope/2001-October/102360.html Basically, I can stop zope from responding by opening two browser windows which point to a long running zope dtml-method (the 2 methods) OTOH, pressing stop on one browser window makes zope responsive again while zope won't stop the respective thread (observable via top). The 4 is zope's default maximum number of python threads, which I can reach by using the above "hit-stop-and-reload" trick. cheers, oliver _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Oliver Bleutgen writes:
As I wrote before, it happens in mod_perl, it doesn't happen in zope2.3.3 on How does "mod_perl" do it? It is non-trivial...
And I would still be interested in an explanation why two long running methods (not four) seem to be able to stall zopes http server on linux. I just checked with an "activeSleep" script:
from time import time
def sleep(sec): e= time() + float(sec) while time() < e: pass print 'active sleep finished' return 'slept'
I had three parallel "sleep" requests and a forth request could manage Zope without problems... Maybe your long running methods are special? Dieter
On 30/10/01 10:49 pm, "Dieter Maurer" <dieter@handshake.de> wrote:
And I would still be interested in an explanation why two long running methods (not four) seem to be able to stall zopes http server on linux. I just checked with an "activeSleep" script:
from time import time
def sleep(sec): e= time() + float(sec) while time() < e: pass print 'active sleep finished' return 'slept'
I had three parallel "sleep" requests and a forth request could manage Zope without problems...
Maybe your long running methods are special?
Dieter
I was surprised to see Linux mentioned as having a problem with stalling the http server, as everyone who's running linux who has replied to this thread has said they've had no problems with multiple threads. For completeness, I tried the above as a python script on Solaris 8/Zope 2.4.1/python 2.1 - I could set the script off, but then couldn't do anything else on the server until the script had finished. But I think those requests had got through to Zope, as when the sleep thread had finished, Zope carried on with my other request. :( tone -- Dr Tony McDonald, Assistant Director, FMCC, http://www.fmcc.org.uk/ The Medical School, Newcastle University Tel: +44 191 243 6140 A Zope list for UK HE/FE http://www.fmcc.org.uk/mailman/listinfo/zope
Tony McDonald writes:
For completeness, I tried the above as a python script on Solaris 8/Zope 2.4.1/python 2.1 - I could set the script off, but then couldn't do anything else on the server until the script had finished. But I think those requests had got through to Zope, as when the sleep thread had finished, Zope carried on with my other request. :( Strange...
It would indicate a serious bug either Python or the Solaris thread library. Maybe, we should inform the Python experts and see whether they can shed some light into this... Unfortunately, the newsserver of my ISP is currently broken, such that I am unable to discuss this in c.l.p... Dieter
On 31/10/01 7:35 pm, "Dieter Maurer" <dieter@handshake.de> wrote:
Tony McDonald writes:
For completeness, I tried the above as a python script on Solaris 8/Zope 2.4.1/python 2.1 - I could set the script off, but then couldn't do anything else on the server until the script had finished. But I think those requests had got through to Zope, as when the sleep thread had finished, Zope carried on with my other request. :( Strange...
It would indicate a serious bug either Python or the Solaris thread library.
Indications seem to be pointing to a bug in the python implementation of threads under solaris, but I'm really not qualified to say that's the case.
Maybe, we should inform the Python experts and see whether they can shed some light into this...
Unfortunately, the newsserver of my ISP is currently broken, such that I am unable to discuss this in c.l.p...
Dieter
I set a thread off on c.l.p and got responses from Anthony Baxter (who said he may be able to look at this quite soon, with a view to getting it into python 2.1.2) and Tim Peters. Tim suggested some work with the python CVS, but my CVS-Zen is pretty low. My hope is that Anthony can get a 2.1.2 release out which I will install *immediately* and report back to the list... Tone. -- Dr Tony McDonald, Assistant Director, FMCC, http://www.fmcc.org.uk/ The Medical School, Newcastle University Tel: +44 191 243 6140 A Zope list for UK HE/FE http://www.fmcc.org.uk/mailman/listinfo/zope
Dieter Maurer wrote:
Oliver Bleutgen writes:
As I wrote before, it happens in mod_perl, it doesn't happen in zope2.3.3 on How does "mod_perl" do it? It is non-trivial...
I have no idea how theys do it, but with the perl script I posted in another
And I would still be interested in an explanation why two long running methods (not four) seem to be able to stall zopes http server on linux. I just checked with an "activeSleep" script:
from time import time
def sleep(sec): e= time() + float(sec) while time() < e: pass print 'active sleep finished' return 'slept'
I had three parallel "sleep" requests and a forth request could manage Zope without problems...
Maybe your long running methods are special?
No, but I found a explanation, ... well sort of, and the important point is that it has nothing to do with zope. It seems that NT limits these connections per process, because internet explorer behaves as I described, but using tcpdump one can see that the third request never reaches the server. Using another http client on the same machine. while the two IE windows are still loading. gets the zope pages without a problem. Using mozilla I can reproduce IE's behavior, if I use a pair of tabbed windows, but not if I open new navigator windows. Another proof that zope can't be at fault here is that even an apache server on the same machine is unreachable under the conditions depicted above. Ok, if anybody has a hint what happens here, I'm interested, but perhaps private mail would be in order, as it doesn't concern zope. cheers, oliver
Oliver Bleutgen writes:
.... No, but I found a explanation, ... well sort of, and the important point is that it has nothing to do with zope. It seems that NT limits these connections per process ... to 2 ... I am always pleased to learn about Windows peculiarities. It is so widespread, that there is a high chance that one is hit by them... Knowing beforehand can save a lot of anguish(?).
Dieter
Thomas B. Passin writes:
AFAIK, such a beast does not exist where you can stop a transaction from pressing a browsers stop button. Web is stateless, so a stop button on a browser cannot be connected to the servers understanding of finish the request or don't.
Yes and no. When you stop the browser, the socket connection closes. The next time the server tries to use that socket it gets an exception. Ideally in handling the exception the server should stop the thread in question, but who is to say that really happens? Ususally, Zope computes the complete response, before it starts to use the socket again.
This is necessary to provide correct exception handling. Would Zope start to send part of the response as soon it became available, then exception handling became difficult when later an exception is raised (because HTTP does not define exceptions). There is a single exception to the above rule: "RESPONSE.write" immediately start sending the data. After the first "write", there must no be an exception anymore for this request... It may be that the "write" recognizes that its socket were closed, but I fear, it is separated from the socket by a ZServer channel... Dieter
On 26/10/01 8:42 am, "Oliver Erlewein" <oerlewein@gmx.de> wrote:
Well I've tested your script with an old backup of Zope 2.3.2 on an Win NT SP 5 machiene. There are no problems. The script runs in one window and in the other I can surf the management screen. My Solaris can't do that.
Neither can mine.
On Solaris and on NT I could see your second problem. When I press cancel on the Browser the process/thread doesn't stop. Thats really a problem. I started your script twice and the machiene (NT) is nearly not usable anymore. But thats better than Solaris - there I can't start the process twice!
Same situation here.
For me I've prooven that there is something VERY WEIRD with the Solaris Zope. OK it might not be Zope but Python. As for me I need an answer / solution desperately!
I'm not going to guess whether it's a combination of Zope/Python/Solaris. I'm not a python-guru. What I am going to do is go over what I've tried. Warning: I don't have a solution :( I've scoured the python lists and found that there does seem to be a problem with threads where Python and Solaris are involved. This is present in *all* versions of python up until version 2.2b1 This is a test on my MacOS-X python2.1 installation (only the first bit is shown); 162[12:49]tonymcd@orion ~/zope % python /usr/local/lib/python2.1/test/test_thread.py creating task 1 task 1 will run for 9.2 sec creating task 2 task 2 will run for 0.5 sec creating task 3 task 3 will run for 1.7 sec creating task 4 task 4 will run for 7.5 sec creating task 5 task 5 will run for 0.8 sec creating task 6 task 6 will run for 9.0 sec creating task 7 task 7 will run for 4.7 sec creating task 8 task 8 will run for 3.1 sec creating task 9 task 9 will run for 6.6 sec creating task 10 task 10 will run for 0.1 sec waiting for all tasks to complete task 10 done task 2 done task 5 done task 3 done task 8 done task 7 done task 9 done task 4 done task 6 done task 1 done all tasks done Now try that under Solaris; 201 [12:52] % python2.1 /usr/local/lib/python2.1/test/test_thread.py creating task 1 creating task 2 creating task 3 creating task 4 creating task 5 creating task 6 creating task 7 creating task 8 creating task 9 creating task 10 waiting for all tasks to complete task 1 will run for 5.4 sec task 2 will run for 3.0 sec task 3 will run for 9.3 sec task 4 will run for 8.2 sec task 5 will run for 8.9 sec task 6 will run for 0.0 sec task 7 will run for 6.0 sec task 8 will run for 2.5 sec task 9 will run for 8.7 sec task 10 will run for 6.6 sec task 6 done task 8 done task 2 done task 1 done task 7 done task 10 done task 4 done task 9 done task 5 done task 3 done all tasks done (It would be interesting to see what happens under Linux or a Windows-OS I think). Ok, so 2.2b1 should be better... the relevant section from; http://sourceforge.net/project/shownotes.php?group_id=5470&release_id=57697 Is - Thread scheduling on Solaris should be improved; it is no longer necessary to insert a small sleep at the start of a thread in order to let other runnable threads be scheduled. So I downloaded the 2.2b1 source distribution and compiled it up under Solaris. I did the same test as above; 202 [12:55] % python2.2 /usr/local/lib/python2.2/test/test_thread.py creating task 1 creating task 2 creating task 3 creating task 4 task 1 will run for 5.7 sec task 4 will run for 1.7 sec creating task 5 creating task 6 creating task 7 task 2 will run for 7.5 sec task 3 will run for 4.2 sec task 5 will run for 1.2 sec creating task 8 task 6 will run for 3.9 sec task 8 will run for 2.5 sec creating task 9 creating task 10 waiting for all tasks to complete task 7 will run for 2.4 sec task 9 will run for 8.3 sec task 10 will run for 3.2 sec task 5 done task 4 done task 7 done task 8 done task 10 done task 6 done task 3 done task 1 done task 2 done task 9 done all tasks done Encouraging, but not fantastic (I think - my ignorance of threading is showing here). Ok, the acid test - I got a clean Zope 2.4.1 installation and did a; % python2.2 wo_pcgi.py installation. I then started Zope up (obviously with python 2.2) and got this; 208 [12:58] % ./start /usr/local/lib/python2.2/FCNTL.py:7: DeprecationWarning: the FCNTL module is deprecated; please use fcntl DeprecationWarning) /usr/local/lib/python2.2/FCNTL.py:7: DeprecationWarning: the FCNTL module is deprecated; please use fcntl DeprecationWarning) Etc. I also got a core dump from python2.2 Thinking it might be a 2.4.2 issue, I built that from scratch as well (using python 2.2). I got the same result.
Any ideas anybody? My primary guess is, that Solaris doesn't relese the threads after using them. I've tried a threaded Python script on my Solaris machiene and that had no problems. But I must confess I have no clue on how Zope Threading works. Therefore my test doesn't proove anything really.
I have no idea what might be causing this. I'm not a Solaris kernel hacker or anything like that. It seems that zope and python2.2 don't want to play anyhow (that's a little unfair - python 2.2 is a beta at the moment). So where am I? 1) I can run Zope 2.4.1 and python 2.1 happily - as long as I understand it's effectively single-threaded. 2) python 2.2 seems to have the fixes for threading problems under Solaris 3) I can't run Zope 2.4.1/2.4.2 and python 2.2b1 under Solaris at the moment ...and that's it. I don't expect Zope to be python 2.2 compatible until sometime after 2.2 final is released. If that sorts out my threading problem, I'll be a happy camper. The thing is *I don¹t know* if that will fix the problems I'm seeing.
By the way...it also shows how fast Zope really is because if I run "singlethreaded" and Zope can still serve a few thousand requests a day thats really not bad.
Yeah, this is ok, but one of our main sites is used by 50 students at a time - this is where the real single-threaded nature of Zope/Solaris is *painful* to watch. There must be *someone* out there who's using a Solaris Zope-based site that has got this fixed? Mustn't there? Anyone? (gad!, I sound like a lonely hearts ad.)
Oliver Erlewein
This is really getting me down :( Tone. -- Dr Tony McDonald, Assistant Director, FMCC, http://www.fmcc.org.uk/ The Medical School, Newcastle University Tel: +44 191 243 6140 A Zope list for UK HE/FE http://www.fmcc.org.uk/mailman/listinfo/zope
tony, zope and python 2.2 are not compatible at this moment. jens On Friday, October 26, 2001, at 08:13 , Tony McDonald wrote:
Ok, the acid test - I got a clean Zope 2.4.1 installation and did a;
% python2.2 wo_pcgi.py
installation. I then started Zope up (obviously with python 2.2) and got this;
208 [12:58] % ./start /usr/local/lib/python2.2/FCNTL.py:7: DeprecationWarning: the FCNTL module is deprecated; please use fcntl DeprecationWarning) /usr/local/lib/python2.2/FCNTL.py:7: DeprecationWarning: the FCNTL module is deprecated; please use fcntl DeprecationWarning)
Etc.
I also got a core dump from python2.2
Thinking it might be a 2.4.2 issue, I built that from scratch as well (using python 2.2). I got the same result.
Any ideas anybody? My primary guess is, that Solaris doesn't relese the threads after using them. I've tried a threaded Python script on my Solaris machiene and that had no problems. But I must confess I have no clue on how Zope Threading works. Therefore my test doesn't proove anything really.
I have no idea what might be causing this. I'm not a Solaris kernel hacker or anything like that.
It seems that zope and python2.2 don't want to play anyhow (that's a little unfair - python 2.2 is a beta at the moment).
On 26/10/01 1:25 pm, "Jens Vagelpohl" <jens@zope.com> wrote:
tony,
zope and python 2.2 are not compatible at this moment.
jens
Thanks for the clarification Jens - that's saved me quite a bit of time! :) Lest people think I'm getting steamed up about this issue - I'm not at the moment, I have confidence that this threading issue *will* get sorted. My main problem is that my own competence in the areas that might make a difference is pretty limited, so I can't help out that easily. But I really look forward to having a multi-threaded ZEO setup firing on all 6 of the processors on our Sun-iron ;) Many thanks, Tone. -- Dr Tony McDonald, Assistant Director, FMCC, http://www.fmcc.org.uk/ The Medical School, Newcastle University Tel: +44 191 243 6140 A Zope list for UK HE/FE http://www.fmcc.org.uk/mailman/listinfo/zope
It'd be pretty interesting if Anthony Baxter was able to run your tests. I know he's got a serious set of Solaris machines. Alas, I'm not sure what to do either...it would seem that we need a Solaris threading expert. Oliver Erlewein wrote:
Well I've tested your script with an old backup of Zope 2.3.2 on an Win NT SP 5 machiene. There are no problems. The script runs in one window and in the other I can surf the management screen. My Solaris can't do that.
On Solaris and on NT I could see your second problem. When I press cancel on the Browser the process/thread doesn't stop. Thats really a problem. I started your script twice and the machiene (NT) is nearly not usable anymore. But thats better than Solaris - there I can't start the process twice!
For me I've prooven that there is something VERY WEIRD with the Solaris Zope. OK it might not be Zope but Python. As for me I need an answer / solution desperately! Any ideas anybody? My primary guess is, that Solaris doesn't relese the threads after using them. I've tried a threaded Python script on my Solaris machiene and that had no problems. But I must confess I have no clue on how Zope Threading works. Therefore my test doesn't proove anything really.
By the way...it also shows how fast Zope really is because if I run "singlethreaded" and Zope can still serve a few thousand requests a day thats really not bad.
Oliver Erlewein
-- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
participants (9)
-
Chris McDonough -
Dieter Maurer -
Jens Vagelpohl -
Oliver Bleutgen -
Oliver Erlewein -
Paul Zwarts -
Paz -
Thomas B. Passin -
Tony McDonald