On Fri, 2004-04-09 at 18:02, Paul Winkler wrote:
> That's easy. LocalFS, CMFCore.FSFile, and ExtFile 1.1.3 all read the
> entire file into memory before sending anything back to the client.
> That's why ExtFile 1.4 is so much better - it uses RESPONSE.write()
> with 64k chunks.

I just don't understand why it's a third the speed of ExtFile 1.1.3 at
the largest file size.

> > overhead; products would be better off to do a direct RESPONSE.write if
> > the total file size was under 128k (as evidenced by the fact that the
> > iterator-based products are slower at small file sizes).
> Yeah, my patches were very minimal. They could easily be extended to
> only use iterators for larger content-length.
> I'll do that, add a working LocalFS and another thingie I heard about 
> yesterday into the mix, and do another round of benchmarks maybe tomorrow.


> Fine and dandy, but I'd still really love to see what can be done
> about ZEO. Caches only prevent ZODB access for stuff that's in the cache...
> Sooner or later, some user will get a cache miss and that poor soul will 
> see speed go down by an order of magnitude or two.  Ouch.

Since it's only on the first request, I don't care *too* much (although
I do care) how long it takes to slurp across ZEO, especially because
blobs rarely change in normal usage and thus would be seldom evicted
from FSCacheManager's cache.  It's just likely "more bang for the buck"
in the common case to prevent the ZODB read in the first place than to
try to pick through and speed up ZEO's (very subtle) code.  That said,
go for it!

- 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