Right. As soon as you get disk based storage for Redis SSDs will make a lot of difference.

I think that SSD will do a difference in Redis once we’ll have Virtual Memory implemented. Redis will random-access the swap file likely.

This is interesting as it well highlights common misconception about what SSDs are fast for. SSDs (and I unclude FusionIO here) are fast for random reads and writes. Sequential Reads single Intel SSD will have speed similar to the good hard drive (at some extent due to SATA interface limits) and FusionIO similar to the good RAID with few hard drives. Writes are more expensive for SSDs so for Sequential Writes standard hard drives are often the winners. It is the most interesting when it comes for small sequential writes with fsync() calls – the Raid has DRAM with BBU which has very low latency for writes. The SSDs as I see write directly to flash which is fast but slower than DRAM. I would expect fsync() speed to become very similar in the end as nothing prevents FusionIO etc have some DRAM with battery or capacitors but SSD do not get the leverage here against legacy hard drives.

My hope was that, by using FusionIO, there would be a less pronounced penalty for appendonly yes / appendfsync always. This (obviously) turned out not to be the case.

@diego

I’ll do some testing later with “save 60 10000″ and other parameters, the primary goal of this run was to look at the cost of appendonly yes/appendfsync always. And the 30,000 set/s I got with fsync everysec aren’t *much* of an improvement over your 24k, but that was somewhat expected as sequential writes on SSDs (as Peter says) “aren’t cost efficient”.

@antirez

I thought the 40k on loopback was a bit low, but my real interest was the new appendonly yes/fsync always. There are more benchmarks I’m thinking about doing, I’m hoping “Round 2″ will be next week!

– Ryan Lowe

Why did you test it on FusionIO ? This does not look a very good use case for it – Redis whenever it periodically dumps its memory or whenever it is using appendonly log does sequential writes and SSDs in general are not cost efficient in such cases – Spindles with BBU cache in the RAID should do as good or even better (the 5000 fsync/sec you seems to be getting is not impressive)

Also I’m wondering if Redis has got “Group Commit” implemented in append only mode – will it do single fsync per few operations if multiple transactions are pending ?

thanks for this tests! A few remarks:

- I think fsync set to “always” is so slow because Redis is single threaded and fsync() is slow, it has to wait the syscall finish before to return serving other clients.
- Broken pipe should be harmless, it’s just a metter of how redis-benchmark works and timing issues. It should be possible to see the error even without persistences with more than 50 clients, even now that 1.2 supports epoll.
- It’s strange that on Linux against loopback you get only 40,000/s, should be at least 100,000/s in a entry level server.

Thanks again! I’m looking forward for other tests given that the title “round 1″ make me hope about a second round

Cheers,
Salvatore