[Zope] How to run Zope?

[Joel Burton]

On Tue, 6 Mar 2001, Dario Lopez-K=E4sten wrote:

> Hello!
>=20
> we are trying to figure out the best way to run Zope behind apache.
>=20
> Background:
>=20
> We have a machine that will run Zope. Zserver is running all the time.
> We want to use Apache to serve Zope and other static/php/perl things as
> well. We also need to use SSL with Zope and apache seem a better choice
> thatn using SSL-enabled Zserver (more proven, more stable).
>=20
> So, question:
>=20
> What is the recommende way to server Zope behind Apache, with URL-rewriti=
ng,
> possible multiple site-hosting, etc.
>=20
> Is it as a CGI? If so which one?
> Is it using Apache acting as a proxy to Zope?
> Is it using any of the available Apache-Zope modules?
>=20
> or something else?
>=20
> we are confused; we have read the howtos available, but we are not able t=
o
> understand the proper way. Obviously there are different requirements for
> differents scenarios, but it is hard to understand which senario applies =
to
> what situation.
>=20
> Also, we do not fully understand the consequences of the varioius methods
> available.
>=20
> Any help is as usual appreciated.

[ I did a bit of research and thinking about this recently, but I'm not a
Master Zopista yet, so, list, if I've make an error, please point out. ]

My own thoughts:

1) ZServer is multi-threaded, and I'd like to keep it that way for
performance reasons.

2) Running ZServer by itself is a good idea if you have only Zope
site(s) (you can easily do virtual domains w/a ZServer only solution using
SiteAccess product); if you have lots of PHP code, something else needs to
serve the PHP.

3) PCGI (persistent CGI) is easy to set up, and you can 'get the Zope out'
of your URLs by using rewriting. It does involve spawing a very thin CGI
program w/each request, but performance should still be very good. It is
not, however, a solution that keeps the threaded nature of ZServer.

4) Apache + ProxyPass lets you just hand your Zope requests back to
ZServer using ProxyPass requests. It's *very* easy to set up and
understand, and requires no other programs. It keeps ZServer
multithreaded. Small downside: normally, when Zope gives you the client IP
address, it gives you the Apache IP, not the client user. This is from
ProxyPass, not Zope, you can easily compile a version of Zope that has a
patch to hand the real client IP in a different environmental variable.

[ Personally, I never cared about this -- client IP addresses are a rather
poor security check, and given the amount of proxying and forwarding that
goes on nowadays, they're not a good indicator of a unique visit,
either. In any case, since Apache can do all your logging, and it knows
your real client IP, you're still getting perfect logs. ]

5) There are some solutions to serve PHP/Perl from Zope, where Zope can
spawn a Perl/PHP process. I'd consider this only if you have one or two
legacy scripts that aren't used much.

6) Our solution? We only have a few PHP/Perl things (a groupware app for
staff use only, mailing list mgmt software, etc.) We've created a few
domains: www.zzz.com (ZServer), mail.zzz.com (PHP groupware),
lists.zzz.com (mailing lists). A simple server is dirt cheap nowadays for
us, and setting up a small different box running Linux Apache and serving
the PHP/Perl stuff seemed a smaller price than running both on the same
server.)

7) If I had to pick a shared solution, I'd pick ProxyPass.

8) In any case, you can always use Apache to proxy your results, or use an
external proxy-thingie, like Squid. The problem is that many Zope pages
contain a mix of semi-static things (like perhaps your home page) that
could be cached for several hours, and some always-changing things (like
the little bit that says if someone is logged in, or what the top news
story is, etc.) This is not a fault of Zope, but a pitfall in simple
one-page-caches-all model.

You can fix this by using frames (so that each frame is either cached or
not cached).

In our case, we don't get so much traffic that web saturation is our
problem. Our problem is that many pages have many DB queries, Zope
searches, etc., that they can be a bit slow. What we want is for Zope to
cache the results of a particular DTML method or Python script, and keep
using this result for x seconds, hours or days. The page handed to end
user is still dynamic, but we can assemble the components faster. This is
now easily done w/the RAM cache.


Good luck! Go forth and be Zope,

--=20
Joel Burton   <jburton@scw.org>
Director of Information Systems, Support Center of Washington