From 4059ca2a2612bda13bc283c84fa0239e964edb26 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Thu, 28 Nov 2024 16:19:36 +0100 Subject: [PATCH 01/36] feat(replay): Mobile Replay performance overhead --- .../session-replay/performance-overhead.mdx | 28 +++++++++ .../session-replay/performance-overhead.mdx | 22 +++++++ .../session-replay/performance-overhead.mdx | 40 +++++++++++++ .../mobile/performance-overhead.mdx | 57 +++++++++++++++++++ 4 files changed, 147 insertions(+) create mode 100644 docs/platforms/android/session-replay/performance-overhead.mdx create mode 100644 docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx create mode 100644 docs/platforms/react-native/session-replay/performance-overhead.mdx create mode 100644 docs/product/explore/session-replay/mobile/performance-overhead.mdx diff --git a/docs/platforms/android/session-replay/performance-overhead.mdx b/docs/platforms/android/session-replay/performance-overhead.mdx new file mode 100644 index 00000000000000..206836518c8b4c --- /dev/null +++ b/docs/platforms/android/session-replay/performance-overhead.mdx @@ -0,0 +1,28 @@ +--- +title: Performance Overhead +sidebar_order: 5502 +notSupported: +description: "Learn more about how enabling Session Replay impacts the performance of your application." +--- + +The only way to get accurate metrics is to measure performance overhead yourself. You can apply realistic access patterns against your own application, and correlate that to your own topline business metrics. You can learn more about the various optimizations implemented in the Android Replay SDK in the [Replay Performance Overhead](/product/explore/session-replay/mobile/performance-overhead/) documentation. + +We measured the overhead of the Android Replay SDK using the [Pocket Casts](https://github.com/Automattic/pocket-casts-android) open-source app, which includes a diverse set of components such as Fragments, Activities, and Jetpack Compose screens. The benchmarks were conducted with full masking enabled, using optimized release builds, and running through the same user flow 10 times. This approach ensured the measurements closely reflect the overhead in a real-world application. Here are the results (median values are shown): + +| Metric | Sentry SDK only | Sentry + Replay SDK | +| -------------------------------- | --------------- | ------------------- | +| FPS | 55 fps | 54 fps | +| Memory | 255 MB | 265 MB | +| CPU | 36% | 42% | +| App Startup Time (Cold) | 1533.35 ms | 1539.55 ms | +| Main Thread Time | - | 20ms | +| Network Bandwidth | - | 35 KB | + + +The benchmarks were run on a Pixel 2XL with Android 11. + + + +Jetpack Compose view hierarchies may be slower to snapshot initially due to ART optimizations compared to the traditional Android View System, but their performance improves as execution progresses. + + diff --git a/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx b/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx new file mode 100644 index 00000000000000..aa4f902416e107 --- /dev/null +++ b/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx @@ -0,0 +1,22 @@ +--- +title: Performance Overhead +sidebar_order: 5502 +notSupported: +description: "Learn more about how enabling Session Replay impacts the performance of your application." +--- + +The only way to get accurate metrics is to measure performance overhead yourself. You can apply realistic access patterns against your own application, and correlate that to your own topline business metrics. You can learn more about the various optimizations implemented in the iOS Replay SDK in the [Replay Performance Overhead](/product/explore/session-replay/mobile/performance-overhead/) documentation. + +We measured the overhead of the iOS Replay SDK using the [Pocket Casts](https://github.com/Automattic/pocket-casts-ios) open-source app, which includes a diverse set of components such as ViewControllers and SwiftUI screens. The benchmarks were conducted with full masking enabled, using optimized release builds, and running through the same user flow 10 times. This approach ensured the measurements closely reflect the overhead in a real-world application. Here are the results (median values are shown): + +| Metric | Sentry SDK only | Sentry + Replay SDK | +| -------------------------------- | --------------- | ------------------- | +| FPS | 55 fps | 53 fps | +| Memory | 102 MB | 121 MB | +| CPU | 4% | 13% | +| App Startup Time (Cold) | 1264.80 ms | 1265 ms | +| Main Thread Time | - | 43ms | +| Network Bandwidth | - | 50 KB | + + +The benchmarks were run on an iPhone 14 Pro. diff --git a/docs/platforms/react-native/session-replay/performance-overhead.mdx b/docs/platforms/react-native/session-replay/performance-overhead.mdx new file mode 100644 index 00000000000000..fd60795ed57926 --- /dev/null +++ b/docs/platforms/react-native/session-replay/performance-overhead.mdx @@ -0,0 +1,40 @@ +--- +title: Performance Overhead +sidebar_order: 5502 +notSupported: +description: "Learn more about how enabling Session Replay impacts the performance of your application." +--- + +The only way to get accurate metrics is to measure performance overhead yourself. You can apply realistic access patterns against your own application, and correlate that to your own topline business metrics. You can learn more about the various optimizations implemented in the React Native Replay SDK in the [Replay Performance Overhead](/product/explore/session-replay/mobile/performance-overhead/) documentation. + +The React Native Replay SDK is a lightweight wrapper around the native iOS and Android SDKs, so its overhead is negligible compared to the native SDKs, making it not worth separate measurement. Below are the benchmark results for each respective platform. + +We measured the overhead using the [Pocket Casts iOS](https://github.com/Automattic/pocket-casts-ios) and [Pocket Casts Android](https://github.com/Automattic/pocket-casts-android) open-source apps respectively, which include a diverse set of components such as ViewControllers and SwiftUI screens. The benchmarks were conducted with full masking enabled, using optimized release builds, and running through the same user flow 10 times. This approach ensured the measurements closely reflect the overhead in a real-world application. Here are the results (median values are shown): + +## iOS + +| Metric | Sentry SDK only | Sentry + Replay SDK | +| -------------------------------- | --------------- | ------------------- | +| FPS | 55 fps | 53 fps | +| Memory | 102 MB | 121 MB | +| CPU | 4% | 13% | +| App Startup Time (Cold) | 1264.80 ms | 1265 ms | +| Main Thread Time | - | 43ms | +| Network Bandwidth | - | 50 KB | + + +The benchmarks were run on an iPhone 14 Pro. + +## Android + +| Metric | Sentry SDK only | Sentry + Replay SDK | +| -------------------------------- | --------------- | ------------------- | +| FPS | 55 fps | 54 fps | +| Memory | 255 MB | 265 MB | +| CPU | 36% | 42% | +| App Startup Time (Cold) | 1533.35 ms | 1539.55 ms | +| Main Thread Time | - | 20ms | +| Network Bandwidth | - | 35 KB | + + +The benchmarks were run on a Pixel 2XL with Android 11. diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx new file mode 100644 index 00000000000000..a5dc00b3e7c740 --- /dev/null +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -0,0 +1,57 @@ +--- +title: "Replay Performance Overhead" +sidebar_order: 30 +description: "Learn more about how enabling Session Replay impacts the performance of your application." +--- + +Session Replay for mobile works by taking snapshots of the view hierarchy as well as a screenshot within the same frame, at the rate of one per second. These screenshots are then compressed into a video file representing a segment of the user’s session. All these small segments are then streamed into Sentry with additional trace identifiers, breadcrumbs, and other useful debugging information to compose the full user session. + +In order to perform this work without negatively impacting the host application's performance, the mobile SDKs take care to introduce minimal additional CPU and memory overhead, record screenshots and view hierarchy in a non-intrusive way and only when necessary, send the absolute minimum number of bytes required, and use low-latency ingestion endpoints geographically close to your end-users. + +**For most mobile applications, the performance overhead of our mobile SDKs will be imperceptible to end-users.** + +## How Is Session Replay Optimized? + +Sentry's Session Replay SDK takes several measures to avoid negatively impacting the performance of the screen on which it's running: + +- The Session Replay SDK works by capturing screenshots, encoding them into small video segments and transmitting the content to Sentry’s servers. To reduce the amount of data transferred, multiple optimization strategies are employed: + - The SDK captures at most one screenshot per second at a 1:1 pixel density (commonly referred to as `@1x` on iOS and `mdpi` on Android). This significantly speeds up the screenshot screenshot capture process while maintaining acceptable quality. + - Screenshots are compressed into lossy `jpeg` files to reduce disk space usage and enable replay recovery in the event of a crash or an ANR. + - When sending a replay segment, the screenshots are further compressed into an `mp4` video file using `h.264` compression with a 75 kbps bitrate (the default behavior). This ensures a small payload size while preserving a perceivable replay quality. We observed nearly a 5x reduction in size when compressing five screenshots into a video segment. + - The video segment, alogn with other debugging information (such as breadcrumbs) is gzip-compressed on the client before transmission over HTTP. This compression is performed on a background thread, ensuring the application's main thread remains unaffected. + - To minimize disk space usage, screenshots and video segment files are deleted from the disk upon successful upload. +- Sentry’s event ingestion infrastructure uses [distributed Points-of-Presence (PoPs)](https://blog.sentry.io/2022/03/31/sentry-points-of-presence-how-we-built-a-distributed-ingestion/) which place ingestion servers around the world and close to your users. When a Session Replay event is transmitted, the user’s device connects and transmits the event payload to the closest PoP available for their region. This greatly reduces end-to-end latency and minimizes the amount of networking overhead placed on the browser. +- The SDK is built to gracefully downgrade when needed. In the event of sending too many replay events and hitting Sentry's rate limit, the SDK will disable recording to make sure the rate limit is respected. Once the rate limit is lifted, the SDK will continue recording. + +## Factors in Performance Overhead + +While the performance overhead of our mobile replay SDKs will be imperceptible to end-users most of the time, it can vary based on the complexity of your application. If an application has screens with a deeply-nested view tree, there will be higher overhead compared to simpler (e.g. Settings) screens. + +If masking is enabled (the default behavior), network overhead is further reduced because the screenshots have fewer pixels, resulting in smaller file sizes. + +There are different stages in the lifecycle of a mobile application, each with different performance characteristics. Here is a list of stages in the lifecycle, and the most important performance metrics to be aware of. + +### App Start + +There is virtually no overhead from the SDK during application startup. It performs only a few lightweight tasks, such as registering the necessary listeners for system events and scheduling a background thread for capturing. + +### Main Thread + +The SDK performs only the bare minimum on the main thread to capture a new frame for the replay (a screenshot and a view hierarchy snapshot) before immediately switching to a background thread for post-processing tasks. These tasks include masking screenshots, storing them in the disk cache, or encoding a video segment. This process occurs at most once per secondk, and it can be even less frequent depending on the frame rate setting. + +The SDK also monitors view tree changes, and if no changes have occurred since the last frame capture, it reuses the previously captured data, completely avoiding any work on the main thread. + +### Capturing touch events + +- Click/touch, swipe and scroll events are incredibly small and fast to log; overhead is negligible. +- We debounce touch events and use smoothing for move events to balance the detail you see while debugging, with the amount of redundant data captured. + +## Measuring Performance Overhead + +The only way to get accurate metrics is to measure performance overhead yourself. You can apply realistic access patterns against your own application, and correlate that to your own topline business metrics. + +We measured the overhead of the Replay SDK on various open-source apps that have millions of users in production (i.e. real-world apps that have a big set of different components and features), such as [Bluesky](https://github.com/bluesky-social/social-app) or [Pocket Casts](https://github.com/Automattic/pocket-casts-android). You can check the results on the respective SDK's docs: + +- [iOS](/platforms/apple/guides/ios/session-replay/) +- [Android](/platforms/android/session-replay/) +- [React Native](/platforms/react-native/session-replay/) From 735fcf7ec323cf3ad9e228956a2ff9c106b0c27a Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Thu, 28 Nov 2024 17:23:47 +0100 Subject: [PATCH 02/36] Fix links --- .../explore/session-replay/mobile/performance-overhead.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index a5dc00b3e7c740..d9c372c0d47177 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -52,6 +52,6 @@ The only way to get accurate metrics is to measure performance overhead yourself We measured the overhead of the Replay SDK on various open-source apps that have millions of users in production (i.e. real-world apps that have a big set of different components and features), such as [Bluesky](https://github.com/bluesky-social/social-app) or [Pocket Casts](https://github.com/Automattic/pocket-casts-android). You can check the results on the respective SDK's docs: -- [iOS](/platforms/apple/guides/ios/session-replay/) -- [Android](/platforms/android/session-replay/) -- [React Native](/platforms/react-native/session-replay/) +- [iOS](/platforms/apple/guides/ios/session-replay/performance-overhead/) +- [Android](/platforms/android/session-replay/performance-overhead/) +- [React Native](/platforms/react-native/session-replay/performance-overhead/) From 7c8c7e315e3c0eb5b1587f0198299f920e51073e Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 29 Nov 2024 09:00:04 +0100 Subject: [PATCH 03/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Jasmin <77064737+jas-kas@users.noreply.github.com> --- .../explore/session-replay/mobile/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index d9c372c0d47177..a3311b511e0cb7 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -15,7 +15,7 @@ In order to perform this work without negatively impacting the host application' Sentry's Session Replay SDK takes several measures to avoid negatively impacting the performance of the screen on which it's running: - The Session Replay SDK works by capturing screenshots, encoding them into small video segments and transmitting the content to Sentry’s servers. To reduce the amount of data transferred, multiple optimization strategies are employed: - - The SDK captures at most one screenshot per second at a 1:1 pixel density (commonly referred to as `@1x` on iOS and `mdpi` on Android). This significantly speeds up the screenshot screenshot capture process while maintaining acceptable quality. + - The SDK captures at most one screenshot per second at a 1:1 pixel density (commonly referred to as `@1x` on iOS and `mdpi` on Android). This significantly speeds up the screenshot capture process while maintaining acceptable quality. - Screenshots are compressed into lossy `jpeg` files to reduce disk space usage and enable replay recovery in the event of a crash or an ANR. - When sending a replay segment, the screenshots are further compressed into an `mp4` video file using `h.264` compression with a 75 kbps bitrate (the default behavior). This ensures a small payload size while preserving a perceivable replay quality. We observed nearly a 5x reduction in size when compressing five screenshots into a video segment. - The video segment, alogn with other debugging information (such as breadcrumbs) is gzip-compressed on the client before transmission over HTTP. This compression is performed on a background thread, ensuring the application's main thread remains unaffected. From 6252573e0712391c1ad280e9908b2f11885d2f65 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 29 Nov 2024 09:04:41 +0100 Subject: [PATCH 04/36] Update docs/platforms/react-native/session-replay/performance-overhead.mdx Co-authored-by: Jasmin <77064737+jas-kas@users.noreply.github.com> --- .../react-native/session-replay/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/platforms/react-native/session-replay/performance-overhead.mdx b/docs/platforms/react-native/session-replay/performance-overhead.mdx index fd60795ed57926..91be9a5b8ea6b8 100644 --- a/docs/platforms/react-native/session-replay/performance-overhead.mdx +++ b/docs/platforms/react-native/session-replay/performance-overhead.mdx @@ -7,7 +7,7 @@ description: "Learn more about how enabling Session Replay impacts the performan The only way to get accurate metrics is to measure performance overhead yourself. You can apply realistic access patterns against your own application, and correlate that to your own topline business metrics. You can learn more about the various optimizations implemented in the React Native Replay SDK in the [Replay Performance Overhead](/product/explore/session-replay/mobile/performance-overhead/) documentation. -The React Native Replay SDK is a lightweight wrapper around the native iOS and Android SDKs, so its overhead is negligible compared to the native SDKs, making it not worth separate measurement. Below are the benchmark results for each respective platform. +The React Native Replay SDK is a lightweight wrapper around the native iOS and Android SDKs, so its overhead is negligible compared to the native SDKs, making it not worth a separate measurement. Below are the benchmark results for each respective platform. We measured the overhead using the [Pocket Casts iOS](https://github.com/Automattic/pocket-casts-ios) and [Pocket Casts Android](https://github.com/Automattic/pocket-casts-android) open-source apps respectively, which include a diverse set of components such as ViewControllers and SwiftUI screens. The benchmarks were conducted with full masking enabled, using optimized release builds, and running through the same user flow 10 times. This approach ensured the measurements closely reflect the overhead in a real-world application. Here are the results (median values are shown): From 1d6646af96d8176134929dfe0d13e56dba50418a Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 29 Nov 2024 09:06:22 +0100 Subject: [PATCH 05/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Jasmin <77064737+jas-kas@users.noreply.github.com> --- .../explore/session-replay/mobile/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index a3311b511e0cb7..a580eb1306713d 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -18,7 +18,7 @@ Sentry's Session Replay SDK takes several measures to avoid negatively impacting - The SDK captures at most one screenshot per second at a 1:1 pixel density (commonly referred to as `@1x` on iOS and `mdpi` on Android). This significantly speeds up the screenshot capture process while maintaining acceptable quality. - Screenshots are compressed into lossy `jpeg` files to reduce disk space usage and enable replay recovery in the event of a crash or an ANR. - When sending a replay segment, the screenshots are further compressed into an `mp4` video file using `h.264` compression with a 75 kbps bitrate (the default behavior). This ensures a small payload size while preserving a perceivable replay quality. We observed nearly a 5x reduction in size when compressing five screenshots into a video segment. - - The video segment, alogn with other debugging information (such as breadcrumbs) is gzip-compressed on the client before transmission over HTTP. This compression is performed on a background thread, ensuring the application's main thread remains unaffected. + - The video segment, along with other debugging information (such as breadcrumbs), is gzip-compressed on the client before transmission over HTTP. This compression is performed on a background thread, ensuring the application's main thread remains unaffected. - To minimize disk space usage, screenshots and video segment files are deleted from the disk upon successful upload. - Sentry’s event ingestion infrastructure uses [distributed Points-of-Presence (PoPs)](https://blog.sentry.io/2022/03/31/sentry-points-of-presence-how-we-built-a-distributed-ingestion/) which place ingestion servers around the world and close to your users. When a Session Replay event is transmitted, the user’s device connects and transmits the event payload to the closest PoP available for their region. This greatly reduces end-to-end latency and minimizes the amount of networking overhead placed on the browser. - The SDK is built to gracefully downgrade when needed. In the event of sending too many replay events and hitting Sentry's rate limit, the SDK will disable recording to make sure the rate limit is respected. Once the rate limit is lifted, the SDK will continue recording. From 9b324fd3281847d683e4e4b419536776726a3487 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 29 Nov 2024 09:06:58 +0100 Subject: [PATCH 06/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Jasmin <77064737+jas-kas@users.noreply.github.com> --- .../explore/session-replay/mobile/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index a580eb1306713d..ee4610f0f0aeb8 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -17,7 +17,7 @@ Sentry's Session Replay SDK takes several measures to avoid negatively impacting - The Session Replay SDK works by capturing screenshots, encoding them into small video segments and transmitting the content to Sentry’s servers. To reduce the amount of data transferred, multiple optimization strategies are employed: - The SDK captures at most one screenshot per second at a 1:1 pixel density (commonly referred to as `@1x` on iOS and `mdpi` on Android). This significantly speeds up the screenshot capture process while maintaining acceptable quality. - Screenshots are compressed into lossy `jpeg` files to reduce disk space usage and enable replay recovery in the event of a crash or an ANR. - - When sending a replay segment, the screenshots are further compressed into an `mp4` video file using `h.264` compression with a 75 kbps bitrate (the default behavior). This ensures a small payload size while preserving a perceivable replay quality. We observed nearly a 5x reduction in size when compressing five screenshots into a video segment. + - When sending a replay segment, the screenshots are further compressed into an `mp4` video file using `h.264` compression with a 75 kbps bitrate (the default behavior). This ensures a small payload size while preserving the replay video quality. We observed nearly a 5x reduction in size when compressing five screenshots into a video segment. - The video segment, along with other debugging information (such as breadcrumbs), is gzip-compressed on the client before transmission over HTTP. This compression is performed on a background thread, ensuring the application's main thread remains unaffected. - To minimize disk space usage, screenshots and video segment files are deleted from the disk upon successful upload. - Sentry’s event ingestion infrastructure uses [distributed Points-of-Presence (PoPs)](https://blog.sentry.io/2022/03/31/sentry-points-of-presence-how-we-built-a-distributed-ingestion/) which place ingestion servers around the world and close to your users. When a Session Replay event is transmitted, the user’s device connects and transmits the event payload to the closest PoP available for their region. This greatly reduces end-to-end latency and minimizes the amount of networking overhead placed on the browser. From 5e34e6c89b4b599df32a1d90cf179fecf6ef4c40 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 29 Nov 2024 09:12:29 +0100 Subject: [PATCH 07/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Jasmin <77064737+jas-kas@users.noreply.github.com> --- .../explore/session-replay/mobile/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index ee4610f0f0aeb8..3e492fc9a350e3 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -25,7 +25,7 @@ Sentry's Session Replay SDK takes several measures to avoid negatively impacting ## Factors in Performance Overhead -While the performance overhead of our mobile replay SDKs will be imperceptible to end-users most of the time, it can vary based on the complexity of your application. If an application has screens with a deeply-nested view tree, there will be higher overhead compared to simpler (e.g. Settings) screens. +While the performance overhead of our mobile replay SDKs will be imperceptible to end-users most of the time, it can vary based on the complexity of your application. If an application has screens with a deeply-nested view tree, there will be higher overhead compared to simpler (e.g., Settings) screens. If masking is enabled (the default behavior), network overhead is further reduced because the screenshots have fewer pixels, resulting in smaller file sizes. From 5cde0bed62c3e84709e1797e9b87de24d1be8719 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 29 Nov 2024 09:12:45 +0100 Subject: [PATCH 08/36] Update docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx Co-authored-by: Jasmin <77064737+jas-kas@users.noreply.github.com> --- .../apple/guides/ios/session-replay/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx b/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx index aa4f902416e107..6e55e57add17f0 100644 --- a/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx +++ b/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx @@ -5,7 +5,7 @@ notSupported: description: "Learn more about how enabling Session Replay impacts the performance of your application." --- -The only way to get accurate metrics is to measure performance overhead yourself. You can apply realistic access patterns against your own application, and correlate that to your own topline business metrics. You can learn more about the various optimizations implemented in the iOS Replay SDK in the [Replay Performance Overhead](/product/explore/session-replay/mobile/performance-overhead/) documentation. +The only way to get accurate metrics is to measure performance overhead yourself. You can apply realistic access patterns against your own application, and correlate that to your own topline business metrics. You can learn more about the various performance overhead optimizations implemented in the iOS Replay SDK in the [Replay Performance Overhead](/product/explore/session-replay/mobile/performance-overhead/) documentation. We measured the overhead of the iOS Replay SDK using the [Pocket Casts](https://github.com/Automattic/pocket-casts-ios) open-source app, which includes a diverse set of components such as ViewControllers and SwiftUI screens. The benchmarks were conducted with full masking enabled, using optimized release builds, and running through the same user flow 10 times. This approach ensured the measurements closely reflect the overhead in a real-world application. Here are the results (median values are shown): From 272ba004e24108eaa70f55be1c3d3db6265c911c Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 29 Nov 2024 09:13:04 +0100 Subject: [PATCH 09/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Jasmin <77064737+jas-kas@users.noreply.github.com> --- .../explore/session-replay/mobile/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index 3e492fc9a350e3..0ba7767b9b0449 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -43,7 +43,7 @@ The SDK also monitors view tree changes, and if no changes have occurred since t ### Capturing touch events -- Click/touch, swipe and scroll events are incredibly small and fast to log; overhead is negligible. +- Click/touch, swipe, and scroll events are incredibly small and fast to log; overhead is negligible. - We debounce touch events and use smoothing for move events to balance the detail you see while debugging, with the amount of redundant data captured. ## Measuring Performance Overhead From ea752e541cbf42b295873fe7c24acf7780f3cbec Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 29 Nov 2024 09:13:18 +0100 Subject: [PATCH 10/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Jasmin <77064737+jas-kas@users.noreply.github.com> --- .../explore/session-replay/mobile/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index 0ba7767b9b0449..90c3f96b862f89 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -33,7 +33,7 @@ There are different stages in the lifecycle of a mobile application, each with d ### App Start -There is virtually no overhead from the SDK during application startup. It performs only a few lightweight tasks, such as registering the necessary listeners for system events and scheduling a background thread for capturing. +There is virtually no overhead from the SDK during application start up. It performs only a few lightweight tasks, such as registering the necessary listeners for system events and scheduling a background thread for capturing. ### Main Thread From 2e8acfb85f7a9d14f656c97b135db8d861325890 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 29 Nov 2024 09:14:26 +0100 Subject: [PATCH 11/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Jasmin <77064737+jas-kas@users.noreply.github.com> --- .../explore/session-replay/mobile/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index 90c3f96b862f89..cddb696764134e 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -37,7 +37,7 @@ There is virtually no overhead from the SDK during application start up. It perf ### Main Thread -The SDK performs only the bare minimum on the main thread to capture a new frame for the replay (a screenshot and a view hierarchy snapshot) before immediately switching to a background thread for post-processing tasks. These tasks include masking screenshots, storing them in the disk cache, or encoding a video segment. This process occurs at most once per secondk, and it can be even less frequent depending on the frame rate setting. +The SDK performs only the bare minimum on the main thread to capture a new frame for the replay (a screenshot and a view hierarchy snapshot) before immediately switching to a background thread for post-processing tasks. These tasks include masking screenshots, storing them in the disk cache, or encoding a video segment. This process occurs at most once per second, and it can be even less frequent depending on the frame rate setting. The SDK also monitors view tree changes, and if no changes have occurred since the last frame capture, it reuses the previously captured data, completely avoiding any work on the main thread. From ea4d452fa7b77e68a112e27cf61f3a7837860b7d Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 29 Nov 2024 09:14:46 +0100 Subject: [PATCH 12/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Jasmin <77064737+jas-kas@users.noreply.github.com> --- .../explore/session-replay/mobile/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index cddb696764134e..b30543ded22749 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -41,7 +41,7 @@ The SDK performs only the bare minimum on the main thread to capture a new frame The SDK also monitors view tree changes, and if no changes have occurred since the last frame capture, it reuses the previously captured data, completely avoiding any work on the main thread. -### Capturing touch events +### Capturing Touch Events - Click/touch, swipe, and scroll events are incredibly small and fast to log; overhead is negligible. - We debounce touch events and use smoothing for move events to balance the detail you see while debugging, with the amount of redundant data captured. From 5ba12f91e1a46438024d95634e089bc48e2cc1cc Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 29 Nov 2024 09:15:12 +0100 Subject: [PATCH 13/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Jasmin <77064737+jas-kas@users.noreply.github.com> --- .../explore/session-replay/mobile/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index b30543ded22749..3774ab0134902b 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -50,7 +50,7 @@ The SDK also monitors view tree changes, and if no changes have occurred since t The only way to get accurate metrics is to measure performance overhead yourself. You can apply realistic access patterns against your own application, and correlate that to your own topline business metrics. -We measured the overhead of the Replay SDK on various open-source apps that have millions of users in production (i.e. real-world apps that have a big set of different components and features), such as [Bluesky](https://github.com/bluesky-social/social-app) or [Pocket Casts](https://github.com/Automattic/pocket-casts-android). You can check the results on the respective SDK's docs: +We measured the overhead of the Replay SDK on various open-source apps that have millions of users in production (i.e., real-world apps that have a big set of different components and features), such as [Bluesky](https://github.com/bluesky-social/social-app) or [Pocket Casts](https://github.com/Automattic/pocket-casts-android). You can check the results on the respective SDK's docs: - [iOS](/platforms/apple/guides/ios/session-replay/performance-overhead/) - [Android](/platforms/android/session-replay/performance-overhead/) From 3ca4d9d5e7a9bf73e4ee7b9072b751a8c5be9fdc Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 29 Nov 2024 09:17:07 +0100 Subject: [PATCH 14/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx --- .../explore/session-replay/mobile/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index 3774ab0134902b..c38b0a175d3135 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -20,7 +20,7 @@ Sentry's Session Replay SDK takes several measures to avoid negatively impacting - When sending a replay segment, the screenshots are further compressed into an `mp4` video file using `h.264` compression with a 75 kbps bitrate (the default behavior). This ensures a small payload size while preserving the replay video quality. We observed nearly a 5x reduction in size when compressing five screenshots into a video segment. - The video segment, along with other debugging information (such as breadcrumbs), is gzip-compressed on the client before transmission over HTTP. This compression is performed on a background thread, ensuring the application's main thread remains unaffected. - To minimize disk space usage, screenshots and video segment files are deleted from the disk upon successful upload. -- Sentry’s event ingestion infrastructure uses [distributed Points-of-Presence (PoPs)](https://blog.sentry.io/2022/03/31/sentry-points-of-presence-how-we-built-a-distributed-ingestion/) which place ingestion servers around the world and close to your users. When a Session Replay event is transmitted, the user’s device connects and transmits the event payload to the closest PoP available for their region. This greatly reduces end-to-end latency and minimizes the amount of networking overhead placed on the browser. +- Sentry’s event ingestion infrastructure uses [distributed Points-of-Presence (PoPs)](https://blog.sentry.io/2022/03/31/sentry-points-of-presence-how-we-built-a-distributed-ingestion/) which place ingestion servers around the world and close to your users. When a Session Replay event is transmitted, the user’s device connects and transmits the event payload to the closest PoP available for their region. This greatly reduces end-to-end latency and minimizes the amount of networking overhead placed on the device. - The SDK is built to gracefully downgrade when needed. In the event of sending too many replay events and hitting Sentry's rate limit, the SDK will disable recording to make sure the rate limit is respected. Once the rate limit is lifted, the SDK will continue recording. ## Factors in Performance Overhead From e676a5f919739185eaff1a538f81f851ed98c567 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 29 Nov 2024 12:30:37 +0100 Subject: [PATCH 15/36] Address PR feedback --- .../session-replay/mobile/performance-overhead.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index c38b0a175d3135..ac5751cb3ec9de 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -6,9 +6,9 @@ description: "Learn more about how enabling Session Replay impacts the performan Session Replay for mobile works by taking snapshots of the view hierarchy as well as a screenshot within the same frame, at the rate of one per second. These screenshots are then compressed into a video file representing a segment of the user’s session. All these small segments are then streamed into Sentry with additional trace identifiers, breadcrumbs, and other useful debugging information to compose the full user session. -In order to perform this work without negatively impacting the host application's performance, the mobile SDKs take care to introduce minimal additional CPU and memory overhead, record screenshots and view hierarchy in a non-intrusive way and only when necessary, send the absolute minimum number of bytes required, and use low-latency ingestion endpoints geographically close to your end-users. +In order to perform this work without negatively impacting the host application's performance, Sentry employs a number of measures to minimize additional CPU and memory overhead, record screenshots and view hierarchy in a non-intrusive way and only when necessary, send the absolute minimum number of bytes required, and use low-latency ingestion endpoints geographically close to your end-users. -**For most mobile applications, the performance overhead of our mobile SDKs will be imperceptible to end-users.** +**For most mobile applications, the performance overhead of our Session Replay SDK will be imperceptible to end-users.** ## How Is Session Replay Optimized? @@ -16,7 +16,7 @@ Sentry's Session Replay SDK takes several measures to avoid negatively impacting - The Session Replay SDK works by capturing screenshots, encoding them into small video segments and transmitting the content to Sentry’s servers. To reduce the amount of data transferred, multiple optimization strategies are employed: - The SDK captures at most one screenshot per second at a 1:1 pixel density (commonly referred to as `@1x` on iOS and `mdpi` on Android). This significantly speeds up the screenshot capture process while maintaining acceptable quality. - - Screenshots are compressed into lossy `jpeg` files to reduce disk space usage and enable replay recovery in the event of a crash or an ANR. + - Screenshots are compressed into lossy `jpeg` files to reduce disk space usage and enable recovering of the last frames of a replay in the event of a crash or an ANR. - When sending a replay segment, the screenshots are further compressed into an `mp4` video file using `h.264` compression with a 75 kbps bitrate (the default behavior). This ensures a small payload size while preserving the replay video quality. We observed nearly a 5x reduction in size when compressing five screenshots into a video segment. - The video segment, along with other debugging information (such as breadcrumbs), is gzip-compressed on the client before transmission over HTTP. This compression is performed on a background thread, ensuring the application's main thread remains unaffected. - To minimize disk space usage, screenshots and video segment files are deleted from the disk upon successful upload. @@ -25,7 +25,7 @@ Sentry's Session Replay SDK takes several measures to avoid negatively impacting ## Factors in Performance Overhead -While the performance overhead of our mobile replay SDKs will be imperceptible to end-users most of the time, it can vary based on the complexity of your application. If an application has screens with a deeply-nested view tree, there will be higher overhead compared to simpler (e.g., Settings) screens. +While the performance overhead of our Session Replay SDK will be imperceptible to end-users most of the time, it can vary based on the complexity of your application. If an application has screens with a deeply-nested view tree, there will be higher overhead compared to simpler (e.g., Settings) screens. If masking is enabled (the default behavior), network overhead is further reduced because the screenshots have fewer pixels, resulting in smaller file sizes. From 337e600226ba082bf7f48a15ec2cd8bbbaa53c3f Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Fri, 29 Nov 2024 12:32:31 +0100 Subject: [PATCH 16/36] Address PR feedback --- .../android/session-replay/performance-overhead.mdx | 4 ++-- .../guides/ios/session-replay/performance-overhead.mdx | 4 ++-- .../react-native/session-replay/performance-overhead.mdx | 8 ++++---- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/platforms/android/session-replay/performance-overhead.mdx b/docs/platforms/android/session-replay/performance-overhead.mdx index 206836518c8b4c..b0c261bf7fa7f6 100644 --- a/docs/platforms/android/session-replay/performance-overhead.mdx +++ b/docs/platforms/android/session-replay/performance-overhead.mdx @@ -15,8 +15,8 @@ We measured the overhead of the Android Replay SDK using the [Pocket Casts](http | Memory | 255 MB | 265 MB | | CPU | 36% | 42% | | App Startup Time (Cold) | 1533.35 ms | 1539.55 ms | -| Main Thread Time | - | 20ms | -| Network Bandwidth | - | 35 KB | +| Main Thread Time | n/a | 20ms | +| Network Bandwidth | n/a | 35 KB | The benchmarks were run on a Pixel 2XL with Android 11. diff --git a/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx b/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx index 6e55e57add17f0..838b48ea8cf2c0 100644 --- a/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx +++ b/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx @@ -15,8 +15,8 @@ We measured the overhead of the iOS Replay SDK using the [Pocket Casts](https:// | Memory | 102 MB | 121 MB | | CPU | 4% | 13% | | App Startup Time (Cold) | 1264.80 ms | 1265 ms | -| Main Thread Time | - | 43ms | -| Network Bandwidth | - | 50 KB | +| Main Thread Time | n/a | 43ms | +| Network Bandwidth | n/a | 50 KB | The benchmarks were run on an iPhone 14 Pro. diff --git a/docs/platforms/react-native/session-replay/performance-overhead.mdx b/docs/platforms/react-native/session-replay/performance-overhead.mdx index 91be9a5b8ea6b8..f66dec728ed0dd 100644 --- a/docs/platforms/react-native/session-replay/performance-overhead.mdx +++ b/docs/platforms/react-native/session-replay/performance-overhead.mdx @@ -19,8 +19,8 @@ We measured the overhead using the [Pocket Casts iOS](https://github.com/Automat | Memory | 102 MB | 121 MB | | CPU | 4% | 13% | | App Startup Time (Cold) | 1264.80 ms | 1265 ms | -| Main Thread Time | - | 43ms | -| Network Bandwidth | - | 50 KB | +| Main Thread Time | n/a | 43ms | +| Network Bandwidth | n/a | 50 KB | The benchmarks were run on an iPhone 14 Pro. @@ -33,8 +33,8 @@ The benchmarks were run on an iPhone 14 Pro. | Memory | 255 MB | 265 MB | | CPU | 36% | 42% | | App Startup Time (Cold) | 1533.35 ms | 1539.55 ms | -| Main Thread Time | - | 20ms | -| Network Bandwidth | - | 35 KB | +| Main Thread Time | n/a | 20ms | +| Network Bandwidth | n/a | 35 KB | The benchmarks were run on a Pixel 2XL with Android 11. From 17f19eaf17107ee8114f5f85fa810d9756b0cf9c Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 13:50:30 +0100 Subject: [PATCH 17/36] Update docs/platforms/android/session-replay/performance-overhead.mdx Co-authored-by: Liza Mock --- docs/platforms/android/session-replay/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/platforms/android/session-replay/performance-overhead.mdx b/docs/platforms/android/session-replay/performance-overhead.mdx index b0c261bf7fa7f6..cda5b9156c1f83 100644 --- a/docs/platforms/android/session-replay/performance-overhead.mdx +++ b/docs/platforms/android/session-replay/performance-overhead.mdx @@ -2,7 +2,7 @@ title: Performance Overhead sidebar_order: 5502 notSupported: -description: "Learn more about how enabling Session Replay impacts the performance of your application." +description: "Learn about how enabling Session Replay impacts the performance of your application." --- The only way to get accurate metrics is to measure performance overhead yourself. You can apply realistic access patterns against your own application, and correlate that to your own topline business metrics. You can learn more about the various optimizations implemented in the Android Replay SDK in the [Replay Performance Overhead](/product/explore/session-replay/mobile/performance-overhead/) documentation. From 9b9453c95096e9f4efecd89ba4029edcbba96d45 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 13:51:47 +0100 Subject: [PATCH 18/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Liza Mock --- .../explore/session-replay/mobile/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index ac5751cb3ec9de..e90c0199af9fa1 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -1,7 +1,7 @@ --- title: "Replay Performance Overhead" sidebar_order: 30 -description: "Learn more about how enabling Session Replay impacts the performance of your application." +description: "Learn about how enabling Session Replay impacts the performance of your application." --- Session Replay for mobile works by taking snapshots of the view hierarchy as well as a screenshot within the same frame, at the rate of one per second. These screenshots are then compressed into a video file representing a segment of the user’s session. All these small segments are then streamed into Sentry with additional trace identifiers, breadcrumbs, and other useful debugging information to compose the full user session. From f0de54d5d22c7c20fd39ea63bb9f906a07bb8f9c Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 14:47:47 +0100 Subject: [PATCH 19/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Liza Mock --- .../explore/session-replay/mobile/performance-overhead.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index e90c0199af9fa1..e138207acf2b4d 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -4,9 +4,9 @@ sidebar_order: 30 description: "Learn about how enabling Session Replay impacts the performance of your application." --- -Session Replay for mobile works by taking snapshots of the view hierarchy as well as a screenshot within the same frame, at the rate of one per second. These screenshots are then compressed into a video file representing a segment of the user’s session. All these small segments are then streamed into Sentry with additional trace identifiers, breadcrumbs, and other useful debugging information to compose the full user session. +Session Replay for mobile captures snapshots of the view hierarchy as well as a screenshot within the same frame once per second. These are compressed into a video file representing parts of the user’s session, then streamed to Sentry with trace identifiers, breadcrumbs, and other debugging information to reconstruct the full session. -In order to perform this work without negatively impacting the host application's performance, Sentry employs a number of measures to minimize additional CPU and memory overhead, record screenshots and view hierarchy in a non-intrusive way and only when necessary, send the absolute minimum number of bytes required, and use low-latency ingestion endpoints geographically close to your end-users. +To avoid impacting the host's app performance, Sentry minimizes CPU and memory usage by recording screenshots and view hierarchy non-intrusively and only when necessary, sending only essential bytes, and using low-latency ingestion endpoints geographically close to your end-users. **For most mobile applications, the performance overhead of our Session Replay SDK will be imperceptible to end-users.** From e8fc586574342d723ec646a7ede34c80b533701e Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 14:48:31 +0100 Subject: [PATCH 20/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Liza Mock --- .../explore/session-replay/mobile/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index e138207acf2b4d..7d6be777f905de 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -12,7 +12,7 @@ To avoid impacting the host's app performance, Sentry minimizes CPU and memory u ## How Is Session Replay Optimized? -Sentry's Session Replay SDK takes several measures to avoid negatively impacting the performance of the screen on which it's running: +Sentry's Session Replay SDK takes several measures to avoid negatively impacting the performance of the screen on which it's running. - The Session Replay SDK works by capturing screenshots, encoding them into small video segments and transmitting the content to Sentry’s servers. To reduce the amount of data transferred, multiple optimization strategies are employed: - The SDK captures at most one screenshot per second at a 1:1 pixel density (commonly referred to as `@1x` on iOS and `mdpi` on Android). This significantly speeds up the screenshot capture process while maintaining acceptable quality. From 2b8441b1468143038d13d69b645928c0cc314420 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 14:48:50 +0100 Subject: [PATCH 21/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Liza Mock --- .../explore/session-replay/mobile/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index 7d6be777f905de..61aee6da71cf60 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -17,7 +17,7 @@ Sentry's Session Replay SDK takes several measures to avoid negatively impacting - The Session Replay SDK works by capturing screenshots, encoding them into small video segments and transmitting the content to Sentry’s servers. To reduce the amount of data transferred, multiple optimization strategies are employed: - The SDK captures at most one screenshot per second at a 1:1 pixel density (commonly referred to as `@1x` on iOS and `mdpi` on Android). This significantly speeds up the screenshot capture process while maintaining acceptable quality. - Screenshots are compressed into lossy `jpeg` files to reduce disk space usage and enable recovering of the last frames of a replay in the event of a crash or an ANR. - - When sending a replay segment, the screenshots are further compressed into an `mp4` video file using `h.264` compression with a 75 kbps bitrate (the default behavior). This ensures a small payload size while preserving the replay video quality. We observed nearly a 5x reduction in size when compressing five screenshots into a video segment. + - When sending a replay segment, the screenshots are further compressed into an `mp4` video file using `h.264` compression with a 75 kbps bitrate (the default behavior). This ensures a small payload size while preserving video quality. We observed nearly 5x reduction in size when compressing five screenshots into a video segment. - The video segment, along with other debugging information (such as breadcrumbs), is gzip-compressed on the client before transmission over HTTP. This compression is performed on a background thread, ensuring the application's main thread remains unaffected. - To minimize disk space usage, screenshots and video segment files are deleted from the disk upon successful upload. - Sentry’s event ingestion infrastructure uses [distributed Points-of-Presence (PoPs)](https://blog.sentry.io/2022/03/31/sentry-points-of-presence-how-we-built-a-distributed-ingestion/) which place ingestion servers around the world and close to your users. When a Session Replay event is transmitted, the user’s device connects and transmits the event payload to the closest PoP available for their region. This greatly reduces end-to-end latency and minimizes the amount of networking overhead placed on the device. From 01be4741a162b67e16bf3b5f2b21d035752641b8 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 15:26:51 +0100 Subject: [PATCH 22/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Liza Mock --- .../explore/session-replay/mobile/performance-overhead.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index 61aee6da71cf60..41a42d9ee1abbd 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -25,11 +25,11 @@ Sentry's Session Replay SDK takes several measures to avoid negatively impacting ## Factors in Performance Overhead -While the performance overhead of our Session Replay SDK will be imperceptible to end-users most of the time, it can vary based on the complexity of your application. If an application has screens with a deeply-nested view tree, there will be higher overhead compared to simpler (e.g., Settings) screens. +While the performance overhead of our Session Replay SDK will be imperceptible to end-users most of the time, it can vary based on the complexity of your application. If an application has screens with a deeply-nested view tree, there will be higher overhead compared to simpler screens (for example, Settings). -If masking is enabled (the default behavior), network overhead is further reduced because the screenshots have fewer pixels, resulting in smaller file sizes. +If the default masking behavior is enabled, network overhead will be further reduced because the screenshots have fewer pixels, resulting in smaller file sizes. -There are different stages in the lifecycle of a mobile application, each with different performance characteristics. Here is a list of stages in the lifecycle, and the most important performance metrics to be aware of. +There are different stages in the lifecycle of a mobile application. Each has different performance characteristics. Below is a list of lifecycle stages and the most important performance metrics you should be aware of. ### App Start From c634e6e87918916bbed4f48922d8733e69fd6380 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 15:27:09 +0100 Subject: [PATCH 23/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Liza Mock --- .../explore/session-replay/mobile/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index 41a42d9ee1abbd..dfd41f7a449700 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -39,7 +39,7 @@ There is virtually no overhead from the SDK during application start up. It perf The SDK performs only the bare minimum on the main thread to capture a new frame for the replay (a screenshot and a view hierarchy snapshot) before immediately switching to a background thread for post-processing tasks. These tasks include masking screenshots, storing them in the disk cache, or encoding a video segment. This process occurs at most once per second, and it can be even less frequent depending on the frame rate setting. -The SDK also monitors view tree changes, and if no changes have occurred since the last frame capture, it reuses the previously captured data, completely avoiding any work on the main thread. +The SDK also monitors view tree changes. If no changes have occurred since the last frame capture, it reuses the previously captured data, completely avoiding any work on the main thread. ### Capturing Touch Events From f96d1ab5249f3eab6c6bb115692d90536a27515c Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 15:27:37 +0100 Subject: [PATCH 24/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Liza Mock --- .../explore/session-replay/mobile/performance-overhead.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index dfd41f7a449700..e5a19e5969d4ae 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -43,8 +43,8 @@ The SDK also monitors view tree changes. If no changes have occurred since the l ### Capturing Touch Events -- Click/touch, swipe, and scroll events are incredibly small and fast to log; overhead is negligible. -- We debounce touch events and use smoothing for move events to balance the detail you see while debugging, with the amount of redundant data captured. +- Click/touch, swipe, and scroll events are incredibly small and fast to log, making the overhead negligible. +- We optimize touch event recording by debouncing (limiting the frequency of events) and smoothing move events. This ensures a clear, detailed debugging experience without capturing excessive or redundant data. ## Measuring Performance Overhead From a0ec705c29c616ef95c9ed5ac1a3655ab3b5a68f Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 15:28:42 +0100 Subject: [PATCH 25/36] Update docs/product/explore/session-replay/mobile/performance-overhead.mdx Co-authored-by: Liza Mock --- .../explore/session-replay/mobile/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/product/explore/session-replay/mobile/performance-overhead.mdx b/docs/product/explore/session-replay/mobile/performance-overhead.mdx index e5a19e5969d4ae..7b7d6eefc90967 100644 --- a/docs/product/explore/session-replay/mobile/performance-overhead.mdx +++ b/docs/product/explore/session-replay/mobile/performance-overhead.mdx @@ -50,7 +50,7 @@ The SDK also monitors view tree changes. If no changes have occurred since the l The only way to get accurate metrics is to measure performance overhead yourself. You can apply realistic access patterns against your own application, and correlate that to your own topline business metrics. -We measured the overhead of the Replay SDK on various open-source apps that have millions of users in production (i.e., real-world apps that have a big set of different components and features), such as [Bluesky](https://github.com/bluesky-social/social-app) or [Pocket Casts](https://github.com/Automattic/pocket-casts-android). You can check the results on the respective SDK's docs: +We measured the overhead of the Replay SDK on various open-source apps that have millions of users in production. For example, real-world apps that have a large set of different components and features such as [Bluesky](https://github.com/bluesky-social/social-app) and [Pocket Casts](https://github.com/Automattic/pocket-casts-android). You can check the results by going to the SDK docs below: - [iOS](/platforms/apple/guides/ios/session-replay/performance-overhead/) - [Android](/platforms/android/session-replay/performance-overhead/) From b24170cc6a30b06df3a9b7e688d4b43465306840 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 15:28:58 +0100 Subject: [PATCH 26/36] Update docs/platforms/react-native/session-replay/performance-overhead.mdx Co-authored-by: Liza Mock --- .../react-native/session-replay/performance-overhead.mdx | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/platforms/react-native/session-replay/performance-overhead.mdx b/docs/platforms/react-native/session-replay/performance-overhead.mdx index f66dec728ed0dd..9e1b95d63d7e67 100644 --- a/docs/platforms/react-native/session-replay/performance-overhead.mdx +++ b/docs/platforms/react-native/session-replay/performance-overhead.mdx @@ -23,7 +23,6 @@ We measured the overhead using the [Pocket Casts iOS](https://github.com/Automat | Network Bandwidth | n/a | 50 KB | -The benchmarks were run on an iPhone 14 Pro. ## Android From c6e8e3e84fe2cccdc4427cf5363c91a6f76d0af2 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 15:29:06 +0100 Subject: [PATCH 27/36] Update docs/platforms/react-native/session-replay/performance-overhead.mdx Co-authored-by: Liza Mock --- .../react-native/session-replay/performance-overhead.mdx | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/platforms/react-native/session-replay/performance-overhead.mdx b/docs/platforms/react-native/session-replay/performance-overhead.mdx index 9e1b95d63d7e67..bdbf56e59d94c3 100644 --- a/docs/platforms/react-native/session-replay/performance-overhead.mdx +++ b/docs/platforms/react-native/session-replay/performance-overhead.mdx @@ -36,4 +36,3 @@ We measured the overhead using the [Pocket Casts iOS](https://github.com/Automat | Network Bandwidth | n/a | 35 KB | -The benchmarks were run on a Pixel 2XL with Android 11. From 06dfb69a9ada37f465eeb5014bdc9bf2fd463cab Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 15:29:18 +0100 Subject: [PATCH 28/36] Update docs/platforms/react-native/session-replay/performance-overhead.mdx Co-authored-by: Liza Mock --- .../react-native/session-replay/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/platforms/react-native/session-replay/performance-overhead.mdx b/docs/platforms/react-native/session-replay/performance-overhead.mdx index bdbf56e59d94c3..e7951c9fa50342 100644 --- a/docs/platforms/react-native/session-replay/performance-overhead.mdx +++ b/docs/platforms/react-native/session-replay/performance-overhead.mdx @@ -2,7 +2,7 @@ title: Performance Overhead sidebar_order: 5502 notSupported: -description: "Learn more about how enabling Session Replay impacts the performance of your application." +description: "Learn about how enabling Session Replay impacts the performance of your application." --- The only way to get accurate metrics is to measure performance overhead yourself. You can apply realistic access patterns against your own application, and correlate that to your own topline business metrics. You can learn more about the various optimizations implemented in the React Native Replay SDK in the [Replay Performance Overhead](/product/explore/session-replay/mobile/performance-overhead/) documentation. From 3360c7d70e194ab7446d52b51c06507d3b028e54 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 15:43:32 +0100 Subject: [PATCH 29/36] Update docs/platforms/react-native/session-replay/performance-overhead.mdx Co-authored-by: Liza Mock --- .../session-replay/performance-overhead.mdx | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/docs/platforms/react-native/session-replay/performance-overhead.mdx b/docs/platforms/react-native/session-replay/performance-overhead.mdx index e7951c9fa50342..613dd7c0ec787c 100644 --- a/docs/platforms/react-native/session-replay/performance-overhead.mdx +++ b/docs/platforms/react-native/session-replay/performance-overhead.mdx @@ -5,11 +5,21 @@ notSupported: description: "Learn about how enabling Session Replay impacts the performance of your application." --- -The only way to get accurate metrics is to measure performance overhead yourself. You can apply realistic access patterns against your own application, and correlate that to your own topline business metrics. You can learn more about the various optimizations implemented in the React Native Replay SDK in the [Replay Performance Overhead](/product/explore/session-replay/mobile/performance-overhead/) documentation. +If you're considering enabling Session Replay, it's important to first understand the potential performance impact to your app. While accurate metrics require realistic testing where you apply typical access patterns and correlate the results with your business metrics, to provide a baseline, we measured the overhead using the open-source [Pocket Casts](https://github.com/Automattic/pocket-casts-android) app. -The React Native Replay SDK is a lightweight wrapper around the native iOS and Android SDKs, so its overhead is negligible compared to the native SDKs, making it not worth a separate measurement. Below are the benchmark results for each respective platform. +You can learn more about the various optimizations implemented in the React Native Replay SDK in the [Replay Performance Overhead](/product/explore/session-replay/mobile/performance-overhead/) docs. -We measured the overhead using the [Pocket Casts iOS](https://github.com/Automattic/pocket-casts-ios) and [Pocket Casts Android](https://github.com/Automattic/pocket-casts-android) open-source apps respectively, which include a diverse set of components such as ViewControllers and SwiftUI screens. The benchmarks were conducted with full masking enabled, using optimized release builds, and running through the same user flow 10 times. This approach ensured the measurements closely reflect the overhead in a real-world application. Here are the results (median values are shown): +The React Native Replay SDK is a lightweight wrapper for the native iOS and Android SDKs, so its overhead is minimal and doesn't require separate measurement. Below are the benchmark results for each platform. + +We measured the overhead using the [Pocket Casts iOS](https://github.com/Automattic/pocket-casts-ios) and [Pocket Casts Android](https://github.com/Automattic/pocket-casts-android) open-source apps. Each includes a diverse set of components such as ViewControllers and SwiftUI screens. + +Here's how the benchmarks were conducted: + +- **Configuration:** Full masking was enabled, and optimized release builds were used. +- **User Flow:** The same flow was executed 10 times to ensure consistency. +- **Real-World Representation:** This approach closely mirrors performance in real-world scenarios. + +The benchmarks were run on an iPhone 14 Pro and a Pixel 2XL. ## iOS From 19be384a1e92dc2ae44e895bff8557701a1d29eb Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 15:43:45 +0100 Subject: [PATCH 30/36] Update docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx Co-authored-by: Liza Mock --- .../apple/guides/ios/session-replay/performance-overhead.mdx | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx b/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx index 838b48ea8cf2c0..4f55d916b68091 100644 --- a/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx +++ b/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx @@ -19,4 +19,3 @@ We measured the overhead of the iOS Replay SDK using the [Pocket Casts](https:// | Network Bandwidth | n/a | 50 KB | -The benchmarks were run on an iPhone 14 Pro. From 800e00d1302025de35a6aa0543fcc877ca859c56 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 15:44:46 +0100 Subject: [PATCH 31/36] Update docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx Co-authored-by: Liza Mock --- .../ios/session-replay/performance-overhead.mdx | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx b/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx index 4f55d916b68091..433845c66dee61 100644 --- a/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx +++ b/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx @@ -5,9 +5,22 @@ notSupported: description: "Learn more about how enabling Session Replay impacts the performance of your application." --- -The only way to get accurate metrics is to measure performance overhead yourself. You can apply realistic access patterns against your own application, and correlate that to your own topline business metrics. You can learn more about the various performance overhead optimizations implemented in the iOS Replay SDK in the [Replay Performance Overhead](/product/explore/session-replay/mobile/performance-overhead/) documentation. +If you're considering enabling Session Replay, it's important to first understand the potential performance impact to your app. While accurate metrics require realistic testing where you apply typical access patterns and correlate the results with your business metrics, to provide a baseline, we measured the overhead using the open-source [Pocket Casts](https://github.com/Automattic/pocket-casts-ios) app. + +You can learn more about the various performance overhead optimizations implemented in the iOS Replay SDK in the [Replay Performance Overhead](/product/explore/session-replay/mobile/performance-overhead/) docs. + +## Benchmarking the iOS Replay SDK + +The Pocket Casts app offers a diverse mix of components, including Fragments, Activities, and Jetpack Compose screens, making it an ideal candidate for testing. Here's how the benchmarks were conducted: +- **Configuration:** Full masking was enabled, and optimized release builds were used. +- **User Flow:** The same flow was executed 10 times to ensure consistency. +- **Real-World Representation:** This approach closely mirrors performance in real-world scenarios. + +The benchmarks were run on an iPhone 14 Pro. + +### Results +Below are the results of the benchmarking tests, presented as median values to reflect typical overhead. -We measured the overhead of the iOS Replay SDK using the [Pocket Casts](https://github.com/Automattic/pocket-casts-ios) open-source app, which includes a diverse set of components such as ViewControllers and SwiftUI screens. The benchmarks were conducted with full masking enabled, using optimized release builds, and running through the same user flow 10 times. This approach ensured the measurements closely reflect the overhead in a real-world application. Here are the results (median values are shown): | Metric | Sentry SDK only | Sentry + Replay SDK | | -------------------------------- | --------------- | ------------------- | From c6d52100e90921474b0745b199d37c6b05df1326 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 15:51:44 +0100 Subject: [PATCH 32/36] Update docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx Co-authored-by: Liza Mock --- .../apple/guides/ios/session-replay/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx b/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx index 433845c66dee61..44f383d27188b4 100644 --- a/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx +++ b/docs/platforms/apple/guides/ios/session-replay/performance-overhead.mdx @@ -2,7 +2,7 @@ title: Performance Overhead sidebar_order: 5502 notSupported: -description: "Learn more about how enabling Session Replay impacts the performance of your application." +description: "Learn about how enabling Session Replay impacts the performance of your application." --- If you're considering enabling Session Replay, it's important to first understand the potential performance impact to your app. While accurate metrics require realistic testing where you apply typical access patterns and correlate the results with your business metrics, to provide a baseline, we measured the overhead using the open-source [Pocket Casts](https://github.com/Automattic/pocket-casts-ios) app. From b7eab55375f6dacb41a9df4ec41d8693f73f395e Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 15:52:03 +0100 Subject: [PATCH 33/36] Update docs/platforms/android/session-replay/performance-overhead.mdx Co-authored-by: Liza Mock --- docs/platforms/android/session-replay/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/platforms/android/session-replay/performance-overhead.mdx b/docs/platforms/android/session-replay/performance-overhead.mdx index cda5b9156c1f83..f958d1be5fde5b 100644 --- a/docs/platforms/android/session-replay/performance-overhead.mdx +++ b/docs/platforms/android/session-replay/performance-overhead.mdx @@ -23,6 +23,6 @@ The benchmarks were run on a Pixel 2XL with Android 11. -Jetpack Compose view hierarchies may be slower to snapshot initially due to ART optimizations compared to the traditional Android View System, but their performance improves as execution progresses. +Jetpack Compose view hierarchies may be slower to snapshot initially due to ART optimizations, compared to the traditional Android View System. But their performance improves as execution progresses. From e11cb9c0626c6842c6b0997ca59c9b3a790da9b9 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 15:52:11 +0100 Subject: [PATCH 34/36] Update docs/platforms/android/session-replay/performance-overhead.mdx Co-authored-by: Liza Mock --- docs/platforms/android/session-replay/performance-overhead.mdx | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/platforms/android/session-replay/performance-overhead.mdx b/docs/platforms/android/session-replay/performance-overhead.mdx index f958d1be5fde5b..066ebe8aba8df9 100644 --- a/docs/platforms/android/session-replay/performance-overhead.mdx +++ b/docs/platforms/android/session-replay/performance-overhead.mdx @@ -19,7 +19,6 @@ We measured the overhead of the Android Replay SDK using the [Pocket Casts](http | Network Bandwidth | n/a | 35 KB | -The benchmarks were run on a Pixel 2XL with Android 11. From 77d80e62b8df4b8d875b0270b10626f2aca2d265 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 15:52:22 +0100 Subject: [PATCH 35/36] Update docs/platforms/android/session-replay/performance-overhead.mdx Co-authored-by: Liza Mock --- .../session-replay/performance-overhead.mdx | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/docs/platforms/android/session-replay/performance-overhead.mdx b/docs/platforms/android/session-replay/performance-overhead.mdx index 066ebe8aba8df9..b5af4e51996bcf 100644 --- a/docs/platforms/android/session-replay/performance-overhead.mdx +++ b/docs/platforms/android/session-replay/performance-overhead.mdx @@ -5,9 +5,22 @@ notSupported: description: "Learn about how enabling Session Replay impacts the performance of your application." --- -The only way to get accurate metrics is to measure performance overhead yourself. You can apply realistic access patterns against your own application, and correlate that to your own topline business metrics. You can learn more about the various optimizations implemented in the Android Replay SDK in the [Replay Performance Overhead](/product/explore/session-replay/mobile/performance-overhead/) documentation. +If you're considering enabling Session Replay, it's important to first understand the potential performance impact to your app. While accurate metrics require realistic testing where you apply typical access patterns and correlate the results with your business metrics, to provide a baseline, we measured the overhead using the open-source [Pocket Casts](https://github.com/Automattic/pocket-casts-android) app. -We measured the overhead of the Android Replay SDK using the [Pocket Casts](https://github.com/Automattic/pocket-casts-android) open-source app, which includes a diverse set of components such as Fragments, Activities, and Jetpack Compose screens. The benchmarks were conducted with full masking enabled, using optimized release builds, and running through the same user flow 10 times. This approach ensured the measurements closely reflect the overhead in a real-world application. Here are the results (median values are shown): +You can learn more about the various optimizations implemented in the Android Replay SDK in the [Replay Performance Overhead](/product/explore/session-replay/mobile/performance-overhead/) docs. + +## Benchmarking the Android Replay SDK + +The Pocket Casts app offers a diverse mix of components, including Fragments, Activities, and Jetpack Compose screens, making it an ideal candidate for testing. Here's how the benchmarks were conducted: + +- **Configuration:** Full masking was enabled, and optimized release builds were used. +- **User Flow:** The same flow was executed 10 times to ensure consistency. +- **Real-World Representation:** This approach closely mirrors performance in real-world scenarios. + +The benchmarks were run on a Pixel 2XL with Android 11. + +### Results +Below are the results of the benchmarking tests, presented as median values to reflect typical overhead. | Metric | Sentry SDK only | Sentry + Replay SDK | | -------------------------------- | --------------- | ------------------- | From 47fe5fd3fd7e21408d84bc2dd4e68dda02e91e08 Mon Sep 17 00:00:00 2001 From: Roman Zavarnitsyn Date: Wed, 4 Dec 2024 15:53:01 +0100 Subject: [PATCH 36/36] Update docs/platforms/react-native/session-replay/performance-overhead.mdx --- .../react-native/session-replay/performance-overhead.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/platforms/react-native/session-replay/performance-overhead.mdx b/docs/platforms/react-native/session-replay/performance-overhead.mdx index 613dd7c0ec787c..c3971e81e897c2 100644 --- a/docs/platforms/react-native/session-replay/performance-overhead.mdx +++ b/docs/platforms/react-native/session-replay/performance-overhead.mdx @@ -5,7 +5,7 @@ notSupported: description: "Learn about how enabling Session Replay impacts the performance of your application." --- -If you're considering enabling Session Replay, it's important to first understand the potential performance impact to your app. While accurate metrics require realistic testing where you apply typical access patterns and correlate the results with your business metrics, to provide a baseline, we measured the overhead using the open-source [Pocket Casts](https://github.com/Automattic/pocket-casts-android) app. +If you're considering enabling Session Replay, it's important to first understand the potential performance impact to your app. While accurate metrics require realistic testing where you apply typical access patterns and correlate the results with your business metrics, to provide a baseline, we measured the overhead using the open-source Pocket Casts app. You can learn more about the various optimizations implemented in the React Native Replay SDK in the [Replay Performance Overhead](/product/explore/session-replay/mobile/performance-overhead/) docs.