[Zope] Performance sending static content?

[Chris McDonough]

> 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 """