Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Thu, 14 Jul 2016 07:27:20 +0000 (UTC)
From: "Junegunn Choi (JIRA)" <jira@apache.org>
To: dev@phoenix.incubator.apache.org
Message-ID: <JIRA.12989365.1468479621000.25468.1468481240582@Atlassian.JIRA>
In-Reply-To: <JIRA.12989365.1468479621000@Atlassian.JIRA>
References: <JIRA.12989365.1468479621000@Atlassian.JIRA> <JIRA.12989365.1468479621889@arcas>
Subject: [jira] [Commented] (PHOENIX-3073) Fast path for single-key point
 lookups
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 14 Jul 2016 07:27:31 -0000


    [ https://issues.apache.org/jira/browse/PHOENIX-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15376491#comment-15376491 ] 

Junegunn Choi commented on PHOENIX-3073:
----------------------------------------

I also found that the client overhead for this particular query was greatly increased recently due to the following change (PHOENIX-3040):

https://github.com/apache/phoenix/commit/f9420e6fb8d635572a7049527db0cc513dbeebe6#diff-8c3d3f644c66ef36d5bc604f017fabfcL144

With the change, the query started to use guideposts (isPointLookup = true, plan.isSerial() = false) and it turns out to be quite costly on the client side. The client CPU usage for the same workload before PHOENIX-3040 is 22.3%.

> Fast path for single-key point lookups
> --------------------------------------
>
>                 Key: PHOENIX-3073
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3073
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: Junegunn Choi
>            Assignee: Junegunn Choi
>         Attachments: PHOENIX-3073.patch
>
>
> While comparing Phoenix JDBC client to the native HBase Java client, I noticed that Phoenix client uses significantly more CPU time on the client machine. Profiling revealed that the majority of the time was spent on {{BaseResultIterators.getParallelScans()}}. This was surprising to me as I was only testing with simple point lookup queries.
> Here's how I tested:
> - {{SELECT /*+ SMALL SERIAL */ ID, DOCID FROM IMAGE WHERE ID = ?}}
>     - {{IMAGE}} is a salted table with 100 salt buckets
>     - {{ID}}, the primary key, was randomly selected in a small range so that the requests are served without disk I/O
> - 20K/sec concurrent requests using 128 threads
> {{getParallelScans()}} is quite expensive as it iterates over all regions of the table which can be many, only to return a single Scan object for this query. Since such a single-key point lookup is one of the most frequent type of requests in a typical OLTP application, I believe it makes sense to have a fast path for it. With the patch, the average CPU usage of the client during the workload dropped to 18.8% from 56.7% before the patch.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)