Libelektra: Global Cache

[mpranj]

Meta issue for the global cache.

• [ ] two stage pointer update: 1) only global keyset (timestamps), 2) "real" keyset
• [x] resolver: check if update is needed #2249
• [ ] support other resolvers #2598
• [ ] cache: transient plugins #2269
• [ ] document limitations w.r.t. #2269
• [ ] crypto plugins + caching #2613
• [x] global KeySet handle
• [x] use new plugin name / variant API #2360
• [ ] problems with non-file-based storage plugins #2454
• [x] put cache into release note highlights and add benchmarks
• [ ] rename debugGlobalPositions to something better (cacheHitBypass?) as discussed in #2643
• [x] Add tools for kdb cache {enable,disable,clear}. #2831

[markus2330]

Thank you for tracking this!

[mpranj]

@markus2330 as I mentioned earlier, the very rough numbers for the cache are: 10x faster than no cache (with dump and no weird edge cases).

I investigated, why the improvement is not at its highest potential (we saw mmapstorage read is >70x faster than dump). It seems that other global plugins take up most of the time. (spec, list and stuff in PREGETSTORAGE, PROCGETSTORAGE, POSTGETSTORAGE).

When disabling these positions which are always called, even with cache, we would get an improvement of >80x. Maybe it would be interesting to think about going this direction.

[markus2330]

A big thanks that you investigated this!

Yes, we absolutely should do that. In my mind the cache plugin would always immediately exit for cache hits and not call any further plugins, maybe except some unlock, logging or notification plugins. But spec definitely is not needed when we have a cache hit.

[mpranj]

Nice, I think that will be a huge performance improvement then.

The drawback is that we'll need additional position(s) for that case (logging, unlock, ..). Currently PREGETSTORAGE, PROCGETSTORAGE and POSTGETSTORAGE are always called (whether cache hit, or no update as it was before we had a cache). I'm just not sure what this means for the semantics.

[markus2330]

Yes, the idea is to bypass everything that builds up the KeySet on a cachehit. As logging/notification for kdbGet is not really important and locking currently is not implemented (semlock is disabled) you can simply start by ignoring the semantics of the global plugins on cache hits (not executing anything for now).

[mpranj]

Two things came up regarding this:

Now NO_UPDATE is ~10x slower than CACHE_HIT. For consistency, we should disable the same global positions for NO_UPDATE too.

We either need a workaround or the POSTGETSTORAGE needs to skip the default split (user supplied KeySet not coming from a backend). The reason is that we can not cache uncomitted data. The test-suite seems to work fine if we simply skip it.