diff --git a/src/docs/product/issues/issue-details/performance-issues/consecutive-http/consecutive-http-threshold-settings.png b/src/docs/product/issues/issue-details/performance-issues/consecutive-http/consecutive-http-threshold-settings.png new file mode 100644 index 0000000000000..18b4f925cb54c Binary files /dev/null and b/src/docs/product/issues/issue-details/performance-issues/consecutive-http/consecutive-http-threshold-settings.png differ diff --git a/src/docs/product/issues/issue-details/performance-issues/consecutive-http/index.mdx b/src/docs/product/issues/issue-details/performance-issues/consecutive-http/index.mdx index 685fd9d3f9925..fac37893ea24c 100644 --- a/src/docs/product/issues/issue-details/performance-issues/consecutive-http/index.mdx +++ b/src/docs/product/issues/issue-details/performance-issues/consecutive-http/index.mdx @@ -25,12 +25,17 @@ Once this sequence is found, the following must hold true for each HTTP span: Once these spans are found, the following must also hold true: -- The duration of each HTTP span must exceed a threshold of 1000ms. -- The time between each HTTP span must not exceed a threshold of 500ms. -- The number of sequential HTTP spans must exceed a threshold of 3. +- Minimum time saved from parallelization must exceed `2000ms` +- The duration of each HTTP span must exceed a threshold of `900ms`. +- The time between each HTTP span must not exceed a threshold of `500ms`. +- The number of sequential HTTP spans must exceed a threshold of `3`. If Sentry doesn't detect a Consecutive HTTP issue where you expect one, it's probably because the transaction didn't meet one of the above criteria. +You can configure detector thresholds for consecutive HTTP issues in **Project Settings > Performance**: + +![Consecutive HTTP detector threshold settings](consecutive-http-threshold-settings.png) + ## Span Evidence You can find additional information about your Consecutive HTTP issue by looking at two main aspects in the "Span Evidence" section: diff --git a/src/docs/product/issues/issue-details/performance-issues/large-http-payload/index.mdx b/src/docs/product/issues/issue-details/performance-issues/large-http-payload/index.mdx index 4a713567863cc..c13a96f2e7850 100644 --- a/src/docs/product/issues/issue-details/performance-issues/large-http-payload/index.mdx +++ b/src/docs/product/issues/issue-details/performance-issues/large-http-payload/index.mdx @@ -14,7 +14,7 @@ The detector for this performance issue looks for a single http span that meets - The HTTP url must not begin with \_next/static/ or \_next/data/ - The HTTP url must not end with an extension (e.g. .js, .css, .png, .jpg, .jpeg, .mp3), unless the extension is .json -- The HTTP span must have an `http.response_content_length` (added by the `@sentry/browser` SDK, version `7.53.0`) that exceeds 500kb +- The HTTP span must have an `http.response_content_length` (added by the `@sentry/browser` SDK, version `7.53.0`) that exceeds `300kb` - The HTTP span duration must exceed 100ms If Sentry isn't detecting a large HTTP payload issue where you expect one, it's probably because the transaction didn't meet one of the above criteria. diff --git a/src/docs/product/issues/issue-details/performance-issues/large-render-blocking-asset/index.mdx b/src/docs/product/issues/issue-details/performance-issues/large-render-blocking-asset/index.mdx index 399532c4485d4..fd11eef2530b0 100644 --- a/src/docs/product/issues/issue-details/performance-issues/large-render-blocking-asset/index.mdx +++ b/src/docs/product/issues/issue-details/performance-issues/large-render-blocking-asset/index.mdx @@ -14,7 +14,7 @@ The detector for this performance issue looks for specific asset (resource) span - The span operation has to be either a: `resource.link` or `resource.script`. - The span's `resource.render_blocking_status` data property should either have a value of `blocking` (added by the `@sentry/browser` SDK, version `7.38.0`), or be missing. -- The span's `Encoded Body Size` data property has to be over `1MB`. +- The span's `Encoded Body Size` data property has to be over `500kb`. - The [First Contentful Paint (FCP)](/product/performance/web-vitals/#first-contentful-paint-fcp) of the transaction must be at least `2` seconds (with an upper bound of `10` seconds to eliminate outliers). - The span's duration must be at least `33%` of the FCP. diff --git a/src/docs/product/issues/issue-details/performance-issues/n-one-api-calls.mdx b/src/docs/product/issues/issue-details/performance-issues/n-one-api-calls.mdx index 5a7ef78ebc950..78fbae08325aa 100644 --- a/src/docs/product/issues/issue-details/performance-issues/n-one-api-calls.mdx +++ b/src/docs/product/issues/issue-details/performance-issues/n-one-api-calls.mdx @@ -15,13 +15,18 @@ Sentry detects N+1 API Calls in frontend and mobile applications. The detector i The N+1 API Call detector looks for groups of simultaneous network calls to the same URL. It uses the following detection criteria: - Applies to `GET` requests only -- Minimum of 10 network calls must be happening simultaneously -- Network calls must be a minimum of 50ms in duration and within 5ms of each other +- Minimum of `10` network calls must be happening simultaneously +- Total duration of involved spans must exceed `300ms`. +- Network calls must be within `5ms` of each other - Calls can't be to a GraphQL endpoint or to `_next/data` - Calls can't be fetching a static resource (such as `.png` files) - The transaction operation must be `"navigation"`, `"pageload"`, `"ui.load"`, or `"ui.action"` - The span operation must be `"http.client"` +You can configure detector thresholds for N+1 API calls issues in **Project Settings > Performance**: + +![N+1 API Calls detector threshold settings](n-plus-one-api-calls-detector-settings.png) + ## Span Evidence You can identify the root cause of your N+1 API Call problems by looking at three main aspects in the "Span Evidence" section: diff --git a/src/docs/product/issues/issue-details/performance-issues/n-one-queries.mdx b/src/docs/product/issues/issue-details/performance-issues/n-one-queries.mdx index 693159ff26377..7bfdbf7d9d6a4 100644 --- a/src/docs/product/issues/issue-details/performance-issues/n-one-queries.mdx +++ b/src/docs/product/issues/issue-details/performance-issues/n-one-queries.mdx @@ -12,7 +12,7 @@ _N+1 queries_ are a performance problem in which the application makes database The detector for performance issues looks for a set of sequential, non-overlapping database spans with similar descriptions. It also uses the following criteria: -- Total duration of involved spans must exceed a threshold (usually 100 ms) +- Total duration of involved spans must exceed a `90ms` - Total count of involved spans must exceed a threshold (usually five spans) - Involved spans must have full queries as their descriptions (some SDKs truncate queries and add an ellipsis to the end) - There must be at least one database span that precedes the repeating spans (this is called the "source" span, and is used for fingerprinting) diff --git a/src/docs/product/issues/issue-details/performance-issues/n-plus-one-api-calls-detector-settings.png b/src/docs/product/issues/issue-details/performance-issues/n-plus-one-api-calls-detector-settings.png new file mode 100644 index 0000000000000..353d1a9ea2b46 Binary files /dev/null and b/src/docs/product/issues/issue-details/performance-issues/n-plus-one-api-calls-detector-settings.png differ diff --git a/src/docs/product/issues/issue-details/performance-issues/uncompressed-asset/index.mdx b/src/docs/product/issues/issue-details/performance-issues/uncompressed-asset/index.mdx index f0300aaea7794..429506d0073d1 100644 --- a/src/docs/product/issues/issue-details/performance-issues/uncompressed-asset/index.mdx +++ b/src/docs/product/issues/issue-details/performance-issues/uncompressed-asset/index.mdx @@ -14,7 +14,7 @@ The detector for this performance issue looks for specific asset (resource) span - The span has to be one of either: `resource.link` or `resource.script` spans, which in practice means it's a `.css` or `.js` file. - It has to be over `512kb` in size, (to filter out smaller files that are less likely to benefit from being compressed). -- The span duration has to be over `500ms`, (to filter out faster transfers or assets served in internal networks). +- The span duration has to be over `500ms` (to filter out faster transfers or assets served in internal networks). - There has to be another asset span in the transaction that has compressed files. This helps filter out cases where a users' browser isn't sending the `Accept-Encoding` header. If Sentry isn't detecting an uncompressed asset issue where you expect one, it's probably because the transaction didn't meet one of the above criteria. diff --git a/src/platforms/apple/common/install/carthage.mdx b/src/platforms/apple/common/install/carthage.mdx index c40acbe4cc1bf..12fce9df7d60d 100644 --- a/src/platforms/apple/common/install/carthage.mdx +++ b/src/platforms/apple/common/install/carthage.mdx @@ -13,11 +13,11 @@ Run `carthage update` to download the framework and drag the built _Sentry.xcfra Sentry's Carthage setup generates 3 different frameworks: - - Sentry - - SentryPrivate - - SentrySwiftUI +- Sentry +- SentryPrivate +- SentrySwiftUI -_Sentry_ is required for all projects. _SentrySwiftUI_ is required to measure the performance of your SwiftUI views. _SentryPrivate_ is only needed if you changed the carthage build process to generate static frameworks. +_Sentry_ is required for all projects. _SentrySwiftUI_ is required to measure the performance of your SwiftUI views. _SentryPrivate_ is only needed if you changed the carthage build process to generate static frameworks. ## Macs with Apple Silicon and XCFrameworks