I kind of wonder about them only using one disk. I haven't experimented with this in ZooKeeper, nor have I ever been a DBA, but with traditional database systems (which ZooKeeper should be basically identical to, in this regard), it's a pretty common recommendation to put snapshots and TxLogs on different drives, for the obvious reason of avoiding one of the biggest problems laid out in that blog post: when snapshot happens, it contends with your log flushes, causing write latencies to explode. Suddenly you have tons more IO, and where it used to be nicely sequential, now it's heavily randomized because of the two competing writers. It's kind of the nature of benchmarks that there's always something you can nitpick, but still, I feel like they're running a questionable configuration.
They mention that ZK snapshots "stop the world", and maybe I'm mistaken, but I didn't think that was right - I thought they were just slowing everything down because they write a lot and contend a lot. I'm pretty sure ZK snapshots are fuzzy over a range of transactions, and transactions keep applying during the snapshot, right? Thanks, Dan On Tue, Feb 21, 2017 at 2:24 PM, Benjamin Mahler <[email protected]> wrote: > I'm curious if folks here have seen the following write performance > comparison that was done by CoreOS on etc, Consul, and ZooKeeper: > https://coreos.com/blog/performance-of-etcd.html > > Sounds like performance comparison of reads and updates are coming next. > Are there any thoughts from folks here on this comparison so far? > > Thanks, > Ben >
