One of the more interesting features in 1.2 is the ability to operate in “append-only file persistence mode”, meaning Redis has graduated from a semi-persistent to a fully-persistent system! Using the redis-benchmark script included, I ran the following command
in five modes:
1 – In-Memory
I set “save 900000000 900000000″ so nothing would be written to disk during the tests.
2 – Semi-Persistent
I set “save 1 1″ so that changes would be flushed to disk every second (assuming there was at least one change the previous second).
3 – Fully Persistent
I set appendonly yes and appendfsync always, which calls an fsync for every operation.
4 – Semi-Persistent
I set appendonly yes and appendfsync no, which is about as persistent as MyISAM. An fsync is never explicitly called, rather we’re relying on the OS.
5 – Semi-Persistent
I set appendonly yes and appendfsync everysec, which explicitly calls an fsync every second.
(By default, redis-benchmark invokes 50 parallel clients, with a keep alive of 1, using a 3-byte payload.)
I am quite surprised at the performance penalty here for full durability.
Aside from the numbers, there are a couple of other interesting things I noticed during the benchmarking (note that the full benchmark suite was run, not just SET):
– In case 2, the dump.rdb file was 40k. While in case 3, 4, and 5, appendonly.aof was 1.9M. If you’re going to to use appendonly in production, be sure to consider the additional storage requirements.
– In every case where appendonly was enabled, I received the following error many times as the test was completing (note that this did not occur during the SET operations):
Error writing to client: Broken pipe
To be fair, this is RC, not GA.
* All data easily fit into memory during these tests.
* The FusionIO used was: 160 GB SLC ioDrive
* XFS was the filesystem
* redis version was a git clone at Thu Dec 10 10:41:50 PST 200