[Zope] Zope Scalability

[Jens Vagelpohl]

> ZODB size
> What is the maximum size of this file and/or maximum object ID?
> => just how many objects can the zodb hold? millions? tens of  
> millions..?? billions...??? I have a feeling we'll run out of ram  
> long before actually hitting the limit but it'd be nice to know the  
> theoretical top limit.

There is no answer to this question because it cannot be answered. No  
one has come against a "limit" yet as far as I know. Hitting RAM  
limits depends on the settings you apply to the Zope/ZEO instance(s)  
that serve(s) the content and how much RAM you put in, you can  
control ZODB memory cache size via zope.conf. No one sets up Zope so  
that the whole ZODB is loaded into memory, if that's what you mean.


> Zeo and Cataloging
> If I have my site on one server and ZCatalog (using TextIndexNG) on  
> another server (connected by ZEO) where does the actual index  
> operation occur? Do just the results get propogated to the catalog?

The actual indexing operation happens on the Zope/ZEO instance, and  
the resulting database changes are applied to the respective storage  
where the catalog resides when the transaction commits.


> LDAP Authentication
> I understand that can use the LDAPUserFolder Product to provide  
> authentication against an ldap server. Could I throw,say, 50000+  
> users at zope using this system?

I see no problems with that. It doesn't matter one bit to the  
LDAPUserFolder (or the Zope security machinery) how many user records  
you have in the DIT. If there are any slowdowns as the number of user  
records increases it is most likely due to misconfigurations on the  
LDAP server itself, such as bad indexing or overcomplicateed/ 
unnecessary access control checks.


> Load Balancing and Cookie Based Sessions
> Currently we use cookie based sessions via cookie crumbler  
> presumably in a load balanced server setup we'd have to host  
> acl_users ona  ZEO'd izope instance somewhere on the backend?

Cookie crumbler has nothing to do with sessions. All it does is set/ 
read a cookie with credentials and then "fake" regular HTTP  
authentication with this data. There is no state information being  
stored on the server side, so in a ZEO setup it does not matter which  
ZEO client you hit.

jens