phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bin Shi (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-5069) Use asynchronous refresh to provide non-blocking Phoenix Stats Client Cache
Date Thu, 13 Dec 2018 19:22:00 GMT

     [ https://issues.apache.org/jira/browse/PHOENIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bin Shi updated PHOENIX-5069:
-----------------------------
    Description: 
Below is the high level picture of Phoenix Stats Cache which is based on Google Guava cache.
 !OmCWFETQAAAABJRU5ErkJggg==! 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 fix this and provide a non-blocking
cache.

  was:
Below is the high level picture of Phoenix Stats Cache which is based on Google Guava cache.
 !OmCWFETQAAAABJRU5ErkJggg==! 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[link title|http://example.com][link
title|http://example.com] to fix this and provide a non-blocking cache.


> 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
>            Priority: Major
>
> Below is the high level picture of Phoenix Stats Cache which is based on Google Guava
cache.
>  !OmCWFETQAAAABJRU5ErkJggg==! 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 fix this and provide a
non-blocking cache.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message