Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of ryanobjc@gmail.com designates
 209.85.216.201 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=HZ9uRWOnV3jeuhxmLB32V/wgq9Yk/kLXVBg6cXYJQQwKkeUt5oNKTtja1FKByU2P/i
         kqY7Hf1/6n2G7zTcl4Pum5hQcfb27sdzY96KenKQglg0aFgnuO1LwKlgYg9gqs/gvyYo
         A9ka9EgONZo+JnlxLoe6/U0O7qM155K18x66o=
MIME-Version: 1.0
Date: Sun, 20 Dec 2009 23:49:54 -0800
Message-ID: <78568af10912202349w237129d4rc0b928add67a8c83@mail.gmail.com>
Subject: i made this fix in my own code
From: Ryan Rawson <ryanobjc@gmail.com>
To: hbase-dev@hadoop.apache.org
Content-Type: text/plain; charset=ISO-8859-1

https://gist.github.com/a0abf6092abf63d394c2

It is very very disturbing... basically cache delete code in the
client doesnt work at all.  I was relying on that code in my new
threaded-put implementation, but it wasnt working and my entire
enterprise was failing.

I have a kick ass patch I'll put up soon. I am seeing substantially
higher aggregate performance left and right. On a huge region count
table (1200), previously a single thread was lucky to get 2000
rows/sec (small rows).  Now I can do 16k rows/sec.  In a map reduce
situation performance is up there at like 300k ops/sec and stays high
with very few brownouts.

Previously I was having problems with cluster performance increasingly
frequently dipping to 0, but now with this multithreaded ability,
things are just groovy.  We survive a split even!

-ryan