Welcome back to another Sentry Snack of the Week. Today, I’m going to introduce you to Suspect Spans. Specifically, how you can use suspect spans to identify opportunity to cache, and therefore improve performance.
Did you know that Sentry’s Suspect Spans can help you identify redundant queries? And potentially opportunities to cache data so that you don’t have to make redundant queries? Well, I was pretty impressed by this when I read about it on our blog, and I wanted to tell you a little bit about it.
Before we jump in, I want to define a couple of terms. A “span” is an operation taking place on a service. And a “trace” is that end-to-end journey of one or more connected spans. And when you’re looking to improve performance, identifying slow spans is often a great place to start. Suspect Spans is a performance feature that surfaces a list of spans that are connect to the most most time spent within a transaction. Not only does this help us identify when we might have redundant queries, or redundant spans, but it actually reduces our time as developers as well, because now we don’t have to compare spans across transactions, and instead can just take a look at this list.
With the help of suspect spans, we here at Sentry actually discovered that there were these four queries happening seventeen times! Meaning a total of 68 queries!
We were able to cache the data that was returned back from those queries the first time, reducing it to only four queries, which was a 35% improvement.
Ultimately, caching isn’t always the answer, unfortunately, but redundant queries is definitely an example of when caching is a good idea, and will likely lead to a performance improvement. Suspect Spans can be a great way to help to identify when caching can help.
And don’t forget to like, subscribe and follow us on YouTube. You don’t want to miss anymore of these Sentry Snacks of the Week.
Want to learn more about how Suspect Spans play a role in performance improvements? Check out our blog post on how full stack visibility is useful for finding the root cause of a slowdown
Director of DevRel, Sentry