[
https://issues.apache.org/jira/browse/PHOENIX-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349234#comment-14349234
]
James Taylor commented on PHOENIX-1452:
---------------------------------------
[~samarthjain] - looks very good. +1 to Jan's feedback. Couple of very minor
nits:
- In MutationState, I think we should have independent checks for
logger.isDebugEnabled() versus PhoenixMetrics.isMetricsEnabled(), with the loop
doing the work surrounded by:
{code}
if (logger.isDebugEnabled() || PhoenixMetrics.isMetricsEnabled()) {
...
}
{code}
- Minor stylistic issue, but do you think it's better to do a static import of
PhoenixMetrics.SizeMetric.* and PhoenixMetric.CountMetric.* rather than repeat
that everywhere for readability? Up to you.
+1 after these changes for 4.0 and master branch.
> Add Phoenix client-side logging and capture resource utilization metrics
> ------------------------------------------------------------------------
>
> Key: PHOENIX-1452
> URL: https://issues.apache.org/jira/browse/PHOENIX-1452
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 5.0.0, 4.2
> Reporter: Jan Fernando
> Assignee: Samarth Jain
> Attachments: PHOENIX-1452.patch, PHOENIX-1452_v2.patch,
> PHOENIX-1452_v3.patch, wip.patch
>
>
> For performance testing and tuning of features that use Phoenix and for
> production monitoring it would be really helpful to easily be able to extract
> statistics about Phoenix's client-side Thread Pool and Queue Depth usage to
> help with tuning and being able to correlate the impact of tuning these 2
> parameters to query performance.
> For global per JVM logging one of the following would meet my needs, with a
> preference for #2:
> 1. A simple log line that that logs the data in ThreadPoolExecutor.toString()
> at a configurable interval
> 2. Exposing the ThreadPoolExecutor metrics in PhoenixRuntime or other global
> client exposed class and allow client to do their own logging.
> In addition to this it would also be really valuable to have a single log
> line per query that provides statistics about the level of parallelism i.e.
> number of parallel scans being executed. I don't full explain plan level of
> data but a good heuristic to be able to track over time how queries are
> utilizing the thread pool as data size grows etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
