Outliers are some of the most difficult data points to deal with in any visualization. Depending on the type of visualization and the type of data, they may be critically important to understanding the value of the data, or they may simply be extraneous noise that in reality are unexplainable anomalies and not representative of the dataset. As a result, when designing an interactive feature, we always try to design for extremes in such a way that outliers can be brought in and out of the visualization depending on the context in which you are viewing the data.
The Heatmap
One of the most useful features of Tracelytics is the heatmap visualization of requests. It shows the time window on the X axis, left to right, with each point plotting a distribution of requests. The Y axis shows request latency with the color density in proportion with the amount of data we see there.
This heatmap is taken from TR Jordan’s post on evaluating the performance of your application (Let’s Talk About Your Performance). The heatmap shows data from memcache, which typically has very short calls, but here we see abnormalities such as the traffic spike just after 6:15PM that caused the latency to temporarily increase. This is a great example of a visualization calling out web performance issues.
The Problem with the Heatmap
But not all heatmaps are this evenly distributed. Often a group of request in a given time window are much slower or faster the the majority of requests. This results in a heatmap, which is very difficult to read and interpret:
Clearly, well above 90% of the data falls under 2.0sec, but a range of calls are showing up between 2.0 and 12.0 sec. This compresses the majority of data to the bottom most portion of the visualization. What If we wanted to focus on the requests with latency between 0 – 2.0 sec? Well, we could have shown only the top 90% of requests from the dataset assuming you are most interesting in the cluster of requests. But This assumes that you are not interested in those outliers. And more importantly, by hiding those outliers, you would lose the context in which the majority of requests exist.
The Solution
The solution we implemented we call the mini-heatmap. It is a flyout context window which allows you to focus the main heatmap onto the latency time window that you are interested in. By default, when you arrive on a heatmap page, the main visualization is focused on the top 98% of requests, just as a starting point. With this implementation we were able to satisfy our requirements:
1. Let the user know what they are viewing
On page load, the top 98% of requests are shown, and a note at the top of the heatmap gives the user information on what time window of latency is being shown
2. Allow the user to select their own time window
The user viewing the heatmap may be interested in outliers, or may want to investigate the majority of requests. When clicked, the flyout shows a mini-heatmap for all the requests in the time window, allowing the user to refocus the main heatmap to the area important to investigation. Even when the main heatmap is refocused this enables the user can be kept aware of outliers or conversely the majority of requests.
3. Quickly include outliers
When the main heatmap is refocused, we provide link bars for the user to quickly include the requests above or below the focused latency window you have chosen.
So What’s Next?
As you can see, by refocusing the latency window of the heatmap you unlock a wealth of data. Leave us comments below and let us know what you think of our solution, what you think can be improved, or what features of visualization you woud like us to cover next.