cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Extremely high background data usage when Firebase Performance is enabled in our Android app

Joseph.Kreiser
Producer

We are developing an Android app that uses AppDynamics 20.5.0 and Firebase Bill-of-Materials 26.8.0, which includes Firebase Performance.  We recently received a report from a user who found that the background network data usage of our app was extremely high, on the order of gigabytes per month.

 

Upon investigation, we found that the call to the https://col.eum-appdynamics.com endpoint would consume a lot of data as requests were repeatedly made to it on app startup.  We went through our app release history and noticed that this behavior started around the time we added Firebase Bill-of-Materials, and after digging some more, found that the high data usage stopped when we disabled Firebase Performance.

 

This behavior is present even when we update AppDynamics to its latest version (21.11.0) and Firebase Bill-of-Materials to its latest version (30.0.1).

 

Is this a known issue, and if so, is there anything that can be done on the mobile app side's AppDynamics configuration to prevent the high data usage?  In the short term, we've disabled Firebase Performance in the app, but obviously it's not an optimal solution.

5 REPLIES 5

Tony.Zhang
AppDynamics Team

Here's something you might find interesting. In order to figure out which Firebase network calls were getting captured by AppDynamics, I enabled Firebase Performance again and turned on AppDynamics logging with

 

Instrumentation.start(
AgentConfiguration.builder()
.withAppKey(BuildConfig.APPDYNAMICS_EUM_KEY)
.withContext(applicationContext)
.withLoggingEnabled(true)

...

 

I did see captures of a Firebase URL (https://firebaselogging-pa.googleapis.com/v1/firelog/legacy/batchlog) in the logs, like this:

 

 

I/AppDynamics: [{"type":"network-request","ec":5216,"eid":"032d59a6-8e77-455c-8e8e-c3605d8dafcf","sessionCounter":-1,"st":1652898366005,"sut":1311277514,"et":1652898366960,"eut":1311278468,"bkgd":false,"url":"https://firebaselogging-pa.googleapis.com/v1/firelog/legacy/batchlog","hrc":200,"crg":"f2629914-c6ab-4a8e-8a2e-3fae504f1274","bts":[],"see":false,"is":"AppDynamics.URLConnection","avi":52,"av":"4.0.8","agv":"20.5.0","ab":"e7031ad7","dm":"samsung","dmo":"SM-G781U1","ds":110167,"tm":"5628","cf":"1804800","cc":8,"osv":"12","ca":"unknown","ct":"wifi","bid":"33518b01-0b6f-496e-bc1b-8810a92469b6"}]

 

 

So I tried filtering them out with this:

      Instrumentation.start(
AgentConfiguration.builder()
.withAppKey(BuildConfig.APPDYNAMICS_EUM_KEY)
.withContext(applicationContext)
.withLoggingEnabled(true)
.withExcludedUrlPatterns(
setOf(
"^https:\\/\\/firebaselogging\\-pa\\.googleapis\\.com.*\$",
)
)

But they were fairly infrequent, and the high data usage was still present.

 

What I did see being printed repeatedly were entries like these, which seemed to be logging calls made to the AppDynamics collection URL (https://col.eum-appdynamics.com/eumcollector/mobileMetrics?version=2

 

 

2022-05-18 14:29:25.005 28372-28457/? I/AppDynamics: [2:29:25 PM Eastern Daylight Time] Agent sending beacons to collector (https://col.eum-appdynamics.com/eumcollector/mobileMetrics?version=2) [AD-AAB-AAC-NMJ]:
2022-05-18 14:29:25.006 28372-28457/? I/AppDynamics: [{"type":"network-request","ec":5381,"eid":"6e02c4f4-fe8a-4c7e-9a7b-45297837b2be","sessionCounter":-1,"st":1652898564881,"sut":1311476390,"et":1652898564999,"eut":1311476508,"bkgd":false,"url":"https://col.eum-appdynamics.com/eumcollector/mobileMetrics?version=2","pcl":2,"hrc":200,"crg":"da9ee96c-db86-4174-a35e-535d02f60736","bgan":"appdynamics_eee1d4f8-67a2-498e-a725-47e29803822e","bts":[{"btId":"559464","time":-1,"estimatedTime":0}],"see":false,"is":"AppDynamics.URLConnection","avi":52,"av":"4.0.8","agv":"20.5.0","ab":"e7031ad7","dm":"samsung","dmo":"SM-G781U1","ds":110167,"tm":"5628","cf":"1804800","cc":8,"osv":"12","ca":"unknown","ct":"wifi","bid":"8f6360f2-6186-46d0-ac36-d9f340cff65b"}]

 

 

It almost seems like AppDynamics is capturing calls to its own collection URL, repeatedly, but only when Firebase Performance is enabled.

 

If I filter out the AppDynamics collection URL as well, like this:

      Instrumentation.start(
AgentConfiguration.builder()
.withAppKey(BuildConfig.APPDYNAMICS_EUM_KEY)
.withContext(applicationContext)
.withLoggingEnabled(true) // set default INFO logging. Tagged "AppDynamics".
.withExcludedUrlPatterns(
setOf(
"^https:\\/\\/firebaselogging\\-pa\\.googleapis\\.com.*\$",
"^https:\\/\\/col.eum\\-appdynamics.com\\/eumcollector.*\$",
)
)

then the high data usage stops.

Hi @Joseph.Kreiser @Tony.Zhang 

 

Your reply is now live on the thread. It was being caught by spam since you had a post with a large amount of text and code. I have gone ahead and approved your replies and deleted all but the first one.

 

Going forward you should not have this problem.


Thanks,

Ryan, Cisco AppDynamics Community Manager




Found something helpful? Click the Accept as Solution button to help others find answers faster.

Liked something? Click the Thumbs Up button.



Check out Observabiity in Action

new deep dive videos weekly in the Knowledge Base.

Hi Joseph,

 

Thank you for the detailed followup. Good to know that this resolves the problem. We are not familiar with internal workings of Firebase performance, but its likely due to mutual instrumentation between the plugins. Will look into how this issue can be more easily avoided in the future and address it in a future release. Meanwhile this workaround, or the one I suggested should suffice. Let us know if you run into any more issues!

I should also mention that I tried excluding Firebase classes, like this:

 

adeum {
    ...

    excludeClasses = ['com.google.firebase.*']
}

 

but the high data usage was still present.

Join Us On December 10
Learn how Splunk and AppDynamics are redefining observability


Register Now!

Observe and Explore
Dive into our Community Blog for the Latest Insights and Updates!


Read the blog here
Top Kudoed Authors