[Zope] Zope, Apache/NT, Reliability issues

[Martijn Pieters]

On Thu, Jun 08, 2000 at 07:25:15PM -0300, Fabio Akita wrote:
> I´ve used the ZServer in stand alone mode and I also have implemented
> the easy Proxy Reverse trick in Apache. I will try FastCGI and PCGI as
> soon as possible, but I have some doubts now.
>
> My test platform is a Windows NT 4 running Apache 1.3.12. The first
> doubt comes to the fact that I could not find the pcgi module for NT (I
> do not have any kind of C compiler, so I´ll be very glad if anyone know
> a binare version). So I´d like to know where can I find informations
> about installing Zope using PCGI in an NT Apache installation.

It could be someone else has already compiled it and used it.

> The second doubt: what exactly are the differences of running it in PCGI
> mode or in ZServer? I do understand the concept of forking a process and
> interfacing a web server and a process through a CGI interface as PCGI
> and I also understand the fact of the multithreading feature in ZServer.
> 
> Basically it would mean that each connection request will fork a new
> Zope connection and then maintain it in some kind of a connection pool
> (as databases do)? Or will there be only one process running Zope and a
> queue of requests to access it? What are the performance impacts, what
> are the hardware (memory/CPU) impacts? Personally I do not like the
> concept of CGI but know nothing about the Persistent CGI concept.

PCGI passes on requests to Zope, where Zope can handle multiple requests at
the same time. Basically, requests are handed over to ZServer ass if the
request came in directly. PCGI takes some care of waiting for ZServer to
become available if it is congested.

So, there is one Zope instance running that can listen to normal HTTP
requests, FTP requests and PCGI requests (any combination of that). The PCGI
CGI's are fielded on requests coming though Apache and hand back the results
to the client.

> And what about the method of "masquerading" the ZServer through Apache?
> I have read solutions using the Rewrite module and the Proxy module, but
> it actually means (roughly speaking) that if there are 10 requests
> made to Apache then it will make 10 requests to ZServer so, considering
> only the reliability issue of the server even if Apache can handle
> millions of requests per second, the ZServer would fall down much faster
> than that so I cannot see any advantage of using Apache in front of it.
> Of course I understand the other advantages of Apache as it´s many
> configuration options, robustness as a web server, etc, but can the
> ZServer stay up and running in pair with Apache? Maybe there´s any way
> to configure Apache to cache the pages -- as a Squid would -- so it can
> "filter" the requests and low the requests level that it will do to
> ZServer?

People generally use Apache for combining Zope with other content. Zope is
good at serving dynamic content, Apache at static, so if you serve Zope behind
Apache, you can mix and match. Also, when you have existing CGI, PHP or other
Apache dependant content that you want to make available from the same base
URL, you will need to use Apache in front of Zope.

You can, IIRC, use tge ProxyPass trick together with caching as well,but I
have no experience with that. There is one big disadvantage to using ProxyPass
at the moment, which is that you need to use the SiteAccess product to make it
work correctly. The SiteAccess product has some known issues and causes
regressions in parts of Zope, like the ZCatalog. These issues _shold_ be
solved with the upcoming 2.2 release of Zope.

> And what about it´s object oriented database? I also have some doubts
> about it. I worked a lot with relational databases as MS SQL and MySQL
> but never tried to study an OO approach to DB. How fast it is? How much
> requests can it handle without hanging, collapsing or corrupting data? I
> mean, anyone tried to do some study of a database that changes everytime
> and have queries everytime, I mean, searches in a database where it´s
> data changes constantly (searching a static database is much different
> than searching on a mutable one). Row level locking, transaction,
> consistency, etc, all these concepts apply here? Can it be substituted
> by a traditional relational database and have it´s contentes interfaced
> to "looks like" object oriented?

The ZODB, Zope's Object Database, is an integral part of Zope. As soon as you
look at Zope through the management interface, you are looking at objects
stored in the ZODB. Zope is inherently OO, and you generally use object
instances to build your site.

The ZODB is transactional, is optimized for high reads, low writes, and takes
care of access conflicts not by locking, but invalidating all connections that
use an object that has been altered by another connection. Zope reacts to this
by retrying the requests whose connection was invalidated. Because everything
is transactional, this works great. There is detailed documentation on ZODB
available at:

  http://www.zope.org/Documentation/Developer/Models/ZODB/

The default Storage component is FileStorage, which provides Undo and support
for Versions, and which stores all data in one file (easy backup). Other
Storage components are available, like one that stores data in Berkeley DB
(but doesn't support Undo and Versions, IIRC), a DemoStorage which layers over
another Storage and keeps all changes in memory, it doesn't ever write them,
and soon ZEO will be available, a Storage that enables you to share a Storage
on a Storage server, effectively providing scalability, availability and
distribution:

  http://www.zope.org/Products/ZEO/ZEOFactSheet

With SQL Methods and Database Adapters you can of course still integrate
legacy data from SQL RDBMs into your app. Object storing a la WebObjects isn't
supported out of the box, but could be built on top of the Zope framework.

-- 
Martijn Pieters
| Software Engineer    mailto:mj@digicool.com
| Digital Creations  http://www.digicool.com/
| Creators of Zope       http://www.zope.org/
|   The Open Source Web Application Server
---------------------------------------------