From eb3e260a2e95525bbb8bf68f86092e62521ad469 Mon Sep 17 00:00:00 2001 From: Karl Heinz Struggl Date: Tue, 3 Dec 2024 17:12:22 +0100 Subject: [PATCH 1/3] adds new SDK overhead page for Android --- docs/platforms/android/overhead/index.mdx | 43 +++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 docs/platforms/android/overhead/index.mdx diff --git a/docs/platforms/android/overhead/index.mdx b/docs/platforms/android/overhead/index.mdx new file mode 100644 index 0000000000000..79d6170dcea43 --- /dev/null +++ b/docs/platforms/android/overhead/index.mdx @@ -0,0 +1,43 @@ +--- +title: SDK Overhead +description: "Learn about Sentry's Android SDK overhead." +sidebar_order: 7500 +--- + +Adding new features or dependencies to your app incurs additional costs on resources - CPU time, memory usage, network bandwidth, among other things. Sentry SDKs are no different. This document adds transparency to the possible overhead that using this SDK can add, and help you find the feature set and configurations that work best for you. + +## General Approach + +The SDK is designed to have minimal to no impact on the user experience. To achieve this, we utilize an array of tools to measure and optimize the performance of our implementations continuously. + +We also employ various techniques to ensure we don't add strain on the system's resources along the hot path - on Mobile, this very often means that we offload processing steps, I/O, and other things to a background thread, or we postpone processing to a later time if possible. + +If you find (e.g. via local Profiling, or using Sentry to improve the performance of your app) that the SDK does not operate within the guidelines mentioned below, please [open an issue](https://github.com/getsentry/sentry-java/issues/new/choose) on our SDK repo and make sure you provide as much context as you can. + +## Error Monitoring + +During regular operation, error monitoring incurs little to no overhead. Once an error or crash occurs, the user experience is compromised, and any crash handling routines operate under time constraints imposed by the system. This means that these implementations are highly optimized to perform the required work as quickly as possible. + +The SDK also provides methods to manually capture events: `captureError` and `captureMessage`. These methods perform some complex operations, such as capturing stack trace information, and while they are highly optimized as well, calling them in tight loops should be avoided. + +## Screenshots and View Hierarchy + +If you activate these features, the SDK will capture Screenshots and View Hierarchy of the app's UI at the time of the error crash. This incurs a small overhead that is unnoticeable during normal operation. + +If your app raises many errors in a tight loop, it can become too much to process quickly enough, and UI jank can be the result, so make sure you handle such cases appropriately. The SDK provides callbacks to fine-tune when to capture Screenshots and View Hierarchy, which can also be used to reduce performance impact in scenarios where you don't need screenshots or view hierarchies. + +## Breadcrumbs + +Breadcrumbs are collected through automated integrations or by manually adding them. To have them readily available for every event generated by the SDK, they are continuously persisted, and managed in a performant buffer. This is expected to have no impact on user experience. + +Capturing excessive numbers of breadcrumbs (e.g. by creating breadcrumbs for all log messages) can cause significant performance overhead. To mitigate this, review and adapt your app's usage of breadcrumbs. For example, increase the min-level of log messages for which to create breadcrumbs from `warn` to `error`. + +Note that increasing the max number of breadcrumbs **does not** improve performance and can even have a detrimental effect. + +## Tracing and Performance Monitoring + +As stated in our product docs on the topic, Tracing adds some overhead, but should have minimal impact on the performance of your application. In typical scenarios, the expected overhead is less than 3% of the app's resource utilization. + +## Profiling + +As stated in our product docs on the topic, Profiling adds some overhead, but should have minimal impact on the performance of your application. In typical scenarios, the expected overhead is less than 5% of the app's resource utilization. From ab948bc410f082ca625fe9f68b18dc672440fdfe Mon Sep 17 00:00:00 2001 From: Karl Heinz Struggl Date: Wed, 4 Dec 2024 17:16:19 +0100 Subject: [PATCH 2/3] adds session replay section --- docs/platforms/android/overhead/index.mdx | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/platforms/android/overhead/index.mdx b/docs/platforms/android/overhead/index.mdx index 79d6170dcea43..3c423d96fbf3b 100644 --- a/docs/platforms/android/overhead/index.mdx +++ b/docs/platforms/android/overhead/index.mdx @@ -41,3 +41,7 @@ As stated in our product do ## Profiling As stated in our product docs on the topic, Profiling adds some overhead, but should have minimal impact on the performance of your application. In typical scenarios, the expected overhead is less than 5% of the app's resource utilization. + +## Session Replay + +As stated in our product docs on the topic, Session Replay adds some overhead, but should have minimal impact on the performance of your application. For more details on the measured overhead, read the performance overhead docs for this SDK. From c430898bfc1c6e18597075edcaf316a1873336cf Mon Sep 17 00:00:00 2001 From: Karl Heinz Struggl Date: Thu, 5 Dec 2024 01:23:18 -0800 Subject: [PATCH 3/3] Apply suggestions from code review Co-authored-by: Alex Krawiec --- docs/platforms/android/overhead/index.mdx | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/platforms/android/overhead/index.mdx b/docs/platforms/android/overhead/index.mdx index 3c423d96fbf3b..021cb66880154 100644 --- a/docs/platforms/android/overhead/index.mdx +++ b/docs/platforms/android/overhead/index.mdx @@ -4,15 +4,15 @@ description: "Learn about Sentry's Android SDK overhead." sidebar_order: 7500 --- -Adding new features or dependencies to your app incurs additional costs on resources - CPU time, memory usage, network bandwidth, among other things. Sentry SDKs are no different. This document adds transparency to the possible overhead that using this SDK can add, and help you find the feature set and configurations that work best for you. +Adding new features or dependencies to your app incurs additional costs on resources - CPU time, memory usage, and network bandwidth, among other things. Sentry SDKs are no different. This document adds transparency to the possible overhead that using our SDK can add, and help you find the feature set and configurations that work best for you. ## General Approach -The SDK is designed to have minimal to no impact on the user experience. To achieve this, we utilize an array of tools to measure and optimize the performance of our implementations continuously. +The SDK is designed to have minimal to no impact on user experience. To achieve this, we utilize an array of tools to continuously measure and optimize the performance of our implementations. We also employ various techniques to ensure we don't add strain on the system's resources along the hot path - on Mobile, this very often means that we offload processing steps, I/O, and other things to a background thread, or we postpone processing to a later time if possible. -If you find (e.g. via local Profiling, or using Sentry to improve the performance of your app) that the SDK does not operate within the guidelines mentioned below, please [open an issue](https://github.com/getsentry/sentry-java/issues/new/choose) on our SDK repo and make sure you provide as much context as you can. +If you find (for example via local Profiling, or using Sentry to improve the performance of your app) that the SDK does not operate within the guidelines mentioned below, please [open an issue](https://github.com/getsentry/sentry-java/issues/new/choose) on our SDK repo and make sure you provide as much context as you can. ## Error Monitoring @@ -28,9 +28,9 @@ If your app raises many errors in a tight loop, it can become too much to proces ## Breadcrumbs -Breadcrumbs are collected through automated integrations or by manually adding them. To have them readily available for every event generated by the SDK, they are continuously persisted, and managed in a performant buffer. This is expected to have no impact on user experience. +Breadcrumbs are collected through automated integrations or by manually adding them. To have them readily available for every event generated by the SDK, they are continuously persisted, and managed in a performant buffer. This shouldn't impact user experience. -Capturing excessive numbers of breadcrumbs (e.g. by creating breadcrumbs for all log messages) can cause significant performance overhead. To mitigate this, review and adapt your app's usage of breadcrumbs. For example, increase the min-level of log messages for which to create breadcrumbs from `warn` to `error`. +Capturing excessive numbers of breadcrumbs (for example, creating breadcrumbs for all log messages) can cause significant performance overhead. To mitigate this, review and adapt your app's usage of breadcrumbs. For example, increase the min-level of log messages that create breadcrumbs from `warn` to `error`. Note that increasing the max number of breadcrumbs **does not** improve performance and can even have a detrimental effect.