From d2af3cf7db566ed19ffc1cabe8f59cd4dfc0dc36 Mon Sep 17 00:00:00 2001 From: Nelsito Date: Wed, 29 Jan 2025 14:35:16 -0300 Subject: [PATCH 1/3] Update faq.md with device impact --- docs/android/faq.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/docs/android/faq.md b/docs/android/faq.md index ae129983..f50fc8aa 100644 --- a/docs/android/faq.md +++ b/docs/android/faq.md @@ -89,6 +89,20 @@ Newer AGP versions provide a more performant API for bytecode instrumentation am We have benchmarked the Embrace SDK's performance during app launch between 10 and 50 milliseconds. In practice, this is between 1-3% of typical app launch time. +### **What is the impact of adding Embrace Android SDK regarding app performance, device battery/data usage/disk space?** + +TL;DR _The impact depends on how you use the API._ + +The incremental battery usage is negligible because we are mostly dormant unless telemetry is being recorded, in which case the CPU should already be active. We do have a thread that monitors the main thread for ANRs if that feature is enabled when the app is in the foreground, but that only pings the thread every 100ms +For disk usage, we only hit the disk every 2 seconds when the app is in the foreground, regardless of how much telemetry is recorded—everything is buffered in memory and flushed to disk at that interval. In the background, we only do so if new telemetry has been added since the last check, so it's pretty lightweight if you're not recording data. +For disk space, we buffer on disk session data that hasn't been sent, and once it's successfully sent, it's deleted. The data is compressed, too, so unless the device has a lot of unsent requests because of the lack of network connection, the disk size wouldn't be more than a couple of megabytes. +In terms of data usage, it also depends on usage, but it's negligible for a modern app. Sessions typically get bigger if there are a lot of network requests to be logged, but they compress well and each is usually less than 100 KB (P99 for sessions is 98KB) +Our delivery layer retry is based on exponential backoff, starting at 1 minute and doubling with every failure. We only attempt to do so if we detect a network connection. So you should never see tight loops of failures and retries that would clog up the CPU, as the 7th retry will be after 64m. The request connection timeout is 10s, and the read timeout is 60. +In terms of disk persistence, we store a maximum of 500 payloads that have failed to be sent - and we trim based on priority and time, i.e., if we need to trim, we trim the less important payloads first, starting with logs, then sessions, then crashes, by First-In-First-Out. So even if the app is offline for a long time, there is still a ceiling of how much extra disk space will be consumed, which may be 10s of MBs if you're logging a lot of data. +Regarding payload size, our backend rejects any payloads greater than 3mb, so in practice, with the data limits we have set on the various telemetry types we capture, it should not get close to that. + +We proactively profile the impact of instrumentation on the app. Spans generally take < 1 ms to start and stop, so the overhead to measurement shouldn't impact user experience, even if you do it directly on the main thread. + ### **What determines if a session is classified as prod or dev?** A session is classified as dev if all of the following are true: From 36c10c1248da108663ec8fef883f62b2f6470288 Mon Sep 17 00:00:00 2001 From: Nelsito Date: Wed, 5 Feb 2025 13:26:40 -0300 Subject: [PATCH 2/3] Update docs/android/faq.md Co-authored-by: Francisco Prieto --- docs/android/faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/android/faq.md b/docs/android/faq.md index f50fc8aa..6b72edaf 100644 --- a/docs/android/faq.md +++ b/docs/android/faq.md @@ -94,7 +94,7 @@ We have benchmarked the Embrace SDK's performance during app launch between 10 a TL;DR _The impact depends on how you use the API._ The incremental battery usage is negligible because we are mostly dormant unless telemetry is being recorded, in which case the CPU should already be active. We do have a thread that monitors the main thread for ANRs if that feature is enabled when the app is in the foreground, but that only pings the thread every 100ms -For disk usage, we only hit the disk every 2 seconds when the app is in the foreground, regardless of how much telemetry is recorded—everything is buffered in memory and flushed to disk at that interval. In the background, we only do so if new telemetry has been added since the last check, so it's pretty lightweight if you're not recording data. +For disk usage, we only hit the disk every 2 seconds when the app is in the foreground, regardless of how much telemetry is recorded. Everything is buffered in memory and flushed to disk at that interval. In the background, we only do so if new telemetry has been added since the last check, so it's pretty lightweight if you're not recording data. For disk space, we buffer on disk session data that hasn't been sent, and once it's successfully sent, it's deleted. The data is compressed, too, so unless the device has a lot of unsent requests because of the lack of network connection, the disk size wouldn't be more than a couple of megabytes. In terms of data usage, it also depends on usage, but it's negligible for a modern app. Sessions typically get bigger if there are a lot of network requests to be logged, but they compress well and each is usually less than 100 KB (P99 for sessions is 98KB) Our delivery layer retry is based on exponential backoff, starting at 1 minute and doubling with every failure. We only attempt to do so if we detect a network connection. So you should never see tight loops of failures and retries that would clog up the CPU, as the 7th retry will be after 64m. The request connection timeout is 10s, and the read timeout is 60. From 8f184f2a3bfad9f205c8bc31e0afd89cf8b64d35 Mon Sep 17 00:00:00 2001 From: Nelsito Date: Wed, 5 Feb 2025 13:26:50 -0300 Subject: [PATCH 3/3] Update docs/android/faq.md Co-authored-by: Francisco Prieto --- docs/android/faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/android/faq.md b/docs/android/faq.md index 6b72edaf..65e267b0 100644 --- a/docs/android/faq.md +++ b/docs/android/faq.md @@ -95,7 +95,7 @@ TL;DR _The impact depends on how you use the API._ The incremental battery usage is negligible because we are mostly dormant unless telemetry is being recorded, in which case the CPU should already be active. We do have a thread that monitors the main thread for ANRs if that feature is enabled when the app is in the foreground, but that only pings the thread every 100ms For disk usage, we only hit the disk every 2 seconds when the app is in the foreground, regardless of how much telemetry is recorded. Everything is buffered in memory and flushed to disk at that interval. In the background, we only do so if new telemetry has been added since the last check, so it's pretty lightweight if you're not recording data. -For disk space, we buffer on disk session data that hasn't been sent, and once it's successfully sent, it's deleted. The data is compressed, too, so unless the device has a lot of unsent requests because of the lack of network connection, the disk size wouldn't be more than a couple of megabytes. +For disk space, we buffer on disk session data that hasn't been sent, and once it's successfully sent, it's deleted. The data is compressed too, so unless the device has a lot of unsent requests due to a lack of network connection, the disk usage should not exceed a few megabytes. In terms of data usage, it also depends on usage, but it's negligible for a modern app. Sessions typically get bigger if there are a lot of network requests to be logged, but they compress well and each is usually less than 100 KB (P99 for sessions is 98KB) Our delivery layer retry is based on exponential backoff, starting at 1 minute and doubling with every failure. We only attempt to do so if we detect a network connection. So you should never see tight loops of failures and retries that would clog up the CPU, as the 7th retry will be after 64m. The request connection timeout is 10s, and the read timeout is 60. In terms of disk persistence, we store a maximum of 500 payloads that have failed to be sent - and we trim based on priority and time, i.e., if we need to trim, we trim the less important payloads first, starting with logs, then sessions, then crashes, by First-In-First-Out. So even if the app is offline for a long time, there is still a ceiling of how much extra disk space will be consumed, which may be 10s of MBs if you're logging a lot of data.