[
https://issues.apache.org/jira/browse/PHOENIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16736560#comment-16736560
]
ASF GitHub Bot commented on PHOENIX-5069:
-----------------------------------------
Github user karanmehta93 commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/425#discussion_r245852592
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/query/GuidePostsCache.java ---
@@ -59,22 +59,36 @@
private final ConnectionQueryServices queryServices;
private final LoadingCache<GuidePostsKey, GuidePostsInfo> cache;
+ private final ExecutorService executor;
public GuidePostsCache(ConnectionQueryServices queryServices,
Configuration config) {
this.queryServices = Objects.requireNonNull(queryServices);
+
+ // The size of the thread pool used for refreshing cached table
stats
+ final int statsCacheThreadPoolSize = config.getInt(
+ QueryServices.STATS_CACHE_THREAD_POOL_SIZE,
+ QueryServicesOptions.DEFAULT_STATS_CACHE_THREAD_POOL_SIZE);
+
+ executor = Executors.newFixedThreadPool(statsCacheThreadPoolSize);
--- End diff --
The thread pool should be initialized only if stats are enabled.
> 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)
