topic auto-instrumentation - Overhead in Real User Monitoring

auto-instrumentation - Overhead

Sara — Thu, 10 Feb 2022 17:38:48 GMT

Hi, I want to perform automatic instrumentation for Android (Dynatrace Android Gradle plugin) and iOS and I want to know how much the weight of the mobile application will increase and how much data consumption (internet) will be after performing the instrumentation. I was asking and they gave me an answer Android manual setup and instrumentation | AppMon documentation (dynatrace.com) and Mobile UEM | AppMon documentation (dynatrace.com). The drawback is that this information is from AppMon and is not very recent, ¿Is there another document that I can review or a more recent version that has this information?

Thanks

Re: auto-instrumentation - Overhead

Julius_Loman — Fri, 11 Feb 2022 07:29:28 GMT

CPU overhead is so low I can't really be measured. The application binary size will increase slightly (not sure about the current size but it was ~500kB last time I tried to compare it). And regarding the data consumption - it's best to measure it by yourself if you are worried. The payloads are effective, compressed and sent out in batches from the instrumented application.

Re: auto-instrumentation - Overhead

ljavelac — Thu, 17 Feb 2022 00:07:54 GMT

Hello Julius

¿Do you know a tool to measure data consumption ? and ¿How can it be identified the dynatrace batches?

Thanks

Re: auto-instrumentation - Overhead

Julius_Loman — Fri, 18 Feb 2022 07:12:39 GMT

@ljavelac you will need to measure it by yourself somehow. The beacon URL contains /dtmb or /mbeacon depending on the configuration of your application and the SDK version used.

Re: auto-instrumentation - Overhead

AntonioSousa — Fri, 18 Feb 2022 09:16:06 GMT

@ljavelac

If you don't have root/jailbreaked device, the most correct way to acknowledge the Dynatrace traffic is to capture it on the network side. I know this is not easy, but it is the most correct way. This is because you will then have to filter out Dynatrace traffic, as in a typical situation, phones are very network chatty, your app will probably be using it's own data, and also you might have other 3rd parties like Firebase.

I have done this before, and it's only a few KBs per user action, but it can vary, depending on multiple factors, including of course the ones @Julius_Loman mentioned.

Re: auto-instrumentation - Overhead

ljavelac — Wed, 23 Mar 2022 22:30:30 GMT

I performed some tests to measure the data consumption of the mobile RUM in a native android application instrumented via Dynatrace Android Gradle plugin.

So I just want to post my experience and results.

I used theese tools and I got a good experience, but you should use them under your responsability:

Tpacketcapture, this app is available in play store, and this is a vpn app that capture the network traffic of the smartphone and save it in a .pcap file.
WireShark for PC to analyze the .pcap file.

I performed 3 tests, 2 using wifi and 1 using mobile data. Then I checked the user sessions in Dynatrace Saas to determine the number of user action, errors, crash, events and session properties reported.

Then I analyzed each .pcap file, here it was a little difficult to identify the Dynatrace IPs so I tried with resolving the domain by running a nslookup command to the mobile beacon of the tenant, finally I got 5 distinct IPs.

Then I filtered the IPs and verified the payloads to be sure about the Dynatrace traffic nodes. Here I found some references to amazon and the mbeacon.

Here a result table:

I realized that there were incoming an outcoming traffic in the app for the Dynatrace communication.

App incoming traffic from dynatrace = mostly security validations, TLS certificates (aws, dynatrace)....

App outcoming traffic to dynatrace= mostly mobile rum reported data.

Finally

Data consumption for a user session with no crashes is around:

test 2

outcoming = 16.91 KB rounded to 17 KB
incoming = 47.91 KB rounded to 48 KB
Total = 64.82 KB rounded to 65 KB

User actions = 33

test 3

outcoming = 18.7 KB rounded to 19 KB
incoming = 48.1 KB rounded to 48 KB
Total = 66.8 KB rounded to 67 KB

User actions = 38

So, if I take the outcoming KB and divide by the number of user actions I get around 0,5 KB per user action.

Data consumption for a user session with crash is around:

test 1

outcoming = 24,7 KB rounded to 25 KB
incoming = 73,6 KB rounded to 74 KB
Total = 98.3 KB rounded to 98 KB

User actions = 16

The Data consumption increased, I think it could be because of the crash stacktrace reported.

So, if I take the outcoming KB and divide by the number of user actions I get around 1,5 KB per user action.

For ending this post, I tried to raise a equation using useraction as variable and depending if the user action have crash or doesn´t. But this is very very experimental an is based only in 3 tests so there aren't enought data points.

The customer was concerned about data consumption, so this challenge was interesting and we got information that helped the customer to trust more in Dynatrace.

Re: auto-instrumentation - Overhead

AntonioSousa — Wed, 23 Mar 2022 22:41:11 GMT

@ljavelac

Thanks so much for you investigation! I suppose that the traffic you mention is only the Dynatrace traffic, as 500 bytes per user action is even lower that what I had imagined!

Re: auto-instrumentation - Overhead

ljavelac — Wed, 23 Mar 2022 22:47:14 GMT

You're right, the traffic mention is only the Dynatrace traffic.