Re: Is first query to a table region way slower?

2018-01-28 Thread James Taylor
Did you do an rs.next() on the first query? Sounds related to HConnection
establishment. Also, least expensive query is SELECT 1 FROM T LIIMIT 1.

Thanks,
James

On Sun, Jan 28, 2018 at 5:39 PM Pedro Boado  wrote:

> Hi all,
>
> I'm running into issues with a java springboot app that ends up querying a
> Phoenix cluster (from out of the cluster) through the non-thin client.
>
> Basically this application has a high latency - around 2 to 4 seconds -
> for the first query per  primary key to each region of a table with 180M
> records ( and 10 regions ) . Following calls - for different keys within
> the same region - have an average response time of ~60-80ms. No secondary
> indexes involved. No writes to the table at all during these queries.
>
> I don't think it's related to HConnection establishing as it was already
> stablished before the query ran ( a SELECT * FROM table LIMIT 1 is executed
> as soon as the datasource is created )
>
> I've been doing some quick profiling and almost all the time is spent
> inside the actual jdbc call.
>
> So here's the question: in your experience, is this normal behaviour - so
> I have to workaround the problem from application code warming up
> connections during app startup -  or is it something unusual? Any
> experience reducing first query latencies?
>
> Thanks!
>
>


Is first query to a table region way slower?

2018-01-28 Thread Pedro Boado
Hi all,

I'm running into issues with a java springboot app that ends up querying a
Phoenix cluster (from out of the cluster) through the non-thin client.

Basically this application has a high latency - around 2 to 4 seconds - for
the first query per  primary key to each region of a table with 180M
records ( and 10 regions ) . Following calls - for different keys within
the same region - have an average response time of ~60-80ms. No secondary
indexes involved. No writes to the table at all during these queries.

I don't think it's related to HConnection establishing as it was already
stablished before the query ran ( a SELECT * FROM table LIMIT 1 is executed
as soon as the datasource is created )

I've been doing some quick profiling and almost all the time is spent
inside the actual jdbc call.

So here's the question: in your experience, is this normal behaviour - so I
have to workaround the problem from application code warming up connections
during app startup -  or is it something unusual? Any experience reducing
first query latencies?

Thanks!