<moved just to zope-dev instead of both zope3-dev and zope-dev>
Btw: does this also
- decrease memory usage during delivery time?
Probably. I haven't done any work to prove it, though. It can theoretically prevent ZODB/ZEO cache "thrashing", where large static objects might consume a significant portion of the ZODB cache at any given time if you have a large enough "working set" of static content and lots of consumers of different parts of that working set. I believe also that the ZODB object cache stores copies of the same objects for each active connection, so presumably if you've got 4 connections and 4 people download the same content at exactly the same time, you presumably wind up with 4 copies of the same objects representing that content in memory at once. Optimally, if you were able to serve the content mostly from disk, you'd have only one copy of the content in one thread's cache at any given time and the other threads would never access the ZODB for the content at all. And at some point, once the disk-cached content had expired from the ZODB cache, you'd have no memory consumed by cache at all for that content, freeing cache memory to deal with truly dynamic things.
- provide a solution of having too many threads consumed up by long-taking downloads?
This isn't currently an issue in Zope 2 (and presumably not in Zope 3 either, although I haven't looked). I thought this was the case too up until a couple of days ago, but Jim let me in on the fact that Zope worker threads aren't really tied up at all during "slow" downloads (at least for large File/Image objects) for longer than it takes to retrieve the data out of the ZODB, because the machinery which the RESPONSE.write protocol consumes spools large chunks of data out to a tempfile. This operation doesn't block based on consumer speed, so the worker thread finishes as fast as it can write to the tempfile. Medusa alone is responsible for delivering the data out of the tempfile to the consumer afterwards, but that happens in the main thread and is transparent to Zope itself. Medusa/asyncore is very fast and consumes very few resources, so serving many copies of this content isn't much of a hit to Zope itself. - C