4 ms·

Right now, yes. Deploys happen frequently enough and are sufficiently fast that I can get something disabled globally in under 30 seconds. The next iteration of

Right now, yes. Deploys happen frequently enough and are sufficiently fast that I can get something disabled globally in under 30 seconds. The next iteration of this stuff I'm building now; goals are standalone library, more DRY, and some kind of simple web UI where I can do the global enable/disable actions. I'll likely stick to manipulating buckets in config files for the foreseeable future; it's being able to mass-enable/disable that I need to refine.

technoweenie 16y ago
I've started using Redis key/set operations for things like this at GitHub. The nice thing is that these techniques are all simple, and it's easy to modify to fit your evolving needs.
- kylebragger 16y ago
  Yeah, I definitely considered using Redis too; I'd be able to leverage web UI for even stuff like adding/removing users from buckets. How are you handling with persistence? I presume backing up the dump.rdb file frequently? I'd be a shame to lose any of the data (though I'm probably being overly paranoid)
  - technoweenie 16y ago
    We were already using Redis and had an existing backup plan. Though if you're using Redis solely for feature rollout, you can likely get away with it failing gracefully in case the server is down.
  - kneath 16y ago
    Using a combo of the append-only file[1] and a redis slave[2] you'll get about the best durability one can ask for in today's world (assuming you're aware of the gotchas with regard to expiring keys — an edge case). [1] http://code.google.com/p/redis/wiki/AppendOnlyFileHowto http://code.google.com/p/redis/wiki/AppendOnlyFileHowto [2] http://code.google.com/p/redis/wiki/ReplicationHowto http://code.google.com/p/redis/wiki/ReplicationHowto
  - didip 16y ago
    We are using Redis as well. The C code is small, compilable anywhere, and has very small memory footprint when started fresh. Redis has replaced Sphinx as our tag indexer (thanks to its ordered sort) for more than 2 months now. It has never been down. Backup procedure is the same as our MySQL's, tgz the .rdb file to S3 daily.

technoweenie 16y ago

I've started using Redis key/set operations for things like this at GitHub. The nice thing is that these techniques are all simple, and it's easy to modify to fit your evolving needs.

kylebragger 16y ago
Yeah, I definitely considered using Redis too; I'd be able to leverage web UI for even stuff like adding/removing users from buckets. How are you handling with persistence? I presume backing up the dump.rdb file frequently? I'd be a shame to lose any of the data (though I'm probably being overly paranoid)
- technoweenie 16y ago
  We were already using Redis and had an existing backup plan. Though if you're using Redis solely for feature rollout, you can likely get away with it failing gracefully in case the server is down.
- kneath 16y ago
  Using a combo of the append-only file[1] and a redis slave[2] you'll get about the best durability one can ask for in today's world (assuming you're aware of the gotchas with regard to expiring keys — an edge case). [1] http://code.google.com/p/redis/wiki/AppendOnlyFileHowto http://code.google.com/p/redis/wiki/AppendOnlyFileHowto [2] http://code.google.com/p/redis/wiki/ReplicationHowto http://code.google.com/p/redis/wiki/ReplicationHowto
- didip 16y ago
  We are using Redis as well. The C code is small, compilable anywhere, and has very small memory footprint when started fresh. Redis has replaced Sphinx as our tag indexer (thanks to its ordered sort) for more than 2 months now. It has never been down. Backup procedure is the same as our MySQL's, tgz the .rdb file to S3 daily.