Is redis much more stable than memcached?

 Triviality  No Responses »
Jul 292013
 

I got a weird feeling that redis is more stable than memcached … but I don’t have solid evidence for that.

The case is, I migrated an application’s backend from memcached to redis, there were surely some other bug fixes and trivial performance tuning, but thinking of the memcached version had been running in production for more than 6 months without any significant problem, I wouldn’t think my changes make any big difference. Also, I changed my codes only, nothing to do with redis/memcached so I think it’s a fair comparison.

memcached use to hit 6GB memory (VIRT) usage after a week to 10 days running, then for most cases it will crash cos ops people set RAM limitation. Ops people asked me to do a restart once the memory utilization hit a certain level, but I found that restart memcached will simply wipe out all my in-memory-only data like counter, which is not critical but will make the application looks weird (“no more visitor in the past 7 days???”), and this initiated the migration to redis.

After migrated to redis, the memory utilization started from 4200MB, and one of the oldest instance had been running there since Jun 4 (50+ days till now), and memory is at 4300MB. I guess the increment was due to data size growth instead of memory leak, though again, I don’t have evidence.

Anyway, I’m not going to go back to memcached in the future, so the difference won’t bother me.

mysql+memcached vs. openldap

 Triviality  5 Responses »
Sep 092009
 

I’m going to test two types of authentication system, one is what seems to be common in current days which utilizes database and cache, the popular combination is mysql+memcached, and the other is what I recommended to others for authentication system for all the time – LDAP, and surely openldap is the first choice (Fedora DS is not available on other platforms, though seems it’s easier to manage).

I compose couple of items describing the tests I’m going to take, and I will review this couple of times while I’m doing the setup.

First, application. I had some assumption based on my past experience, that is:

  • Good user
  • 1 authentication (login with right username and password)
  • 10 look up, getting user’s attributes (for showing them on some pages, note that reading these attributes needs to go through couple of tables)
  • 1 edit, such as changing profile
  • Bad user
  • 1 authentication (login with incorrect username or password)

and the ratio of good vs. bad user is 1:5 (yea, lots of abuse …).

There will be 1M registered users, but the “good user” will only include 100K of them, which reflects 10% active users rate, actually this is already high. There will be 3 PHP pages: login.php to do authentication, pref.php retrieve preferences of the user, and edit.php try to change user’s profile. All these take GET query strings so to make test easier.

Environment:

  • database testing environment
  • debian acts as web server, running apache and PHP
  • freebsd acts as client, generating load with apache’s ab
  • centos is mysql’s master, handling both read and write
  • opensuse is mysql’s slave, handling read only, note that we are not using mysql-proxy as it seems to me it is far away from production quality so far
  • ubuntu and fedora run memcached, in TCP mode with 64M cache memory each
  • I’m going to post database schema later on
  • ldap testing environment
  • debian acts as web server, running apache and PHP
  • freebsd acts as client, generating load with apache’s ab
  • ubuntu and fedora are running openldap in mirror mode
  • again, schema will be posted here later on

maybe the only unreal part above is openldap will run in mirror mode, which is not extensible – I will check to see what kind of openldap replication is suitable for production deployment.

Pretty much that’s it, will update once I review this plan.