On Thu, 2010-08-12 at 08:34 +1200, Robert Collins wrote: > On Wed, Aug 11, 2010 at 4:27 PM, Michael Hudson > <[email protected]> wrote: > > On Wed, 11 Aug 2010 15:02:13 +1200, Robert Collins > > <[email protected]> wrote: > > > >> The latter are trickier because we want to get all the related data we > >> want at once, no more than needed, and no less. If we get more things > >> go slower, and if we get less we scale poorly as the page gets busier > >> (e.g. more builds). The pattern I've tried in registry with > >> _all_members should help considerably, once we get the cache coherency > >> stuff sorted (which strictly speaking only really affects the test > >> suite : production clears storm caches between requests, and so caches > >> on model objects have no lifetime in the actual server). > > > > What's the issue here, generally speaking? > > I don't know enough to speak generally. I can tell you about a > specific problem. > > > It's possible to arrange for > > caches to be cleared on many boundaries -- for example, the per-request > > security policy cache is cleared when the principal changes, which > > happens during login. Clearing all @cachedpropertys like this might not > > scale very well, but otoh there might be something we can do. > > Sure. > > So there are two caches per model object [at a baseline level] > > *) cachedproperty. This is stored in the model object, as > _attributename_cached attributes.
We used to avoid cachedproperties on model classes as debugging things when you have a (sometimes unexpected) caching at that layer is not fun, but we seem to have lots of them now. I remember that Bjorn used to advocate strongly for us not using them. -- Guilherme Salgado <https://launchpad.net/~salgado>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
