feat(perf-issues): Performance Issues EA documentation (#5516)

Add initial explanation for Performance Issues

Author: gggritso

src/docs/product/issues/index.mdx

@@ -42,6 +42,12 @@ Learn more about triaging issues and their different states in [Issue States and
 
 You can also add issues data to your [custom dashboards](/product/dashboards/custom-dashboards/), as widgets, using the [dataset selector](/product/dashboards/widget-builder/#choose-your-dataset).
 
+## Performance Issues
+
+<Include name="early-adopter-note.mdx" />
+
+In addition to collecting application errors, Sentry can also collect performance problems. If your application is configured for [Performance Monitoring](/product/performance), Sentry will detect common performance problems, and group them into issues just like it does with errors. Learn more in [Performance Issues](/product/issues/performance-issues/).
+
 ## Learn More
 
 <PageGrid />

src/docs/product/issues/performance-issues/index.mdx

@@ -0,0 +1,45 @@
+---
+title: "Performance Issues"
+sidebar_order: 15
+description: "Learn more about Performance Issues and how to use them."
+---
+
+<Include name="early-adopter-note.mdx" />
+
+The **Issue Details** page for performance issues helps you to gain further insight into the source of an issue and the impact it has on your application's users. The main area of the page displays information about a specific transaction event that's part of an issue. The top panel and right-hand sidebar of the page display a summary of all the events grouped together in this issue:
+
+![Performance issue](performance-issue-details.png)
+
+<Note>
+
+You can find performance issues by searching `issue.category:performance` in **Issues**, **Discover**, and **Dashboards**.
+
+</Note>
+
+While the **Issue Details** page displays information about a specific transaction event that's part of an issue, you can navigate between the events of an issue using the "Older" and "Newer" buttons. You'll see information about the issue as well as the details of the most recent event. You'll also be able to see the summary of when the issue was seen, a breakdown of the tags, span evidence, and breadcrumbs if they are available.
+
+## How Performance Issues Work
+
+Sentry detects performance issues by scanning incoming transaction events. First we check various properties of the transaction (span durations, span arrangement, span types, and so on) to detect likely problems. We then check these properties against corresponding thresholds to determine whether a performance issue exists. Lastly, we generate a unique problem fingerprint based on the problem type and location in the application, and use that fingerprint to create a performance issue.
+
+## Tags
+
+Tags are key/value string pairs that are both indexed and searchable. For example, a tag provides you with information such as the browser, device, or user associated with the event. Tags are the diagnostic information sent by the SDK for the individual event.
+
+The tags displayed in the main section of this page are specific to the event that you're viewing. In contrast, the tags displayed in the right-hand sidebar are a summary of all tag values for all events included in the issue. You can set your own tags to make them more useful for debugging as described in Customize Tags.
+
+## Span Evidence
+
+Span evidence is information that explains the performance problem in the context of the current event. It may include details like the specific database queries that cause the problem, the spans that contain the problem, and the slow spans that have an impact on performance. This section also has a span tree which shows how the problematic spans relate to the rest of the event. Different performance problems will have slightly different kinds of evidence.
+
+## Performance Issue Limitations
+
+Performance issues currently have the following limitations:
+
+- Sentry only detects one type of issue: [N+1 Queries](n-one-queries)
+- You cannot create alerts for performance issues
+- Performance issues cannot be merged or deleted
+- Custom fingerprinting and grouping do not apply to performance issues
+- Performance issues only support simple ignore rules
+
+We're working on removing some or all of these limitations.

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

@@ -0,0 +1,52 @@
+---
+title: "N+1 Queries"
+sidebar_order: 10
+description: "Learn more about N+1 queries and how to diagnose and fix them."
+---
+
+<Include name="early-adopter-note.mdx" />
+
+_N+1 queries_ are a performance problem in which the application makes database queries in a loop, instead of making a single query that returns all the information at once. Each database connection takes some amount of time, so querying the database in a loop can be many times slower than doing it just once. This problem often occurs when you use an object-relational mapping (ORM) tool in web frameworks like Django or Ruby on Rails.
+
+## Span Evidence
+
+The evidence for an N+1 queries problem has four main aspects:
+
+- Transaction name
+- Parent span - This can be a view, a serializer, or another span that logically groups the queries.
+- Source span - This is the query that caused the N+1 queries.
+- Repeating span - This is the "N" of N+1 queries. This is the looped query that should have been part of the source.
+
+![N+1 Query span evidence](n-plus-one-span-evidence.png)
+
+## Example
+
+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:
+
+```python
+from django.http import HttpResponse
+
+def books(request):
+    books = Book.objects.all()[:10]
+    book_list = [book.title + " by " + book.author.name for book in books]
+    return HttpResponse((", ").join(book_list))
+```
+
+This code has a subtle performance problem. Each call to `book.author.name` makes a query to fetch the book's author. In total, this code makes 11 queries: one query to fetch the list of books, and 10 more queries to fetch the author of each book. This results in a characteristic query span waterfall:
+
+![N+1 queries in an example application](n-plus-one-queries-before.png)
+
+In order to fix this performance issue, you could use the `selected_related` method in Django, like so:
+
+```python
+from django.http import HttpResponse
+
+def books(request):
+    books = Book.objects.select_related("author").all()[:10]
+    book_list = [book.title + " by " + book.author.name for book in books]
+    return HttpResponse((", ").join(book_list))
+```
+
+Django will `JOIN` the tables ahead of time, and preload the author information. That way, calling `book.author.name` does not need to make an extra query. Instead of a long waterfall, there is a single `SELECT` query:
+
+![Solved N+1 queries in an example application](n-plus-one-queries-after.png)