The solution to your problem is to use ZEO. This allows any number of Zope
application servers to share a single ZODB storage. The app servers and
storage server do not need to be on the same machine, just connected via a
This is the standard way to make Zope scale for large applications.
To solve your use, you would just run each Zope app server single threaded.
You could run as many of these single threaded, identical Zope app servers as
you like. You would then need some sort of load balancer in front of it.
Although I haven't used it myself, there is a python-based software load
balancer named Pound that could be used. There are also various other
software and hardware load balancers available.
In general though running many single threaded Zopes will be more resource
intensive then running fewer multi-threaded Zopes. OTOH, running it this way
would be potentially beneficial when running on a multi-CPU machine due to
the Python global interpreter lock.
On Friday 22 November 2002 08:45 am, Carlo Giomini wrote:
> Dear all,
> because of reasons that would be boring to explain,I have the following
> requirement for my site:
> I need Zope NOT to run as a single-process multithreaded application (as
> it does by default) but instead to run as a pool of processes (each one
> single-threaded); those processes should share the same Data.fs database.
> Shutting down the threads is trivial (using setNumberOfThreads function)
> but the tricky part (for me, at least) is to keep the ability to serve
> many requests concurrently. Since I discarded threads, the only other
> way is to have many Zope instances running (as independent single-threaded
> processes) and a sort of dispatcher process (proxy server?) that listens
> for incoming HTTP connections from the outside world and dispatches it
> to one of the Zope instances (performing also the reverse operation,
> of course). The dispatcher should also care to create (and destroy)
> dynamically the Zope instances, according to the load of traffic (number
> of requests per second). Is there any way to do so without having to
> implement the dispatcher (proxy) process from scratch?
> I have been considering FastCGI as a solution, since it allows a web
> server (say Apache) to spawn many persistent processes to execute
> the CGI requests it receives but, to my disappointment, I noticed
> that the mod_fastcgi directive used in all the howtos on the subject
> is FastCgiExternalServer, which does not allow for the CGI app to be
> created by Apache itself. FastCgiExternalServer relies on a 'manual'
> external starting of the CGI app, which can only be ONE process then!
> There's another directive (FastCgiConfig) that lets Apache spawn the
> process(es) that execute the CGI app, the question is: can it be used
> with Zope instead of FastCgiExternalServer? Since (Fast)CGI apps use
> pipes to communicate with the web server (when they run on the same
> machine), the problem becomes how to pass a web request directly to
> the Zope publishing mechanism over a pipe, bypassing the Zope's HTTP
> server. How can I do that? Someone out there has ever tried to do so?
> Also, how does Zope support having multiple instances of it sharing the
> same database (Data.fs)? One solution could be having many ZEO clients on
> the same machine, but I wonder if it is possible to create those clients
> dynamically (to scale according to the load of incoming requests) or
> rather they can only be installed 'statically' (not at run-time, I mean).
> Thanks in advance for any help you can give, regards,
> Zope-Dev maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -