On Tue, 6 Mar 2001, Dario Lopez-K�sten wrote:

Hello!

we are trying to figure out the best way to run Zope behind apache.

Background:

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).

So, question:

What is the recommende way to server Zope behind Apache, with URL-rewriting, possible multiple site-hosting, etc.

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?

or something else?

we are confused; we have read the howtos available, but we are not able to understand the proper way. Obviously there are different requirements for differents scenarios, but it is hard to understand which senario applies to what situation.

Also, we do not fully understand the consequences of the varioius methods available.

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, -- Joel Burton <jburton@scw.org> Director of Information Systems, Support Center of Washington