<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

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to