phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <>
Subject Re: [jira] [Updated] (PHOENIX-1118) Provide a tool for visualizing Phoenix tracing information
Date Tue, 09 Jun 2015 18:09:06 GMT
Hi Nishani,
I'd recommend focusing on higher level use cases. From the user's
point of view, they're executing a query and for some reason it's
slower than they expect. How do they figure out why?

They might first do an EXPLAIN on their query to see how Phoenix is
executing it. Which parts are run where? Are secondary indexes being
used as expected? Are filters being pushed down as expected? A better
way to visualize the explain plan might be a good thing for you to
start with.

Second, assuming the explain plan looks good, they'll want to turn on
tracing so that they can get runtime information on which parts of
their query are taking the longest.

Maybe more than one Phoenix table is involved - how will you display
the tracing information across multiple tables for a query that does a
join? Maybe you can punt on this first pass, and focus on single table
queries. A related use case would be a DML statement that's executed
and taking longer than expected. Let's say that the table being
updated has one or more secondary indexes that are also updating the
index tables. Seeing the entire picture of both the table writes plus
the index writes on the same graph would be great.

For the single-table query user case, what does the distribution of
time look like across all the region servers participating in the
query? Maybe some kind of graph that shows quickly if one region
server is taking much more time than the others. Perhaps that's an
indication that the table statistics need to be re-run, as there may
be skew that's developed such that one of the threads is handling more
data than it should. Or perhaps there's an issue with that particular
region server. Was there something else going on at the same time on
that region server, like a background compaction/split process? If
that information is available in the trace table (not sure), it would
be very cool to be able to superimpose that on top of the query trace

Another test might be to run a query over a different table and see if
the same region server shows up again as being slow. So superimposing
the query trace graphs of multiple queries might give the user some

IMHO, this is the kind of angle you should come at this from.


On Mon, Jun 8, 2015 at 4:12 AM, Ayola Jayamaha <> wrote:
> Hi All,
> Basically what type of use cases are you expecting or performing at the
> moment with regard to tracing? For example these are the use cases I'm
> planing.
> 1. Searching by parent id / trace id / description (regx search)
> 2. Grouping and ordering the tracing information by time period.
> 3. Counting the trace count per day / hour.
> 4. Comparing and distinguishing  two sets of tracing.
> Thanks.
> On Mon, Jun 8, 2015 at 4:00 PM, Nishani (JIRA) <> wrote:
>>      [
>> ]
>> Nishani  updated PHOENIX-1118:
>> ------------------------------
>>     Attachment: Screenshot of dependency tree.png
>> Attaching the dependency tree on tracing.
>> Pull request can be found here.
>> > Provide a tool for visualizing Phoenix tracing information
>> > ----------------------------------------------------------
>> >
>> >                 Key: PHOENIX-1118
>> >                 URL:
>> >             Project: Phoenix
>> >          Issue Type: Sub-task
>> >            Reporter: James Taylor
>> >            Assignee: Nishani
>> >              Labels: Java, SQL, Visualization, gsoc2015, mentor
>> >         Attachments: MockUp1-TimeSlider.png, MockUp2-AdvanceSearch.png,
>> MockUp3-PatternDetector.png, MockUp4-FlameGraph.png, Screenshot of
>> dependency tree.png, screenshot of tracing web app.png
>> >
>> >
>> > Currently there's no means of visualizing the trace information provided
>> by Phoenix. We should provide some simple charting over our metrics tables.
>> Take a look at the following JIRA for sample queries:
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.4#6332)
> --
> Best Regards,
> Nishani Jayamaha

View raw message