in this case i pool them as well, which doesn't seem to make any
difference (compared to when i just reuse them -- but i am not writing
but outside of the test i do so i do pool them using techniques
similar to those in HTablePool, CAS-based queues etc. )


On Thu, Apr 21, 2011 at 11:09 PM, Ted Dunning <tdunn...@maprtech.com> wrote:
> Dmitriy,
>
> Did I hear you say that you are instantiating a new Htable for each request?
>  Or was that somebody else?
>
> On Thu, Apr 21, 2011 at 11:04 PM, Stack <st...@duboce.net> wrote:
>
>> On Thu, Apr 21, 2011 at 10:49 PM, Dmitriy Lyubimov <dlie...@gmail.com>
>> wrote:
>> > Anyway. For a million requests shot at a region server at various
>> > speeds between 300 and 500 qps the picture is not pretty. RPC metrics
>> > are arctually good -- no more than 1ms average per next() and 0 per
>> > get(). So region server is lightning fast.
>> >
>>
>> This is 3-500 queries per second of 40 rows each?
>>
>> > What doesn't seem so fast is RPC.
>>
>> OK.
>>
>> > As i reported before, i was getting
>> > 25ms TTLB under the circumstances. In this case all the traffic to the
>> > node goes thru same client (but in reality of course the node's
>> > portion per client should be much less). All that traffic is using
>> > single regionserver node rpc queue as HConnection would not open more
>> > than one socket to same region.
>>
>> You saw "HBASE-2939  Allow Client-Side Connection Pooling"?  Would that
>> help?
>>
>>
>> > And tcp doesn't seem to perform very
>> > well for some reason in this scenario.
>> >
>>
>> What do you see here D?
>>
>>
>> > The next thing i did was to enable tcp_nodelay on both client and
>> > server. That got us down even more to 13ms average.
>> >
>>
>> Thats a big difference.
>>
>>
>> > However, it is still about two times slower if i run all processes at
>> > the same machine (i get around 6-7ms average TTLBs for the same type
>> > of scan).
>> >
>> > Ping time for about same packet size between hosts involved seems to
>> > revolve around 1ms. Where another 5ms average time are getting lost is
>> > still a mystery. But oh well i guess it is as good as it gets.
>> > In real life hbase applications traffic would be much more uniformly
>> > distributed among regions and this would be much less of an issue
>> > perhaps.
>> >
>> > I also suspect that using udp for short scans and gets might reduce
>> > latency a bit as well.
>> >
>>
>> Thank you Dmitriy for digging in.  Good stuff.
>> St.Ack
>>
>

Reply via email to