Re: [Zope-dev] proposal: serving static content faster
On Wednesday, March 24, 2004, at 04:09 AM, Chris McDonough wrote: but the adminstrative headache of selectively associating content with "the right" cache manager just seems like too much of a practical burden to make people bear. Having just done this again for 3 sites, I heartily agree - headache! ;) It would just be way easier to let people be "sloppy" about it by: a) letting people associate content with multiple cache managers. b) creating a cache manager multiplexer (which might expose a bit of policy for dynamic cache selection). c) creating a different cache management architecture that provided caching services based more on policy than on a direct association (ala CMF's CachingPolicyManager). But I really don't have the time to do the work implied by any of the enumerated options. I'll hopefully be able to wait until somebody else gets suffiently indignant about the situation and takes it upon themselves to implement one of the alternatives. ;-) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] proposal: serving static content faster
> 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] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] proposal: serving static content faster
On Wed, 2004-03-24 at 03:25, Jamie Heilman wrote: > Chris McDonough wrote: > > http://dev.zope.org/Wikis/DevSite/Proposals/FasterStaticContentServing Darn, I always forget that cross-posting is bad due to replies to both lists. Sorry. I've limited this reply to the zope-dev list. > Sounds good. WRT your comments on the need for a cache multiplexer so > one can handle the case of HTTP cache control headers & opaque > server-side caches working together--I'm really wondering if a better > solution isn't to just remove the cache header manipulations from > where they are now (in a seperate product) and integrate it more into > an API any where object [that wants to] can use. HTTP cache control > really is a protocol level thing, and the way its bundled as an add-on > service right now feels pretty awkward. I agree... it kinda feels like the services which actually get Zope involved in caching data (RAMCacheManager) should be distinct from those that let other systems know they should cache data (HTTPCacheManager). This is mostly because the need for caching something in an upstream HTTP cache isn't mutually exclusive with potentially wanting to cache it locally too. Well, I guess literally, it probably is (because you probably wouldn't bother caching something in Zope if you could just let Squid do it, at least in the common case), but the adminstrative headache of selectively associating content with "the right" cache manager just seems like too much of a practical burden to make people bear. It would just be way easier to let people be "sloppy" about it by: a) letting people associate content with multiple cache managers. b) creating a cache manager multiplexer (which might expose a bit of policy for dynamic cache selection). c) creating a different cache management architecture that provided caching services based more on policy than on a direct association (ala CMF's CachingPolicyManager). But I really don't have the time to do the work implied by any of the enumerated options. I'll hopefully be able to wait until somebody else gets suffiently indignant about the situation and takes it upon themselves to implement one of the alternatives. ;-) > But anyway, thats a > digression from the main thrust of your let them eat producer > proposal, which I think is a good idea in general. Thanks, - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] proposal: serving static content faster
+1 from me I think its a great idea, I also agree with Jamie about HTTP cache control feeling awkward at the moment not sure how it could be better though Jamie Heilman wrote: Chris McDonough wrote: http://dev.zope.org/Wikis/DevSite/Proposals/FasterStaticContentServing Sounds good. WRT your comments on the need for a cache multiplexer so one can handle the case of HTTP cache control headers & opaque server-side caches working together--I'm really wondering if a better solution isn't to just remove the cache header manipulations from where they are now (in a seperate product) and integrate it more into an API any where object [that wants to] can use. HTTP cache control really is a protocol level thing, and the way its bundled as an add-on service right now feels pretty awkward. But anyway, thats a digression from the main thrust of your let them eat producer proposal, which I think is a good idea in general. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] proposal: serving static content faster
On Wed, 2004-03-24 at 08:00, Chris McDonough wrote: > I have put a new proposal up at > http://dev.zope.org/Wikis/DevSite/Proposals/FasterStaticContentServing > which deals with serving large "static" content objects faster from Zope > 2. This is based on some work that Paul Winkler and I did at the PyCon > Zope 2 sprint. Comments appreciated. I think this would also be very > useful for Zope 3; the concept would just need to be adapted to the new > server architecture in use there instead of ZServer. Btw: does this also - decrease memory usage during delivery time? - provide a solution of having too many threads consumed up by long-taking downloads? Christian -- Christian Theune, gocept gmbh & co. kg http://www.gocept.com - [EMAIL PROTECTED] fon: 03496 3099112 fax: 03496 3099118 mobile: 0179 7808366 signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] proposal: serving static content faster
On Wed, 2004-03-24 at 08:00, Chris McDonough wrote: > I have put a new proposal up at > http://dev.zope.org/Wikis/DevSite/Proposals/FasterStaticContentServing > which deals with serving large "static" content objects faster from Zope > 2. This is based on some work that Paul Winkler and I did at the PyCon > Zope 2 sprint. Comments appreciated. I think this would also be very > useful for Zope 3; the concept would just need to be adapted to the new > server architecture in use there instead of ZServer. Cool and very appreciated. Christian -- Christian Theune, gocept gmbh & co. kg http://www.gocept.com - [EMAIL PROTECTED] fon: 03496 3099112 fax: 03496 3099118 mobile: 0179 7808366 signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] proposal: serving static content faster
Chris McDonough wrote: > http://dev.zope.org/Wikis/DevSite/Proposals/FasterStaticContentServing Sounds good. WRT your comments on the need for a cache multiplexer so one can handle the case of HTTP cache control headers & opaque server-side caches working together--I'm really wondering if a better solution isn't to just remove the cache header manipulations from where they are now (in a seperate product) and integrate it more into an API any where object [that wants to] can use. HTTP cache control really is a protocol level thing, and the way its bundled as an add-on service right now feels pretty awkward. But anyway, thats a digression from the main thrust of your let them eat producer proposal, which I think is a good idea in general. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
