CACHE: named cache stores? about uwsgi

[xrmx]

When i had the need to have more than one cache for the application Roberto suggested to switch to redis, I did and never looked back :) The internal uswgi cache really lacks flexiblity, e.g when it is full you have to implement your own cleanup policy, was not fun for me. Said that it would be a useful feature.

[anthonyrisinger]

what about the suggested "stores" API, is that similar/related? could that be leveraged to replace the uwsgi cache altogether?

basically we have the need for some (inter-node) shared and.or cached state by arbitrary components, and must then be able to relay the proper "silo"/store/

[unbit]

The idea is having the storage subsystem over the cache subsystem, to implement namespaces and recycle policy (read: what to do when the storage is full). So in the future you should be able to create different "virtual disks" mapped the the cache shared memory. Sadly i do not know when it will be ready for commit

[anthonyrisinger]

ok then we'll just let this unfold a little more then :)

thanks for responses.

[unbit]

Ok, it seems having different caches with different settings (block-size, item-size, hashing algorithm...) is something really needed (for example ssl sessions caching works better with a tuning completely different from a web cache). I reopen that.

[unbit]

Ok, committed the first round of multiple caches. A new option has been added --cache2 allowing the configuration of "new generation caches"

--cache2 name=X,max_items=n[,keysize=n,blocks=n,blocksize=n,hashsize=n,hash=S,store=S]

the new thing is that you can now specify the maximum keysize, hashsize and the hash algorithm (currently supported djb33x and murmur2, others will be added). This allows for ultra-optimized stores based on the content.

The new system can be already utilized with SSL sessions and fast/http/raw-router host->backend mappings.

Another addition will be the usage of blocks bitmap (if requested) to allows object to be stored on multiple blocks (to avoid wasting space).

Issues:

The cache sync system (via udp) is currently broken
The optimized cache server is broken
The cache sweepers (the threads aimed at clearing dead items) are broken
The cache remote plugin works only with the default (old style) cache
The cache api for languages still does not support named caches (maybe it will be required to add more api functions to maintain backward compatibility)

[prymitive]

With every uWSGI release I tend to think "this is great, it can't get any better". And then next release comes out and somehow it does ;)
Is there any long term road map? Maybe it's time to start adding milestones to github issues?

[unbit]

there is no roadmap as most of the things pop-up from customers requests or funny/strange ideas proposed by someone :)

[prymitive]

It looks that way, but for clarity we could have few milestones defined ("1.5", "1.6", "when I'm bored") and tag requests as they are reported.

[unbit]

ok, added 1.5 and 1.6.

[anthonyrisinger]

awesome! it may be already doing something like this, but if not, i would suggest prefixing the names of any [implicit] internal stores with some char or string, so people can reliably avoid clobbering them...

...eg. :tls-sessions or __tls-sessions

i think this should primarily be done for stuff that uses the cache implicitly; if you must specify the cache name it's not as important. initially i was going to suggest that implicitly used caches be isolated somehow, but there are probably interesting reasons to manually pop/push stuff to internal stores (prefill/inspect/etc).

[unbit]

Update:

cache sweepers are working again, a thread will be spawned for each cache (to avoid waiting on big caches iterations)

The stats server now exports lot of infos about caching, someone interested in developing a uwsgicachetop ?

[prymitive]

Is there any API for creating named cache from plugins? If not (and I don't see any) would it be possible to add this? I could play a bit more with clustered crons and maybe improve it to the point where someone is willing to use it.

[unbit]

from the init hook (NOT BEFORE !!!)

struct uwsgi_cache *mycache = uwsgi_cache_create("name=pippo2,max_items=100");

[prymitive]

It appears that it works a little bit different:

uwsgi_cache_create("name=clustered_crons,max_items=100,blocksize=4096");
struct uwsgi_cache *mycache = uwsgi_cache_by_name("clustered_crons");

[unbit]

fixed it, if uwsgi-cache_create returns the uwsgi_cache struct you do not need to parse the args to get the name of the cache (allowing the user to customize it)

[unbit]

Another update (really few parts missing). The cache udp update system (the one needed for ssl sessions) has been ported to the new api. The syntax for --cache2 is currrently that:

if (uwsgi_kvlist_parse(arg, strlen(arg), ',', '=',
"name", &c_name,
"max_items", &c_max_items,
"maxitems", &c_max_items,
"items", &c_max_items,
"blocksize", &c_blocksize,
"blocks", &c_blocks,
"hash", &c_hash,
"hashsize", &c_hashsize,
"hash_size", &c_hashsize,
"keysize", &c_keysize,
"key_size", &c_keysize,
"store", &c_store,
"node", &c_nodes,
"nodes", &c_nodes,
"sync", &c_sync,
"udp", &c_udp_servers,
"udp_servers", &c_udp_servers,
"udp_server", &c_udp_servers,
"udpservers", &c_udp_servers,
"udpserver", &c_udp_servers,
NULL)) {
uwsgi_log("unable to parse cache definition\n");
exit(1);
}

a bunch of options could be added before 1.9.

Issues:

cache initial sync is still pretty-broken (working on that right now, see below)

The optimized threaded cache server is broken

The cache plugin still need porting to the new api (this requires cache plugin fix)

The languages cache api still need to be defined. Currently my idea is adding cache_get2|set2|update2|del2 taking as the first argument the name of the cache.

Store to disk still need some love (hope to fix it later today)

[unbit]

Fast update: the cache store system has been ported to the new api.

[unbit]

i close that as the whole cache api has been rewritten