- Start Date: 2022-10-04
- RFC Type: feature
- RFC PR:
Performance issues has started with detecting N+1 issues and adding them to the issues page. This was a first proof of concept, now we are looking to add different types of performance issues to and group those events on the issues page. However there is an drawback of performance spans and transactions versus error events. Error events have titles and stack traces which can provided unique meta-data for fingerprinting and grouping. Today spans do not necessarily provide enough distinct metadata to be able to efficaciously group performance events.
We want to enable scaling out the number of different types of performance issues which can be detected and grouped.
We need communicate the issue around fingerprinting for performance issues, and suggest different ways to add more contextual data to improve fingerprinting. Alternatively we are open to solutions which work around fingerprinting.
Example performance issue type proposals (only ideation from this list and for context not commitments for delivery):
- Slow DB spans
- Consecutive similar spans
- Identical spans
- N+1 DB Queries
- N+1 API Calls
- UI Freeze
- Slow Assets
- Component Re-renders
- Main thread I/O + ANR/Slow Frame
- Shader Compilation
- Txn Deviations
- Cancelled HTTP Requests / Flaky Network
- Degraded performance for a demographic
- Excessive DOM size
https://www.notion.so/sentry/dff3aad2a74940779c3e89d8d8af2537?v=03d1efc28741433c9a203b92fe4cef6e
- Client side/SDK Includes application file name in span/transaction
- Can we fetch more info on Sentry server side from profiling if available
- Could SDKs detect something and create a unique identifier artificially to empower fingerprinting?
Depending on where we put the logic for adding more contextual data, would we be adding too much overhead in SDKs/host application.
- Can we specify why fingerprinting is required?
- what the threshold would be for uniqueness to enable fingerprinting for performance issues?