[asterisk-dev] Review Request: Sorcery Caching

[Mark Michelson]

I've had a look at the page now, and here are my thoughts:

1) One thing that isn't really made clear is the interaction between 
multiple sorcery wizards. In a real-world example, you'd want to hit the 
memory_cache first and then hit the database afterwards if you couldn't 
retrieve the object from the cache. Does the order in which items are 
configured in sorcery.conf dictate the order in which wizards are 
consulted? Right now, I don't think that's the case. Or is it just that 
sorcery will automatically see cached stores as being higher priority 
than others?

2) I agree with Scott's assessment that the global expiration isn't the 
best idea. The object lifetime option makes much more sense.

3) Object expiration interval is something I feel most people wouldn't 
really want to set. They'd just hope that something sane was done by 
default. I think that defaulting to 60 seconds isn't that great a plan 
either, especially if objects in the cache are set to, say, a 10 second 
lifetime. Defaulting to some fraction of the object lifetime would work 
and probably satisfy most people. The value could potentially be updated 
during a rebalancing operation. Another option is to make use of some 
sort of timer heap so that in the case of long-lived cached objects, you 
don't run unneeded checks for object expiration.

4) In addition to the CLI operations, I think equivalent AMI operations 
would be useful. I also considered the idea of being able to change 
cache configuration for an object type via AMI/CLI. I'm not sure how 
useful that would be, and it likely would just create extra contention 
points where they're really just not needed, so meh.

5) It may be useful to have C-level API calls for invalidating 
objects/caches. This way, we could implement behavior such as  a reload 
of res_pjsip.so resulting in invalidation of all cached objects owned by 
res_pjsip.so.

6) The tests are good for testing basic operation of the cache. However, 
there's not much being done so far with regards to off-nominal code 
paths (like a user creating a cache with a negative number of maximum 
objects). First, something needs to be decided regarding how such an 
error is treated. Do we still create the cache but with a default value 
configured instead, or do we completely fail to create the cache? Once 
this is decided, some off-nominal tests with bad configuration should be 
tested.

7) There doesn't seem to be any way for someone to state that they never 
want cached objects to automatically become invalidated (i.e. infinite 
object lifetime). For some installations where configuration is 
performed through web browsers, for instance, it may be that at the time 
the config is changed, the system would issue an AMI/CLI command to 
Asterisk to invalidate the old object. They would essentially always be 
in charge of telling Asterisk when to invalidate cached objects. I know 
this is treading close to the old "sip prune realtime" territory, but I 
feel like this isn't quite as bad since you would have control over 
individual objects and object types.

8) My final comment is in regards to the "expiration" of cached items. 
Based on wording in tests, it sounds like when the expiration interval 
arrives, the item is removed from the cache entirely. I wonder if there 
is a benefit to instead, updating the item when the expiration interval 
arrives. On the one hand, this has the benefit of meaning that a user of 
sorcery will always be hitting the cache and never have to actually fall 
back to a DB lookup. On the other hand, on an idle system, this can 
result in many pointless DB lookups. So there are tradeoffs, but it's 
still something to consider. Also, I think Scott pretty much brought up 
this same idea now that I look back at his response again.

On 04/28/2015 11:28 AM, Joshua Colp wrote:
> Kia ora,
>
> I've created a wiki page[1] which details the beginnings of a basic 
> memory based caching wizard for sorcery. Right now while caching is 
> possible using the existing memory wizard it's not possible to define 
> object lifetimes, so once cached it's always pulled from the cache. 
> This wiki page uses the memory wizard as a base but defines options 
> which can tweak the behavior. Going forward this could serve as a 
> basis for other wizards to be created for caching purposes.
>
> Some things to consider:
> 1. How much control and flexibility should we allow?
> 2. Are there additional mechanisms that should be exposed to allow 
> explicit object expiration?
> 3. Are the defaults sane?
> 4. Is there additional testing that should be done?
> 5. Does anything need additional explanation?
>
> Cheers,
>
> [1] https://wiki.asterisk.org/wiki/display/~jcolp/Sorcery+Caching
>