Forum OpenACS Development: Re: Problem with cache UI

2: Re: Problem with cache UI (response to 1)
Posted by Gustaf Neumann on
Dear Antonio,

i guess, this slipped through, since this user interface is limited to the util_memoize cache only, and people use different interfaces. I've added compatibility for NaviServer (committed to the oacs-5-8 branch).

best regards

3: Re: Problem with cache UI (response to 2)
Posted by Antonio Pisano on
Oh, sorry Gustaf, I really thought util_memoize was THE api when talking about cache.

Is it still ok to use it, or you're going for a different preferrable idiom? If so, what is it?

4: Re: Problem with cache UI (response to 3)
Posted by Gustaf Neumann on
Putting everything in a single cache (like the util_memoize cache) becomes a scalability issue, since there will be competition between all concurrent connection threads for obtaining information from there, since all accesses require mutex locks. especially bad are cases, where e.g. all keys are retrieved from a cache (this might be several a list with hundred thousand or more entries) in a huge list, and the list of keys is later processed for some patterns to for invalidation. Unfortunately is a not a seldom idiom in OpenACS + DotLRN. During the generation of this huge list the cache has to be locked, meaning that all other cache requests from other threads for the util_memoize cache have to wait. One can get statistics about that via nsstats.tcl.

That is one of the reasons, why e.g. xotcl-core/xowiki use different caches.

These locking problems show only up for large and busy sites, for small sites, this does not matter.