gitolite and the (redis) cache
(requires v3.6.1)
WARNING: this has not been tested in a while. YMMV
Gitolite can optionally use the Redis in-memory key-value database for a little speed boost for really large sites.
If you look in the [gitolite performance][perf] page, you will see, right at the bottom, that pretty much the only thing in gitolite that may be slow is the [info][] command. The cache feature fixes that problem :-)
Using Redis as the backend database is actually a bit of overkill; technically this could just as well have been done using a DBM file or SQlite or something like that, but since this is only a cache, an in-memory database works out better. However, Redis does have one real advantage: cache [timeout][]s!
Support for this feature is limited to verifiable gitolite bugs, if you find any; I can't help you with redis itself.
how does caching work?
To use this feature, just install Redis, then the perl driver "Redis.pm". Install or upgrade Gitolite to the latest master, then uncomment (or add, if it doesn't exist) the following line in the rc file:
CACHE => 'Redis',
If you're adding it, please add it within the \%RC hash, but outside the ENABLE list. (If in doubt, add it just after the UMASK entry).
Then perform some gitolite operation (anything that requires any form of access checking). Redis should start automatically and the right things should happen; see below if it does not.
troubleshooting caching
If you ever kill the redis-server be sure to also remove the socket file
~/.redis-gitolite.sock. Conversely if you ever remove the sock file be sure
to kill the process also. Otherwise you get weird behaviour, including
possible hangs. (If things don't seem to work, the first thing to do is to
kill all 'redis-server's on that userid and remove ~/.redis-gitolite.*, then
try again.)
Note: To the best of my knowledge, this cannot result in wrong data being passed to gitolite, causing a security breach. If anyone has time I'd appreciate a review of the code.
caching details
what is cached
At present, gitolite caches only one specific function: the "access()" function. This is available from the shell as the 'gitolite access ...' command, as well as from perl via the "Easy.pm" interface; see [dev-notes][] for more. It is easily the "workhorse" of gitolite.
The cache is flushed completely when the gitolite.conf file is "compiled". You might see some things running a bit slower -- at least until things settle down.
Finally, if you run 'perms', the cache entries for that specific repo are also flushed.
how long is it cached {#timeout}
Redis has a timeout feature that can delete entries after a certain period of time has elapsed since they were created or updated. Gitolite sets a timeout of 90000 seconds (just over a day) normally. However, if you're using the GROUPLIST_PGM feature (see [here][ldap] for details), then this timeout becomes 900 seconds (only 15 minutes). This is because a user's group membership, and thus her access rights, can change without gitolite being aware of the change.
If you're not using the GROUPLIST_PGM feature, you don't have to do anything. But if you are using it, then a cache timeout of 15 minutes may be too much or too little for you -- I cannot judge that. You can tell gitolite what timeout you want for your setup, by adding (or uncommenting) an RC variable called CACHE_TTL; its value is the number of seconds for the timeout.