You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@phoenix.apache.org by "Hadoop QA (JIRA)" <ji...@apache.org> on 2019/02/01 21:55:00 UTC
[jira] [Commented] (PHOENIX-5069) Use asynchronous refresh to
provide non-blocking Phoenix Stats Client Cache
[ https://issues.apache.org/jira/browse/PHOENIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16758692#comment-16758692 ]
Hadoop QA commented on PHOENIX-5069:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12957320/PHOENIX-5069-4.14.1-hbase-1.3-phoenix-stats.002.patch
against master branch at commit 52b5d9d5f8d1f41218956bb6099a3d7eaf50939a.
ATTACHMENT ID: 12957320
{color:green}+1 @author{color}. The patch does not contain any @author tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new or modified tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output: https://builds.apache.org/job/PreCommit-PHOENIX-Build/2293//console
This message is automatically generated.
> Use asynchronous refresh to provide non-blocking Phoenix Stats Client Cache
> ---------------------------------------------------------------------------
>
> Key: PHOENIX-5069
> URL: https://issues.apache.org/jira/browse/PHOENIX-5069
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Bin Shi
> Assignee: Bin Shi
> Priority: Major
> Attachments: PHOENIX-5069-4.14.1-hbase-1.3-phoenix-stats.001.patch, PHOENIX-5069-4.14.1-hbase-1.3-phoenix-stats.002.patch, PHOENIX-5069.master.001.patch, PHOENIX-5069.master.002.patch, PHOENIX-5069.master.003.patch, PHOENIX-5069.patch
>
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> The current Phoenix Stats Cache uses TTL based eviction policy. A cached entry will expire after a given amount of time (900s by default) passed since the entry's been created. This will lead to cache miss when Compiler/Optimizer fetches stats from cache at the next time. As you can see from the above graph, fetching stats from the cache is a blocking operation — when there is cache miss, it has a round trip over the wire to scan the SYSTEM.STATS Table and to get the latest stats info, rebuild the cache and finally return the stats to the Compiler/Optimizer. Whenever there is a cache miss, this blocking call causes significant performance penalty and see periodic spikes.
> *This Jira suggests to use asynchronous refresh mechanism to provide a non-blocking cache. For details, please see the linked design document below.*
> [~karanmehta93] [~twdsilva@gmail.com] [~dbwong] [~elserj] [~ankit@apache.org] [~sergey soldatov]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)