Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CACHE: named cache stores? #92

Closed
anthonyrisinger opened this issue Dec 19, 2012 · 19 comments
Closed

CACHE: named cache stores? #92

anthonyrisinger opened this issue Dec 19, 2012 · 19 comments

Comments

@anthonyrisinger
Copy link
Contributor

Proposal

various components can use the cache for sometimes non-related things (fastrouter keys, subscriptions keys, TLS share/balance, the APP itlsef, etc) would be nice to spawn (unlimited?) cache stores by name, then assign by name to discreet options.

UPDATE #92 (comment)

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

UPDATE #92 (comment)

// create...
struct uwsgi_cache *mycache = uwsgi_cache_create("name=pippo2,max_items=100");
// fetch...
struct uwsgi_cache *mycache = uwsgi_cache_by_name("pippo2");
@xrmx
Copy link
Collaborator

xrmx commented Dec 19, 2012

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
Copy link
Contributor Author

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
Copy link
Owner

unbit commented Dec 19, 2012

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
Copy link
Contributor Author

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

thanks for responses.

@unbit
Copy link
Owner

unbit commented Jan 11, 2013

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 unbit reopened this Jan 11, 2013
@unbit
Copy link
Owner

unbit commented Jan 24, 2013

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
Copy link
Contributor

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
Copy link
Owner

unbit commented Jan 24, 2013

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

@prymitive
Copy link
Contributor

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
Copy link
Owner

unbit commented Jan 24, 2013

ok, added 1.5 and 1.6.

@anthonyrisinger
Copy link
Contributor Author

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
Copy link
Owner

unbit commented Jan 26, 2013

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
Copy link
Contributor

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
Copy link
Owner

unbit commented Jan 27, 2013

from the init hook (NOT BEFORE !!!)

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

@prymitive
Copy link
Contributor

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
Copy link
Owner

unbit commented Jan 27, 2013

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
Copy link
Owner

unbit commented Feb 7, 2013

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
Copy link
Owner

unbit commented Feb 7, 2013

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

@unbit
Copy link
Owner

unbit commented Mar 17, 2013

i close that as the whole cache api has been rewritten

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants