zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Baskar Duraikannu <baskar.duraika...@outlook.com>
Subject RE: Zookeeper performance
Date Wed, 31 Jul 2013 22:25:26 GMT
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? 
> 
> 
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message