N+1 Queries pointing to line of code

[realkosty]

Problem Statement

Prospective customer would like Sentry's N+1 Query performance issue to point to the line of code where the offending query appears in their code. They have recently become aware there are a lot of places in their code where it happens and it would make it easier if Sentry let them immediately correct this without having to search across a large number of potentially similar-looking database queries (please see Jira ticket for details).

Solution Brainstorm

No response

┆Issue is synchronized with this Jira Improvement by Unito

[realkosty]

Potential workaround could be using something like the Bullet library for Ruby (integrates with Sentry): https://github.com/flyerhzm/bullet

[dalezak]

Bullet integration with Sentry would work great in development or staging environments, however Bullet doesn't recommend enabling it in production environments due to performance impact. So seeing code snippet related to N+1 queries would still be very valuable in Sentry.

[getsantry]

Routing to @getsentry/visibility for triage, due by Tue Jan 17 2023 19:35:51 GMT+0000. ⏲️

[narsaynorath]

Added feature request and backlog labels for now. Albert's on the corresponding Jira ticket and aware of this

[leoplct]

+1 it’s supported by ScoutAPM and it’s great! Very easy to find how to fix. With the current Sentry solution is a pain to find what is the line of code causing the issue.

[getsantry]

Routing to @getsentry/product-owners-performance for triage ⏲️

[realkosty]

This is now supported for Django and Laravel: #62118

[gggritso]

Yep, this is supported in Sentry now, but with a caveat: collecting query sources has performance overhead, so we only do it for slow queries where the query's duration outweighs the performance overhead of collecting the query source.

We set a threshold for the minimum query duration depending on the framework: 100ms by default in all Python frameworks, 0ms in Laravel. N+1 queries are often pretty fast (much faster than 100ms), it's their amount that matters. In this case, in order to get query sources, customers might need to set a very low threshold. If they do this, it's a good idea to keep an eye on overall app performance.

Maybe turning down the threshold temporarily to find the source of the queries is a good idea in this case.

Also, the customer who filed the issue is using a Ruby framework, which we don't support yet, tracking that as a feature request here: getsentry/sentry-ruby#2242

[realkosty]

@gggritso thanks for the details, super helpful!