[Zope] Zope Scalability

[John Snowdon]

>-----Original Message-----
>From: zope-bounces at zope.org [mailto:zope-bounces at zope.org] On 
>Behalf Of Jens Vagelpohl
>Sent: 07 October 2005 09:04
>To: Zope ML
>Subject: Re: [Zope] Zope Scalability
>
>
>> As an aside, we find management of ZEO clients much easier 
>if each ZEO
>> client of a particular system shares the same products and external
>> methods via an NFS share. That way we can untar one product and  
>> push it
>> out to all of the clients simultaneously.
>
>I'd be a little afraid of creating a single point of failure with  
>NFS. I have used setups like that before, but personally prefer some  
>simple distribution mechanism instead.
>
>If you use CVS or SVN for your software you could write simple SSH  
>scripts to visit hosts and do a cvs/svn up in the right place and  
>then restart the clients. rsync is a good candidate as well.
>
>jens
>

We don't have anything that complex :-) Most sites that we host probably
have less than 20 external python methods (a lot have none at all!),
with common products shared by all the sites installed on each system in
the master zope lib/python/products directory structure. The majority of
complexity is in each systems ZODB.

All of our boxes are on a private network, on the same gbit switch as
the ZEO server, so performance/service interruption, network timeouts
etc.. is never a factor. The NFS shares (products, extensions, file
upload areas[uploads via zope, and these areas are then served back out
via Apache] and user home directories[again, using our ldap systems for
authentication]) are from the same ZEO server (primary storage is
handled by a multi-terabyte SATA). We're running about ~50 individual
Zope systems at the moment (all as ZEO clients, many have multiple ZEO
clients across several nodes, with incoming requests load balanced via
Pound).. and I must say, this setup is way better than our old Sun E3500
that used to (try) to handle all of this! ZEO is the way to go for
sure.... though we are now hitting problems when trying to integrate the
Internet2's Shibboleth single sign on authentication system into a
load-balanced setup... but that's a story for another time :-)