Zope is great at serving up dynamic content. But what about static content, such as images or large media files? Zope is great at managing such content (even without the higher level content management tools available), but it will never be as fast as a pure file HTTP server such as Apache.
Enter Zope's cache management system. This is a small framework within Zope to deal with caching and has a simple notification system for when cached objects change. Different cache managers can be plugged in. Two that ship with Zope are a memory cache manager, and an HTTP cache manager. The latter adds headers to the response for cached objects so that downstream cache managers (such as Squid) will cache according to a common policy. But other cache managers may be plugged in as long as they implement the Cache Manager interface (these are early examples of the component style development that dominates Zope 3). One we've been deploying to some success is FSCacheManager.
FSCacheManager does something interesting. It dumps cached objects out to disk where they may be served up by Apache or IIS, without requiring custom objects (such as FSImage, which stores images on disk instead of in Zope's object database) or changes to common Zope URL API's, such as absolute_url(). Using rewrite conditions in Apache, it can be set up so that an image gets fetched out of Zope only when there is no file system representation. When an image or other cached object is updated, the cache management invalidation machinery clears the marked file out of the file system, and it's put back there the next time an HTTP request is made for that object.
We've extended this concept to deal with an application we wrote that - for better or worse - stores its user managed images in MySQL. The images are retrieved through a Python Script that uses traversal_subpath that lets us have a url like data/SOME_UNIQUE_ID. Since these images are not being managed by Zope's machinery, we put in some explicit calls to a similar FS Cache type component that we wrote that also dumps files out to the file system to be served by Apache or other HTTP servers. Again - this speeds things up immensely. If an image seldom changes, why run an SQL query every time for every thumbnail on a page? Especially when you can make the URL uniform and independent of where it's ultimately served out of?
What this means is that most of the time, all that is being retrieved out of Zope is the dynamic page template. It's an effective way of moving a lot of the static data out to where it can be served faster without losing out on the many benefits of Zope.