Skip to content

Commit 8b90ecd

Browse files
gggritsolizokm
andauthored
feat(perf-issues): Clarify N+1 Queries issues (#6028)
* Clarify span truncation * Explain the source span * Add note about fingerprinting Co-authored-by: Liza Mock <[email protected]>
1 parent 001bede commit 8b90ecd

File tree

1 file changed

+6
-1
lines changed

1 file changed

+6
-1
lines changed

src/docs/product/issues/issue-details/performance-issues/n-one-queries.mdx

+6-1
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,8 @@ The detector for performance issues looks for a set of sequential, non-overlappi
1414

1515
- Total duration of involved spans must exceed a threshold (usually 100 ms)
1616
- Total count of involved spans must exceed a threshold (usually five spans)
17-
- Involved spans cannot be truncated
17+
- Involved spans must have full queries as their descriptions (some SDKs truncate queries and add an ellipsis to the end)
18+
- There must be at least one database span that precedes the repeating spans (this is called the "source" span, and is used for fingerprinting)
1819

1920
If Sentry is not detecting an N+1 issue where you expect one, it's probably because the transaction didn't meet one of the above criteria.
2021

@@ -28,6 +29,10 @@ The evidence for an N+1 queries problem has four main aspects:
2829

2930
![N+1 Query span evidence](n-plus-one-span-evidence.png)
3031

32+
## Fingerprinting
33+
34+
Sentry computes the issue fingerprint based on the parent span, the source span, and the repeating spans. If you're finding that Sentry is failing to correctly group N+1 query issues, make sure that the database spans in your transactions have parameterized queries as the span description. For example, the span description `SELECT * FROM books WHERE books.id = 1` is not parameterized correctly because it includes the book ID. The book ID parameter should vary for each query. This would create different fingerprints and separate issues. A correct span description should look something like this: `SELECT * FROM books WHERE books.id = %s`. While Sentry attempts to parameterize queries while fingerprinting, it may miss some cases.
35+
3136
## Example
3237

3338
Consider a book review website. It has two ORM models, `Book` and `Author`, each with a corresponding database table. The website shows a list of the ten oldest books and their respective authors. The code might look like this:

0 commit comments

Comments
 (0)