Yep. In all benchmarks response times for tiny data start at about 1-2ms but not in our new setup. Which is why I am at loss where to start looking. Seems like a network congestion but it can't be. Its a barebone setup and admins tell me they have tested it for performance.
apologies for brevity. Sent from my android. -Dmitriy On Apr 19, 2011 6:29 PM, "Ted Dunning" <[email protected]> wrote: > For a tiny test like this, everything should be in memory and latency > should be very low. > > On Tue, Apr 19, 2011 at 5:39 PM, Dmitriy Lyubimov <[email protected]> wrote: >> PS so what should latency be for reads in 0.90, assuming moderate thruput? >> >> On Tue, Apr 19, 2011 at 5:39 PM, Dmitriy Lyubimov <[email protected]> wrote: >>> for this test, there's just no more than 40 rows in every given table. >>> This is just a laugh check. >>> >>> so i think it's safe to assume it all goes to same region server. >>> >>> But latency would not depend on which server call is going to, would >>> it? Only throughput would, assuming we are not overloading. >>> >>> And we clearly are not as my single-node local version runs quite ok >>> response times with the same throughput. >>> >>> It's something with either client connections or network latency or >>> ... i don't know what it is. I did not set up the cluster but i gotta >>> troubleshoot it now :) >>> >>> >>> >>> On Tue, Apr 19, 2011 at 5:23 PM, Ted Dunning <[email protected]> wrote: >>>> 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. >>>> >>> >>
