How many regions? How are they distributed? Typically it is good to fill the table some what and then drive some splits and balance operations via the shell. One more split to make the regions be local and you should be good to go. Make sure you have enough keys in the table to support these splits, of course.
Under load, you can look at the hbase home page to see how transactions are spread around your cluster. Without splits and local region files, you aren't going to see what you want in terms of performance. On Tue, Apr 19, 2011 at 4:46 PM, Dmitriy Lyubimov <dlyubi...@apache.org> wrote: > Hi, > > I would like to see how i can attack hbase performance. > > Right now i am shooting scans returning between 3 and 40 rows and > regardless of data size, approximately 500-400 QPS. The data tables > are almost empty and in-memory, so they surely should fit in those 40% > heap dedicated to them. > > My local 1-node test shows read times between 1 and 2 ms. Great. > > As soon as i go to our 10-node cluster, the response times drop to > 25ms per scan, regardless of # of records. I set scan block cache size > to 100 (rows?), otherwise i was getting outrages numbers reaching as > far out as 300-400ms. > > It's my understanding the timing should be actually still much closer > to my local tests than to 25ms. > > So... how do i attack this ? increase regionserver handler count? What > the latency should i be able to reach for extremely small data records > (<=200bytes)? > > (CDH3b4). HBase debug logging switched off. > > Thanks in advance. > -Dmitriy >
