Performance Issues | Your Feedback

[nanoburd]

Hey all! I’m the product manager for Performance at Sentry. After releasing our first performance issue type (N+1 DB query), we’re now able to detect several more issue types.

Frontend performance issues:

• N+1 API Calls
• Large Render Blocking Assets
• Uncompressed Frontend Assets
• File I/O on the Main Thread

Backend performance issues:

• MN+1 DB Query
• Consecutive DB Query
• Slow DB Query

*Some of these issue types may be available only to Early Adopters

Your feedback is very much appreciated 😄

We’d love to hear from you on how you’ve been interacting with Performance Issues in Sentry. We’re curious about:

• Whether you’ve encountered any of these new issue types (check here to see all your Sentry performance issues) – and if you’ve been able to take action to resolve them
• What type of info is most helpful when debugging these new performance issues or other performance problems? (e.g. stack trace, breadcrumbs, tags, full trace across projects)
• What are other performance problems you frequently face (and care about fixing)?

[jeengbe]

Hi @nanoburd! Thanks a lot for this discussion, great to hear you are this open to feedback!

These performance issues sound super interesting in theory. Sadly, I haven't got a single performance issue report so far. We clearly have (or had; thanks, Sentry!) a n+1 problem in our GraphQL backend, which went unnoticed: https://prisjakt-ab.sentry.io/performance/bff:19fc625d94ec46bfa87cd7f2520515c9/. Having a look in the docs, backend n+1 API calls are not supported, but that sounds like an easy win for you, given the logic is already in place for frontend API calls.

Other than that, I'm really looking forward to more of these features and seeing them in action!

[gggritso]

@jeengbe thanks for the feedback, I agree! Expanding detection to more SDKs (including backend) is on our near-term agenda

[untitaker]

I would like Sentry to detect performance issues in my use of Redis. There are common antipatterns in Redis usage that can be pretty obvious from the span tree, just like with DB queries. At a minimum, Sentry could detect Redis's equivalent of N+1 queries (many successive commands on keys with similar patterns) and suggest pipelining those commands.

[untitaker]

Yup they are identical spans in succesion. If you get around to working on something like this, I can write a demo app that exhibits the issue. I don't have any examples in prod off the top of my head

[DominikB2014]

@untitaker
Just to confirm, in the transaction we wouldn't see a changing parameter?
Because the spans are identical, it sounds like it could be under consecutive db issue as your making consecutive redis spans in consecutive, that shouldn't be consecutive (they can be done in one).
We can enhance the detector to consider that case!

Off the top of my head, this sounds it wouldn't be too big of an change. A demo app wold make it super helpful to see how the transaction looks like and to test a detector against.

[untitaker]

@DominikB2014 ptal https://github.com/untitaker/redis-nplusone-demo

[DominikB2014]

I had a look at this today, this does look like something we could detect!
I noticed in this case all the consecutive SETS were with keys in the same namespace, i'm not sure if this is a critical component to the issue.

Would it make sense to detect any large amounts of consecutive Redis SETs as they could be combined into a pipeline? Regardless if they share the same namespace?

[untitaker]

were with keys in the same namespace

the problem is that there's no such thing as a namespace, the : separator is just a naming convention that Sentry came up with. I have no idea if anybody else uses it.

[noobd3v3loper]

Hi,

We've hosted the sentry on our on prem server. And did a vulnerability scan on the sentry app. And there are findings. I would like to know how to resolve this findings.

The findings is Content Security Policy Missing on header. What would be the headers that needed to be added on our reverse proxy.

[nanoburd]

Hi, could you create a new github issue and someone from the support/security team can take a look at it? This thread is soliciting feedback about a new feature we launched recently called Performance Issues, you can see these in your issue stream by filtering for issue.category:performance. Thanks!~

[klboke]

@nanoburd Hello, we're using Sentry's Performance Transaction Summary and found that Sentry only calculates and analyzes the p95 value of the selftime of spans, but doesn't analyze the duration of spans. In most cases, people are more concerned about the duration of methods, for example, OpenTelemetry only has duration. So, is it possible to include both selftime and duration in the analysis?

[shaedrich]

I'm using the Laravel SDK and after investigating some N+1 issues, I had a hard time figuring out where exactly the problem originates from. All I get from the issue, is the class of the parent span (I suppose), but I couldn't find the class of the child and especially the line of neither.

Laravel/Eloquent could even go so for in listing the model and the relation name.

[gggritso]

@shaedrich that's fair feedback, thanks! This is something we're working on. Luckily, the Laravel SDK supports Query Sources so it's possible for you to track down the exact line of code. Give it a try! When looking at an N+1 performance issue, scroll down to the span waterfall, and expand the repeated queries. Click on one of them, and the query's source should be there.

[shaedrich]

@gggritso Oh, thanks for the explanation—I missed that somehow! Maybe, the UI there could be a little more … I don't know. I mean, there's a lot of information on each span, I know, and it's generally good to have it (you never know when you need it). But it looks a bit cramped and this way. Maybe, there could be a "simple" mode, where you can see everything at one glance and open details in another tab and a "complex" mode with all the information but no need to open each span's details in a separate tab or the like? 🤔

[gggritso]

@shaedrich understood, thanks! I agree, and the Performance team has been talking about improving the span UI for a while, and we're hoping to work on it soon 👍🏻