[
https://issues.apache.org/jira/browse/PHOENIX-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078321#comment-14078321
]
Jesse Yates commented on PHOENIX-177:
-------------------------------------
Yes, you do. Unless we want to start building an uber-jar that contains all the
phoenix modules (or just the specific ones or some specific ones), but we
already have a pretty complicated jar-build.
You will also need the correct hadoopX compat jar (well, you don't need the
hadoop1 if running on hadoop1 b/c it doesn't have anything in it).
> Collect usage and performance metrics
> -------------------------------------
>
> Key: PHOENIX-177
> URL: https://issues.apache.org/jira/browse/PHOENIX-177
> Project: Phoenix
> Issue Type: Sub-task
> Affects Versions: 5.0.0, 4.1
> Reporter: ryang-sfdc
> Assignee: Jesse Yates
> Labels: enhancement
> Fix For: 5.0.0, 4.1
>
> Attachments: phoenix-177-4.0.patch, phoenix-177-master-v0.patch,
> phoenix-177-master.patch
>
>
> I'd like to know how much cpu, physical io, logical io, wait time, blocking
> time, transmission time was spent for each thread of execution across the
> hbase cluster, within coprocessors, and within the client's phoenix
> threadpools for each query.
> Here are some of the problems I want to solve:
> 1) every component has one or more configurable threadpools, and I have no
> idea how to gather data to make any decisions.
> 2) queries that I think should be fast turn out to be dog slow, e.g., select
> foo from bar where foo like 'abc%' group by foo Without attaching a profiler
> to hbase, which most people won't bother with, it's not clear why it's slow.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
