Hey devs, why was memcached chosen as a session alternative instead of for instance redis? Memcache is a pretty bad spot for sessions, and if you dont believe me, read what the author of memcache has to say:
http://dormando.livejournal.com/495593.html
Redis is a much better alternative for sessions, as it's got persistent storage, meaning you can restart a server (lets say after an upgrade), and wont drop your 20.000 connected users. Redis is also actively working on clustering, with alpha code available.
Cor
Hello,
You can have sessions in redis with current roundcube. Just choose normal php sessions in roundcube, and configure php.ini to use php5-redis as a session provider.
Regards, Stephane Le 2 juin 2014 10:31, "Cor Bosman" cor@xs4all.nl a écrit :
Hey devs, why was memcached chosen as a session alternative instead of for instance redis? Memcache is a pretty bad spot for sessions, and if you dont believe me, read what the author of memcache has to say:
http://dormando.livejournal.com/495593.html
Redis is a much better alternative for sessions, as it's got persistent storage, meaning you can restart a server (lets say after an upgrade), and wont drop your 20.000 connected users. Redis is also actively working on clustering, with alpha code available.
Cor
Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
Thanks for the pointer, but it's kind of a hassle as there's no debian packages for phpredis. We could package it ourselves, but thats just more stuff to maintain.
Has anyone ever gotten memcached to be truly redundant? I cant seem to get it so if I bring 1 (of many) memcached down, then bring it back up, it still works right. Roundcube sees an empty server and assumes there's no session key. Memcache has a replication/fallback system but i cant get it to work.
Cor
You can find good php deb packages, with up to date php versions and php-redis in the dotdeb repository. They have debs for wheezy. Beem using it in production for a few months, quite happy so far.
Regards, Stephane Le 2 juin 2014 14:48, "Cor Bosman" cor@xs4all.nl a écrit :
Thanks for the pointer, but it's kind of a hassle as there's no debian packages for phpredis. We could package it ourselves, but thats just more stuff to maintain.
Has anyone ever gotten memcached to be truly redundant? I cant seem to get it so if I bring 1 (of many) memcached down, then bring it back up, it still works right. Roundcube sees an empty server and assumes there's no session key. Memcache has a replication/fallback system but i cant get it to work.
Cor
Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
On 06/02/2014 08:47 AM, Cor Bosman wrote:
Thanks for the pointer, but it's kind of a hassle as there's no debian packages for phpredis. We could package it ourselves, but thats just more stuff to maintain.
http://packages.qa.debian.org/p/php-redis.html
It's not in debian stable (wheezy), but you could ask on debian-backports@lists.debian.org (with a cc to the package maintainer) for someone to supply a backport to wheezy, if you want it available for wheezy, but don't want to maintain it yourself.
--dkg
On 2014-06-02 13:47, Cor Bosman wrote:
Thanks for the pointer, but it's kind of a hassle as there's no debian packages for phpredis. We could package it ourselves, but thats just more stuff to maintain.
Has anyone ever gotten memcached to be truly redundant? I cant seem to get it so if I bring 1 (of many) memcached down, then bring it back up, it still works right. Roundcube sees an empty server and assumes there's no session key.
I believe that this is the way that memcached expects to work.
You provide a list of memcached servers for horizontal scaling rather than high availability.
Memcache has a replication/fallback system but i cant get it to work.
I am running Roundcube against memcached with the repcached patch.
Node #1:
/opt/repcached/bin/memcached -m 4096 -c 4096 -d -l 192.168.128.31 -x 192.168.128.81
Node #2:
/opt/repcached/bin/memcached -m 4096 -c 4096 -d -l 192.168.128.81 -x 192.168.128.31
Both nodes claim to be the master node through the stats interface (and indeed a update on either node is mirrored to the other side). If I restart memcached on one node it fetches the state from the other side after a short pause.
This does work: only this morning I was able to walk the memcached session store from one pair of machines to another pair of machines in the same cluster without any user visible downtime by:
- Shutting down one node and moving the IP address used by that node.
- Pointing Roundcube at the migrated copy after memcached had
resynchronised there 3) Moving the other node in the same fashion
The only problem that I have had is that memcached slowly leaks memory when replication is enabled: some memory isn't released until one of the two nodes is restarted. Consequently I do that once a day, in the middle of the night.
Session timeouts also behave a little differently when memcached is used rather than the normal database session management. I found that the compose page hangs rather than giving a error page if someone clicks "Send" on a page where the session has timed out. We use a four hour session timeout, which helps.
-
Cor Bosman -
Daniel Kahn Gillmor -
David Carter -
stephane martin