[
https://issues.apache.org/jira/browse/PHOENIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16721910#comment-16721910
]
ASF GitHub Bot commented on PHOENIX-5069:
-----------------------------------------
GitHub user BinShi-SecularBird opened a pull request:
https://github.com/apache/phoenix/pull/416
PHOENIX-5069 please go to JIRA to see the detailed design document at…
…tached.
PHOENIX-4998 The estimated instance size of GuidePostsInfo doesn't count
the last update timestamp array.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/BinShi-SecularBird/phoenix PHOENIX-5069
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/phoenix/pull/416.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #416
----
commit 69801e540246d998d02abf90705edc3dd5835dcc
Author: Bin <bshi@...>
Date: 2018-10-28T19:21:27Z
PHOENIX-5069 please go to JIRA to see the detailed design document attached.
PHOENIX-4998 The estimated instance size of GuidePostsInfo doesn't count
the last update timestamp array.
----
> 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
>
> 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] [[email protected]] [~dbwong] [~elserj] [[email protected]]
> [~sergey soldatov]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
