[bmatheny]

I worked on Staircar so maybe I can answer a couple of questions.

Machine failures: failures we'll likely address in a future post but basically each redis instance can have a slave which can be failed over to.

Performance: Staircar isn't nearly as fast as redis, but the primary project goal was making the redis infrastructure opaque to any clients. The secondary goal was performance, which is still quite good.

Early Optimization: In a large infrastructure (thousands of machines, multiple data centers, etc) you have locality issues, slow clients, machine failures and other operational considerations. Again, redis performance is fine and we weren't concerned with that. We were interested in creating a high performance proxy to a pool of redis instances. Also, with Staircar we can make online changes to the redis pool without needing to notify clients of those changes.

[SteveMorin]

Is the code open source or do you have plans to open source it. I am actually pretty interested in this and would love to be able to read the code for it. -Steve

[bmatheny]

Hey Steve, we do have plans to open source the code in two parts. The first part to likely be open sourced will be the high performance logging library that was written for it. After that, the proxy component. Keep an eye on the Tumblr engineering blog for a notification.

[SteveMorin]

Thanks

[a-priori]

I find it interesting that there are two distinct bands in the response time plots. Any ideas what the two represent?

[bmatheny]

The upper band essentially represents new users. At the current rate of growth, we push into a new redis shard every 2-3 days. When we first start writing/reading against that shard, it appears to take a bit of time to warm up.