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

[Justizin]

On 12/11/06, Alec Mitchell <apm13 at columbia.edu> wrote:

>
> This code isn't about a RAMCache which lives across threads and
> requests, but is a short-lived cache which is bound to a particular
> request.  It's purpose is to make multiple calls to the same

I feel that I understand how this solution is currently implemented. :)

> methods/attributes in a given request use the same data, e.g. to
> relpace the elemts in global_defines (now @@plone/globalize) with a
> more general, transparent, and reusable way of making potentially
> expensive calls repeatable for a given request.  It would certainly be

I feel that I understand the goal of this solution. :)

> possible to use a RAMCache for this but it would probably be overkill,
> simply because it would be need to be keyed in a very general way (per
> user, per context, per view, possibly per time of last content change
> for navigation related methods).  In other words, if we were using a

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

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.

So, I understand that it may sound like overkill, but I'm disagreeing.
 Of course, I understand that I may have to choose between writing
code myself and seeing nothing come of the discussion, but I think
it's an idea worth exploring.

> more general cache we'd need to use a much different and more complex
> set of keys.  Of course, these cache decorators can easily be
> rewritten at any time to use a different storage mechanism if that
> turns out to be desirable, probably with no changes needed to code
> that makes use of them.

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.

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.

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.

-- 
Justizin, Independent Interactivity Architect
ACM SIGGRAPH SysMgr, Reporter
http://www.siggraph.org/