[
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)
