[Zope-dev] A thought for 2.6 about various leaks and memory problems

[Shane Hathaway]

Anthony Baxter wrote:
>>>>"Adrian Hungate" wrote
>>>>
>>moved to a different thread or earlier, before the fork, so that we could
>>simply kill senile threads without killing the entire shooting match?
>>
> 
> unfortunately apache does this with seperate processes, not threads.
> 
> memory corruption and leaks aren't solved by offing threads, unfortunately.
> 
> the equivalent would be to start a bunch of single threaded zeo clients on
> a machine, with a loadbalancer in front of them, and periodically off one.
> 
> the only decent loadbalancers I've seen, however, are pretty heavy weight,
> flaky, limited in functionality, or some combination of all three.
> 
> also, the start time for a new ZEO client is non-trivial.

I actually think this is a great idea, but none of my friends here at ZC 
seem to agree.  Nevertheless I've been collecting up some data and 
resources that should help anyone interested in moving this idea forward.

First, you'll need a load balancer.  Here is a lightweight one that 
sounds like a good match for Zope, although I haven't tried it:

http://siag.nu/pen/

It actually tries to match clients with servers, which should lead to 
more ZODB cache hits, therefore lower memory consumption.

Second, you'll need some ZEO clients.  I have an independent ZODB 
application that relies on ZEO, and its start time is about 1 second, 
even though it accesses a 250 MB Data.fs.  The only reason a Zope client 
takes so long is it reads and catalogs all the help files on startup! 
Figure out how to disable that silly code and startup time will be much 
lower (though not 1 second, since there's a lot of Python code to load).

This arrangement would have a lot of benefits:

- The global interpreter lock would no longer be an issue, so you'd be 
able to take better advantage of multiple processors;

- A failed request would never affect other users;

- You'd be able to use new Zope releases in production sooner, since 
"absolute" stability would be less of a requirement.

One thing to consider is that Apache might be technically *less* stable 
than Zope.  Most Apache modules are written in C and are not written by 
the core Apache hackers, providing a lot more opportunities for pointer 
errors than Zope does.  But since Apache forks instead of using threads, 
it takes maximum advantage of the stability provided by the operating 
system.  So as a whole, it is more stable.  Can you imagine how stable 
Zope might be if it used a similar strategy?

Shane