I was wondering -- are there any performance problems associated with using Zope to serve images and other large static content?
Zope can serve about 40 - 100 simple requests per second on stock Intel hardware. Compare this to Apache which is able to do about 200 - 700 requests per second on same. Zope's not as fast as static webservers, nor does it really want to be. It wants to rely on caching to help it out.
In the Java world, we have the Servlet container, which serves Servlets and JSP pages (the most popular choice probably being Tomcat). However, you try not to have your Servlet container serving your graphics -- instead, let Apache do that as a front-end to Tomcat, and have Tomcat only invoked to serve the dynamic HTML pages.
This is often done in the Zope world too. Let Apache or another webserver serve static graphics, let Zope generate dynamic HTML. Another populat strategy is to let Zope generate everything but to use Squid, mod_proxy, or what-have-you as a reverse caching proxy in front of it.
Where it gets complicated, is when you want your application (be it in Java, Python, or whatever) to manage security etc. There is no good solution to this in the Apache/Java world (e.g. no way to let your Java app evaluate security, but let Apache do the actual data serving, assuming the user passes the authorization test).
For graphics only, this generally isn't a problem. For a mix of static and dynamic HTML where you want to serve static HTML from Apache and dynamic HTML from Zope, it can be. This is actually a pretty simple problem. If you want a visit to a URL to show something different to every user depending on their auth credentials, then unfortunately you need to dynamically generate each differing page. If the page needs to be generated dynamically, it's easier to let Zope do that than to try to persuade Apache to do it with SSI or something. Unfortunately this defeats some benefits of caching. I think that most frontend caches try hard to prevent a cached page being shown to a user if that user requests the page with an Authorization: header in the request. For example, if you were using a caching reverse proxy to handle requests to a backend Zope server, if a request came in with an Authorization header that denoted that the request came from "chrism", you wouldn't want to show the user the page generated for "fred". So you let the request make it through to the system which dynamically generates a new page. I think Zope's cache manager software lets you cache different pages represented by the same URL based on auth credentials, but the docs for it are bad enough that I can't quickly tell. :-( If you find out, let me know. There have been various attempts to allow some parts of pages to be cached while dynamically generating other parts. It's hard.
How does Zope deal with this? And if the answer is, "let Zope serve your images", then does Zope tend to be as noticably slow in serving images as, say, Tomcat in Java?
Zope is not particularly slow, nor is it particularly fast at serving any sort of content, be it HTML, images, whatever. It's almost always a good idea to put a reverse caching proxy in front of Zope to cache static data. There's very little downside and a lot of upside. PS - please try not to send HTML mail to the maillist. Thanks! ---------- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com """ Killing hundreds of birds with thousands of stones """