[Framework-Team] Re: [Plone-developers] Revisited: Some preliminary Plone 3.0 profiling results

Martin Aspeli optilude at gmx.net
Mon Dec 11 08:36:41 UTC 2006

Justizin wrote:

> This is incorrect.  If we are storing generated values based on:
>  (context, view_name, method_name, keywords)
> This is an entirely acceptable key for:
>  Zope2 RAMCacheManager
>  Zope3 RAMCache
>  MemcachedManager, which could be based on either of the above

Sure, but that doesn't mean we wouldn't get false positives in the cache 
using this approach.

> Keep in mind, esp with AJAX, that some requests to the same context
> referring to similar data may hit different zope clients and/or
> threads.

Yes. This doensn't solve that at all, nor does it attempt to. The cache 
lives exactly as long as one request, and then disappears.

> The keys are bound to the context and the perspective from which it is
> being accessed, not the request, and there's no reason they should be
> request-specific.

Yes there is. Almost all of these values are valid in a particular 
request, but could be radically different in the next request.

> It may be necessary to also use roles in the key, but in comparison
> with a hash of the context and all arguments to a method, that's
> probably minimal.

Roles, local roles, groups, the changing state of the portal (e.g. some 
more content is added, removed etc), probably other things I can't think 
of right now. The complexity is potentially unbounded, which means that 
the user of the decorator will need a very deep understanding of how the 
value is cached if they are to avoid false positives in the cache, which 
in turn would likely lead to insane bugs (note, this is a lot different 
from caching a piece of content or so, it could lead to SiteErrors all 
over the place due to inconsistent state being recorded).

> There is some concern that memcached may have a limit on cache key
> sizes, but it's a very simple C app and could probably be extended
> easily.

I have no interest in touching C code (or shipping Plone with custom C 
code). Almost no-one in the community knows how to maintain it.

Feel free to prove me wrong, but not by modifying plone.memoize to 
support this, it's expressly not its stated purpose.


More information about the Framework-Team mailing list