Thank you.
> Date: Wed, 31 Jul 2013 20:09:59 +0100 > From: [email protected] > To: [email protected] > 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? > >
