Introducing Scatter Flow Diagram For Performance Engineering

Other than the application architects, most often than not, performance engineers are the next people to know the overall application architecture and how everything fits together & communicates. Sometimes they are the only ones who understand it better.

A while back a colleague reached out to me and requested I give him a high-level application architecture walk-through. He wanted to have this knowledge so he could debug a performance degradation. During the walk-through of the architecture, I was also producing response time scatter plots from different components to help him with his investigation. I was educating him but also helping him narrow down potential areas to focus his investigate.

Architecture was complex and it required different system data to be analyzed. It became apparent to me that I needed a different and some what simple approach to help him better understand the architecture and make sense of the data. Hence I came up with Scatter Flow Diagram (shown below).

Scatter Flow Diagram is a novel way of combining high-level application architecture with scatter plot. It visualizes ingress and egress response time using scatter plots for each component. It overlays response time from each component onto the application architecture. It shows the flow of response time (right to left) across components and how it varying.

I found the following benefits of using the Scatter Flow Diagram:

• Visually we could see which component(s) are potential areas for his investigation. It gave him the starting point. This also helped him engage the right people to debug and fix the problem (highlighted below).

Leftmost graph response time ranges from 0 to 4000ms. The rightmost graph response time ranges from 0 to 600ms. Plus the leftmost graphs have a higher response time variance compared to the other two.

• He could share this visualization with other team members (within or outside) and observation easily viewable. Diagram visualized the data backing his observation. Teams didn't have to run multiple queries to extract and visualize the data or look at different dashboards.
• Different teams could also see the high-level architecture of how their own component communicates with other component.
• It was easy for us to overlay & visualize how response time was changing across each component.
• Also it highlighted areas where Observability was lacking.

This same diagram can be extended to response code or error rate across different components.

Thanks for reading!

If you enjoyed this article feel free to share on social media

Say Hello on: Linkedin | Twitter

Github repo: hseera