phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mujtaba Chohan <>
Subject Re: Phoenix has slow response times compared to HBase
Date Wed, 31 Aug 2016 17:40:07 GMT
Something seems inherently wrong in these test results.

* How are you running Phoenix queries? Were the concurrent Phoenix queries
using the same JVM? Was the JVM restarted after changing number of
concurrent users?
* Is the response time plotted when query is executed for the first time or
second or average of both?
* Is the UUID filtered on randomly distributed? Does UUID match a single
* It seems that even non-concurrent Phoenix query which filters on UUID
takes 500ms in your environment. Can you try the same query in Sqlline a
few times and see how much time it takes for each run?
* If it's slow in Sqlline as well then try truncating your SYSTEM.STATS
* Can you share your table schema and how you ran Phoenix queries and your
HBase equivalent code?

On Wed, Aug 31, 2016 at 5:42 AM, Narros, Eduardo (ELS-LON) <> wrote:

> Hi,
> We are exploring starting to use Phoenix and have done some load tests to
> see whether Phoenix would scale. We have noted that compared to HBase,
> Phoenix response times have a much slower average as the number of
> concurrent users increases. We are trying to understand whether this is
> expected or there is something we are missing out.
> This is the test we have performed:
>    - Create table (20 columns) and load it with 400 million records
>    indexed via a column called 'uuid'.
>    - Perform the following queries using 10,20,100,200,400 and 600 users
>    per second, each user will perform each query twice:
>       - Phoenix: select * from schema.DOCUMENTS where uuid = ?
>       - Phoenix: select /*+ SERIAL SMALL */* from schema.DOCUMENTS where
>       uuid = ?
>       - Hbase equivalent to: select * from schema.DOCUMENTS where uuid = ?
>    - The results are attached and they show that Phoenix response times
>    are at least an order of magnitude above those of HBase
> The tests were run from the Master node of a CDH5.7.2 cluster with Phoenix
> 4.7.0.
> Are these test results expected?
> Kind Regards,
> Edu
> ------------------------------
> Elsevier Limited. Registered Office: The Boulevard, Langford Lane,
> Kidlington, Oxford, OX5 1GB, United Kingdom, Registration No. 1982084,
> Registered in England and Wales.

View raw message