phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: Phoenix response time
Date Fri, 05 Sep 2014 17:38:44 GMT
One other factor, Vikas. Make sure you don't include the connection
time in your measurements. For example, if you use psql.py to run the
query, it connects to the cluster, runs the query, and disconnects.
Establishing a connection can take 2-3 seconds. If you use sqlline.py
on the other hand, it keeps the connection open once started. Then you
can get a better idea of query times as you run them one after
another.

A second important factor is what is already in the HBase block cache.
Make sure you either run the query several times (if you want to take
this into account), or clear the block cache after each run (if you
don't).

Thanks,
James

On Fri, Sep 5, 2014 at 9:00 AM, James Taylor <jamestaylor@apache.org> wrote:
> Hi Vikas,
> Please post your schema and query as it's difficult to have a discussion
> without those. Also if you could post your HBase code, that would be
> interesting as well.
> Thanks,
> James
>
>
> On Friday, September 5, 2014, yeshwanth kumar <yeshwanth43@gmail.com> wrote:
>>
>> hi vikas,
>>
>> we used phoenix on a 4 core/23Gb machine, as a single node setup.
>> used HDP 2.1
>> our table has 50-70M rows,
>> select on that table took less than 2 seconds.
>> Aggregation queries took less than 8 seconds.
>> for achieving good performance we created secondary index on the table.
>>
>> make sure you finetuned hbase,
>> enabling compression on the data makes a difference in response.
>> if u distribute the data and load over all regions in hbase,
>> look at the performance tips mentioned in phoenix blog
>>
>> -yeshwanth
>>
>>
>>
>> Cheers,
>> Yeshwanth
>>
>>
>>
>> On Fri, Sep 5, 2014 at 5:42 PM, Vikas Agarwal <vikas@infoobjects.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> Preface: We are testing phoenix using Hortonworks distribution for HBase
>>> on Amazon EC2 instance (r3.large, 2 CPU/15 GB RAM).
>>>
>>> With contrast to performance benchmarks, I found Phoenix to be very slow
>>> in querying even on primary key or row key. So, tried to increase the RAM
>>> for HBase and Phoenix and increasing the CPU and RAM by upgrading the EC2
>>> machine type to r3.xlarge (4 CPU, 30 GB RAM). Results were like this:
>>>
>>> Time takes in returning result of query on row key:
>>> With Storm running and very less RAM available: 50 sec
>>>
>>> With Storm stopped and RAM available to Phoenix and HBase: 18 sec
>>>
>>> With new machine of next higher category (4 CPU and 30 GB RAM): 8 sec
>>>
>>> Pure HBase query by row key with Storm stopped and (2 CPU, 15 GB RAM):
>>> 0.0150 seconds. :)
>>>
>>> So, the difference seems to be many fold of what native HBase is
>>> providing to us. I am not able to understand how it can be possible? What I
>>> am missing here?
>>>
>>> --
>>> Regards,
>>> Vikas Agarwal
>>> 91 – 9928301411
>>>
>>> InfoObjects, Inc.
>>> Execution Matters
>>> http://www.infoobjects.com
>>> 2041 Mission College Boulevard, #280
>>> Santa Clara, CA 95054
>>> +1 (408) 988-2000 Work
>>> +1 (408) 716-2726 Fax
>>
>>
>

Mime
View raw message