On Thu, May 14, 2009 at 1:07 PM, Joey Echeverria <[email protected]> wrote:
> With a 5 server zk ensemble and an 80% write ratio, you should be able > to support about 10,000 operations per second[1]. That sounds > reasonable to me for most uses that require locks. If you require > higher performance than that, then locking probably isn't for you. > Taking advantage of versioning or other optimistic concurrency control > is probably necessary. > Sounds like it won't scale (smile). IIRC, currently, the THBase implementation has client run transaction. It uses OCC. I suppose ZK would help guard against case where client dies mid-transaction. > At a minimum, I think it makes sense to have zk-based locks as an > alternative to the current locks which tie up an RPC thread. Testing > will probably required to see how it performs under various > assumptions. > We're tying up a RPC listener at moment because client just waits on lock instead of first checking and if taken, retrying later. Shouldn't be too hard to fix, hopefully in a way that doesn't impinge on the default row-based-lock-for-the-single-access case. St.Ack
