zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill de hÓra <b...@dehora.net>
Subject Re: Zookeeper performance
Date Wed, 31 Jul 2013 19:09:59 GMT

> We may get about 100k requests per second. Can zookeeper handle this volume?

Depends on your r/w ratio. ZK isn't always ideal for 'user-scale' write heavy workload (lots
of things being tracked and updated) . My experience is that you'll have memory pressure (due
to the size of the tree) and disk pressure (due to the frequency of snapshotting). You'll
need to look at ssds or ram disks for the latter and expect to invest time tuning the JVM,
ZK parameters for the former.

I agree that it is likely to be error prone without a lot of careful engineering; a design
that avoids/reduces locking or a technology that has locking built-in might be a better fit.

Bill




On Wednesday 31 July 2013 at 12:16, Baskar Duraikannu wrote:

> Hello
> 
> We are looking to use zookeeper for optimistic concurrency. Basically when the user saves
data on a screen, we need to lock, read to ensure that no one else has changed the row while
user is editing data, persist data and unlock znode. 
> 
> If the app/thread does not get a lock, we may set a watch so that polling is avoided.
> 
> Our application is write intensive certain times of the day. We may get about 100k requests
per second. Can zookeeper handle this volume? 



Mime
View raw message