You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@zookeeper.apache.org by Baskar Duraikannu <ba...@outlook.com> on 2013/08/01 00:25:26 UTC

RE: Zookeeper performance

Thank you. 

> Date: Wed, 31 Jul 2013 20:09:59 +0100
> From: bill@dehora.net
> To: user@zookeeper.apache.org
> Subject: Re: Zookeeper performance
> 
> 
> > 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? 
> 
>