The interesting thing about your timing is that I would expect on ext3 you would sill similar slowdowns, although perhaps they are harder to see, due to how the

The interesting thing about your timing is that I would expect on ext3 you would sill similar slowdowns, although perhaps they are harder to see, due to how the most common configuration of using sync=ordered behaves, which should cause effectively any fsync to flush everything to disk, and even then, the kernel will trigger one ext3 commit interval every ~5 seconds by default. I didn't see it mentioned in the blog post, but what filesystem were you running this test on? I don't know the details about Redis' threading and event model, but please feel free to share them; Most event-y systems I've worked on end up falling back to a smallish-number of threads to provide the IO concurrency, because you just don't have the fine grained control of the kernel to provide a perfect level of service with a tiny-number of threads. This is the model the Event MPM in httpd uses, its the model that Traffic Server uses, its the model that Lighthttpd tried to not use at first, but they added threads in later because of blocking stat calls, etc. Kernel's like the liberty that POSIX standards give them, things will block, and even if you want to do 140,000 operations a second, if you want any durability at all, there will have to be a tradeoff, the most likely ones are things like multiple commit logs, and more threading.