Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: Add new SDK overhead page for Flutter (+Dart) #12077

Merged
merged 6 commits into from
Dec 12, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions docs/platforms/dart/overhead/index.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
---
title: SDK Overhead
description: "Learn about Sentry's Dart SDK overhead and how you can tailor your configuration to minimize it."
sidebar_order: 7500
---

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 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 some tasks to native implementations, use debouncing when appropriate, or we postpone processing to a later time if possible.

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-dart/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: <PlatformLink to="/usage/#capturing-errors">`captureError`</PlatformLink> and <PlatformLink to="/usage/#capturing-messages">`captureMessage`</PlatformLink>. 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.

## Breadcrumbs

<PlatformLink to="/enriching-events/breadcrumbs">Breadcrumbs</PlatformLink> 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 (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.

## Tracing and Performance Monitoring

As stated in our <Link to="/product/performance/performance-overhead">product docs on the topic</Link>, 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.
43 changes: 43 additions & 0 deletions docs/platforms/flutter/overhead/index.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
---
title: SDK Overhead
description: "Learn about Sentry's Flutter SDK overhead and how you can tailor your configuration to minimize it."
sidebar_order: 7500
---

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 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 some tasks to native implementations, use debouncing when appropriate, or we postpone processing to a later time if possible.

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-dart/issues/new/choose) on our SDK repo and make sure you provide as much context as you can.
buenaflor marked this conversation as resolved.
Show resolved Hide resolved

## 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: <PlatformLink to="/usage/#capturing-errors">`captureError`</PlatformLink> and <PlatformLink to="/usage/#capturing-messages">`captureMessage`</PlatformLink>. 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 <PlatformLink to="/enriching-events/screenshots">Screenshots</PlatformLink> and <PlatformLink to="/enriching-events/viewhierarchy">View Hierarchy</PlatformLink> of the app's UI at the time of an error or 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.
kahest marked this conversation as resolved.
Show resolved Hide resolved

## Breadcrumbs

<PlatformLink to="/enriching-events/breadcrumbs">Breadcrumbs</PlatformLink> 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 (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.

## Tracing and Performance Monitoring

As stated in our <Link to="/product/performance/performance-overhead">product docs on the topic</Link>, 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 <Link to="/product/explore/profiling/performance-overhead">product docs on the topic</Link>, 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.
Loading