A number of folks have posted about Zope lock up issues. It is very important to me to resolve this issues.
When ZServer occasionally locks up for me, it usually because I did something that's causing the publishing process to hang. This happens when you are coding external methods or Python products and make certain kinds of mistakes that put Zope in a loop.
I finally tracked down my problem. Some of the python code that I have written was falling into an infinite loop, and it had nothing to do with Zope. Of course, given how cool we all agree that Zope is, shouldn't it prevent these stupid programming problems :-) One question, though. Since ZServer is multithreaded, should just the thread that is handling the python code that falls into the loop get stuck? Shouldn't the other threads keep on working? Or does the one thread simply consume all of the available cycles? Thanks for any insight on this, and thanks to all for contributing to Zope. -jason ------------------ Jason Abate jason@hostway.com Hostway, Inc.
At 04:33 PM 8/12/99 -0500, you wrote:
A number of folks have posted about Zope lock up issues. It is very important to me to resolve this issues.
When ZServer occasionally locks up for me, it usually because I did something that's causing the publishing process to hang. This happens when you are coding external methods or Python products and make certain kinds of mistakes that put Zope in a loop.
I finally tracked down my problem. Some of the python code that I have written was falling into an infinite loop, and it had nothing to do with Zope. Of course, given how cool we all agree that Zope is, shouldn't it prevent these stupid programming problems :-)
Ahh, if only Python could read our minds. I guess we could think about some kind of publishing request time out. Hmm. This sounds ugly... At any rate we could fix ZServer so that if it couldn't get a request serviced in a certain amount of time it would return an appropriate error (408?) instead of just waiting forever...
One question, though. Since ZServer is multithreaded, should just the thread that is handling the python code that falls into the loop get stuck? Shouldn't the other threads keep on working? Or does the one thread simply consume all of the available cycles?
Usually it takes five requests to hang ZServer ;-) By default Zope uses 4 publishing threads. Each time you request a URL that put Zope in an infinite loop, there goes one more publishing thread. So after 4 evil requests you're locked up. -Amos
Amos Latteier wrote:
Usually it takes five requests to hang ZServer ;-) By default Zope uses 4 publishing threads. Each time you request a URL that put Zope in an infinite loop, there goes one more publishing thread. So after 4 evil requests you're locked up.
DANG !!! That means that under a heavily used Zope server, some requests (N-4) are waiting for their turn to be executed? It doesn't fork multiple processed on request as Apache for example? is there any parameter where the number of publishing threads could be increased? Because this could be an important loss of performances. I saw that www.zope.org is powered by Zope. Have you experienced slow access to the site sometimes? Let's put it in another way! Would it be Zope able to support (on a good and strong hardware) a Yahoo like server? -- Constantin Teodorescu FLEX Consulting Braila, ROMANIA
At 06:04 AM 8/13/99 +0000, Constantin Teodorescu wrote:
Amos Latteier wrote:
Usually it takes five requests to hang ZServer ;-) By default Zope uses 4 publishing threads. Each time you request a URL that put Zope in an infinite loop, there goes one more publishing thread. So after 4 evil requests you're locked up.
DANG !!!
That means that under a heavily used Zope server, some requests (N-4) are waiting for their turn to be executed?
Unlikely. It's more complex than this. In fact 4 is a reasonable number under most circumstances since most of the time is spent receiving the requests and sending back the responses which happens asynchronously. For example, at any given time, you may have something like 30 requests being received, another 30 responses being returned and 2 or 3 publishing threads running. However, if you wish you can control how many publishing threads run at once.
It doesn't fork multiple processed on request as Apache for example?
Not at all. You may wish to read up on Medusa's async sockets architecture which is actually quite efficient. Threading, forking and async approaches all have tradeoffs, but Medusa is no slouch! Find out more at http://www.nightmare.com/medusa
Let's put it in another way! Would it be Zope able to support (on a good and strong hardware) a Yahoo like server?
To host one of the say 10 most popular sites on the net you're going to have to do a lot of special things. For one, you cannot serve a site like this off a single machine no matter what app server your running ;-) I think that the going wisdom is that you can expect to get about a million hits a day from a reasonably cheap box running Zope. In any event performance figures are a subjective and slippery subject... -Amos P.S. DC will probably be making an announcement fairly soon which should significantly address scalability issues.
participants (3)
-
Amos Latteier -
Constantin Teodorescu -
jason＠brahms.siteprotect.com