Diese Seite enthält Tipps zur Fehlerbehebung für den Einstieg in die Leistungsüberwachung oder die Verwendung von Leistungsüberwachungsfunktionen und -tools.
Erste Überprüfungen zur Fehlerbehebung
Die folgenden zwei Überprüfungen sind allgemeine Best Practices, die jedem vor der weiteren Fehlerbehebung empfohlen werden.
1. Überprüfen Sie Protokollmeldungen auf Leistungsereignisse
Überprüfen Sie Ihre Protokollmeldungen, um sicherzustellen, dass das Leistungsüberwachungs-SDK Leistungsereignisse erfasst.
Aktivieren Sie die Debug-Protokollierung wie folgt:
- Wählen Sie in Xcode (mindestens v13.3.1) Produkt > Schema > Schema bearbeiten aus.
- Wählen Sie im linken Menü Ausführen und dann die Registerkarte Argumente aus.
- Fügen Sie im Abschnitt Beim Start übergebene Argumente
-FIRDebugEnabledhinzu.
Überprüfen Sie Ihre Protokollmeldungen auf Fehlermeldungen.
Performance Monitoring kennzeichnet seine Protokollmeldungen mit
Firebase/Performance, sodass Sie Ihre Protokollmeldungen filtern können.Suchen Sie nach den folgenden Arten von Protokollen, die darauf hinweisen, dass die Leistungsüberwachung Leistungsereignisse protokolliert:
-
Logging trace metric: TRACE_NAME , FIREBASE_PERFORMANCE_CONSOLE_URL -
Logging network request trace: URL
-
Klicken Sie auf die URL, um Ihre Daten in der Firebase-Konsole anzuzeigen. Es kann einen Moment dauern, bis die Daten im Dashboard aktualisiert werden.
Wenn Ihre App keine Leistungsereignisse protokolliert, lesen Sie die Tipps zur Fehlerbehebung .
2. Überprüfen Sie das Firebase-Status-Dashboard
Überprüfen Sie das Firebase-Status-Dashboard , falls ein bekannter Ausfall für Firebase oder für die Leistungsüberwachung vorliegt.
Erste Schritte mit der Leistungsüberwachung
Wenn Sie mit der Leistungsüberwachung ( iOS+ | Android | Web ) beginnen, können die folgenden Tipps zur Fehlerbehebung bei Problemen helfen, bei denen Firebase das SDK erkennt oder Ihre ersten Leistungsdaten in der Firebase-Konsole anzeigt.
Firebase kann erkennen, ob Sie das Leistungsüberwachungs-SDK erfolgreich zu Ihrer App hinzugefügt haben, wenn es Ereignisinformationen (wie App-Interaktionen) von Ihrer App empfängt. Normalerweise zeigt das Leistungs- Dashboard der Firebase-Konsole innerhalb von 10 Minuten nach dem Start Ihrer App die Meldung „SDK erkannt“ an. Dann zeigt das Dashboard innerhalb von 30 Minuten die ersten verarbeiteten Daten an.
Wenn seit dem Hinzufügen der neuesten Version des SDK zu Ihrer App mehr als 10 Minuten vergangen sind und immer noch keine Änderung angezeigt wird, überprüfen Sie Ihre Protokollmeldungen , um sicherzustellen, dass die Leistungsüberwachung Ereignisse protokolliert. Probieren Sie die entsprechenden Schritte zur Fehlerbehebung aus, wie unten beschrieben, um eine verzögerte SDK-Erkennungsmeldung zu beheben.
Wenn Sie noch lokal entwickeln, versuchen Sie, mehr Ereignisse für die Datenerfassung zu generieren:
Entwickeln Sie Ihre App mit einem Simulator oder Testgerät weiter.
Generieren Sie Ereignisse, indem Sie Ihre App mehrmals zwischen Hintergrund und Vordergrund wechseln, mit Ihrer App interagieren, indem Sie über Bildschirme navigieren und/oder Netzwerkanfragen auslösen.
Stellen Sie sicher, dass Ihre Firebase-Konfigurationsdatei (
Google-Service-Info.plist) Ihrer App korrekt hinzugefügt wurde und dass Sie die Datei nicht geändert haben. Überprüfen Sie insbesondere Folgendes:An den Namen der Konfigurationsdatei werden keine zusätzlichen Zeichen wie
(2)angehängt.Die Konfigurationsdatei befindet sich im Stammverzeichnis Ihres XCode-Projekts und wird den richtigen Zielen hinzugefügt.
Die in der Konfigurationsdatei aufgeführte Firebase-Apple-App-ID (
GOOGLE_APP_ID) ist für Ihre App korrekt. Suchen Sie Ihre Firebase-App-ID auf der Karte Ihre Apps Ihrer Projekteinstellungen .
Wenn etwas mit der Konfigurationsdatei in Ihrer App nicht in Ordnung zu sein scheint, versuchen Sie Folgendes:
Löschen Sie die Konfigurationsdatei, die Sie derzeit in Ihrer App haben.
Befolgen Sie diese Anweisungen , um eine neue Konfigurationsdatei herunterzuladen und zu Ihrer Apple-App hinzuzufügen.
Wenn das SDK Ereignisse protokolliert und alles korrekt eingerichtet zu sein scheint, aber die SDK-Erkennungsmeldung oder die verarbeiteten Daten (nach zwei Stunden) immer noch nicht angezeigt werden, wenden Sie sich an den Firebase-Support .
Stellen Sie sicher, dass das Leistungsüberwachungs-SDK nicht durch eines der folgenden Flags in Ihrer
Info.plistDatei deaktiviert ist:-
firebase_performance_collection_enabled -
firebase_performance_collection_deactivated
-
Stellen Sie sicher, dass die Leistungsüberwachung zur Laufzeit nicht deaktiviert ist ( Swift | Obj-C ).
Wenn Sie in Ihrer App nichts Deaktiviertes finden, wenden Sie sich an den Firebase-Support .
Die Leistungsüberwachung verarbeitet Leistungsereignisdaten, bevor sie im Leistungs- Dashboard angezeigt werden.
Wenn seit dem Erscheinen der Meldung „SDK erkannt“ mehr als 24 Stunden vergangen sind und immer noch keine Daten angezeigt werden, überprüfen Sie das Firebase-Status-Dashboard , ob ein bekannter Ausfall vorliegt. Wenn kein Ausfall vorliegt, wenden Sie sich an den Firebase-Support .
Allgemeine Fehlerbehebung
Wenn Sie das SDK erfolgreich hinzugefügt haben und die Leistungsüberwachung in Ihrer App verwenden, können die folgenden Tipps zur Fehlerbehebung bei allgemeinen Problemen helfen, die Leistungsüberwachungsfunktionen und -tools betreffen.
Wenn Sie keine Protokollmeldungen für Leistungsereignisse sehen , versuchen Sie es mit den folgenden Schritten zur Fehlerbehebung:
Stellen Sie sicher, dass das Leistungsüberwachungs-SDK nicht durch eines der folgenden Flags in Ihrer
Info.plistDatei deaktiviert ist:-
firebase_performance_collection_enabled -
firebase_performance_collection_deactivated
-
Stellen Sie sicher, dass die Leistungsüberwachung zur Laufzeit nicht deaktiviert ist ( Swift | Obj-C ).
Wenn Sie in Ihrer App nichts Deaktiviertes finden, wenden Sie sich an den Firebase-Support .
Wenn Ihnen Daten für Bildschirmrendering-Traces fehlen, versuchen Sie die folgenden Schritte zur Fehlerbehebung:
Sehen Sie Leistungsdaten für automatisch erfasste Ablaufverfolgungen , aber nicht für benutzerdefinierte Codeablaufverfolgungen ? Versuchen Sie die folgenden Schritte zur Fehlerbehebung:
Überprüfen Sie die Einrichtung von benutzerdefinierten Code-Traces, die über die Trace-API instrumentiert wurden, insbesondere Folgendes:
- Namen für benutzerdefinierte Codeablaufverfolgungen und benutzerdefinierte Metriken müssen die folgenden Anforderungen erfüllen: keine führenden oder abschließenden Leerzeichen, kein führender Unterstrich (
_) und eine maximale Länge von 32 Zeichen. - Alle Ablaufverfolgungen müssen gestartet und gestoppt werden. Traces, die nicht gestartet, nicht gestoppt oder vor dem Start gestoppt wurden, werden nicht protokolliert.
- Namen für benutzerdefinierte Codeablaufverfolgungen und benutzerdefinierte Metriken müssen die folgenden Anforderungen erfüllen: keine führenden oder abschließenden Leerzeichen, kein führender Unterstrich (
Überprüfen Sie Ihre Protokollmeldungen, um sicherzustellen, dass die Leistungsüberwachung erwartete Ablaufverfolgungen für benutzerdefinierten Code protokolliert.
Wenn die Leistungsüberwachung Ereignisse protokolliert, aber nach 24 Stunden keine Daten angezeigt werden, wenden Sie sich an den Firebase-Support .
Wenn Ihnen Netzwerkanforderungsdaten fehlen, versuchen Sie die folgenden Schritte zur Fehlerbehebung:
Auf Inkompatibilität der Netzwerkbibliothek prüfen. Die Leistungsüberwachung erfasst automatisch Metriken für Netzwerkanforderungen , die die folgenden Netzwerkbibliotheken verwenden:
- Für Swift: URLSession und URLConnection
- Für Objective-C: NSURLSession und NSURLConnection
Beachten Sie, dass Sie eine benutzerdefinierte Überwachung für Netzwerkanforderungen hinzufügen können.
Beachten Sie Folgendes:
Abhängig vom Verhalten Ihres Codes und der von Ihrem Code verwendeten Netzwerkbibliotheken meldet die Leistungsüberwachung möglicherweise nur abgeschlossene Netzwerkanforderungen. Dies bedeutet, dass offen gelassene HTTP/S-Verbindungen möglicherweise nicht gemeldet werden.
Die Leistungsüberwachung meldet keine Netzwerkanforderungen mit ungültigen
Content-TypeHeadern. Netzwerkanforderungen ohne dieContent-TypeHeader werden jedoch weiterhin akzeptiert.
Erfahren Sie mehr darüber , wie Performance Monitoring Netzwerkanforderungsdaten unter URL-Mustern aggregiert .
Sie können auch benutzerdefinierte URL-Muster ausprobieren!
FAQ
Wir haben Top Issues durch Recent Alerts ersetzt, als Folgemaßnahme zu unserer kürzlichen Einführung von Alerts, die Sie automatisch benachrichtigen, wenn die von Ihnen festgelegten Schwellenwerte überschritten werden. Probleme sind jetzt veraltet und werden durch Warnungen ersetzt.
Die Apps-Auswahl oben auf der Leistungskarte filtert die Warnungseinträge unter Letzte Warnungen . Es werden nur die drei neuesten Warnungen für die ausgewählte(n) App(s) angezeigt.
Weitere Informationen zu Warnungen finden Sie unter Einrichten von Warnungen für Leistungsprobleme .
Die Leistungsüberwachung unterstützt Warnungen für Metriken, die definierte Schwellenwerte überschreiten. Um Verwechslungen mit diesen konfigurierbaren Schwellenwerten für Leistungsmetriken zu vermeiden, haben wir die Möglichkeit entfernt, Schwellenwerte für Probleme zu konfigurieren .
Wir haben die Seiten „Details“ und „Metriken“ durch eine neu gestaltete, zentralisierte Benutzeroberfläche (UI) ersetzt, um die Problembehandlung zu verbessern. Diese neue Benutzeroberfläche zur Fehlerbehebung bietet die gleiche Kernfunktionalität wie Details und Metriken. Weitere Informationen zur Fehlerbehebung finden Sie unter Weitere Daten für eine bestimmte Ablaufverfolgung anzeigen .
Die Leistungsüberwachung erfasst Leistungsdaten von den Benutzergeräten Ihrer App. Wenn Ihre Anwendung viele Benutzer hat oder wenn die App eine große Menge an Leistungsaktivitäten generiert, kann die Leistungsüberwachung die Datenerfassung auf eine Teilmenge von Geräten beschränken, um die Anzahl der verarbeiteten Ereignisse zu reduzieren. Diese Grenzwerte sind hoch genug, damit die Metrikwerte auch bei weniger Ereignissen immer noch repräsentativ für die App-Erfahrung Ihres Benutzers sind.
Um das von uns erfasste Datenvolumen zu verwalten, verwendet Performance Monitoring die folgenden Stichprobenoptionen:
Ratenbegrenzung auf dem Gerät : Um zu verhindern, dass ein Gerät plötzliche Trace-Bursts sendet, begrenzen wir die Anzahl der von einem Gerät gesendeten Code- und Netzwerkanforderungs-Traces auf 300 Ereignisse alle 10 Minuten. Dieser Ansatz schützt das Gerät vor Schleifeninstrumenten, die große Mengen an Leistungsdaten senden können, und verhindert, dass ein einzelnes Gerät die Leistungsmessungen verzerrt.
Dynamisches Sampling : Die Leistungsüberwachung erfasst etwa 100 Millionen Ereignisse für Code-Traces und 100 Millionen für Netzwerkanfrage-Traces pro App für alle App-Benutzer. Eine dynamische Abtastrate wird auf Geräten abgerufen (mit Firebase Remote Config), um zu bestimmen, ob ein zufälliges Gerät Ablaufverfolgungen erfassen und senden soll. Ein nicht zum Sampling ausgewähltes Gerät sendet keine Events. Die dynamische Abtastrate ist anwendungsspezifisch und passt sich an, um sicherzustellen, dass das Gesamtvolumen der gesammelten Daten unter dem Grenzwert bleibt.
Benutzersitzungen senden zusätzliche, detaillierte Daten vom Gerät eines Benutzers, was mehr Ressourcen zum Erfassen und Senden der Daten erfordert. Um die Auswirkungen von Benutzersitzungen zu minimieren, kann die Leistungsüberwachung auch die Anzahl der Sitzungen einschränken.
Serverseitige Ratenbegrenzung : Um sicherzustellen, dass Apps das Sampling-Limit nicht überschreiten, verwendet die Leistungsüberwachung möglicherweise serverseitiges Sampling, um einige von Geräten empfangene Ereignisse zu verwerfen. Obwohl diese Art der Begrenzung die Effektivität unserer Metriken nicht ändert, kann sie geringfügige Musterverschiebungen verursachen, einschließlich der folgenden:
- Die Anzahl der Ablaufverfolgungen kann sich von der Anzahl der Ausführungsschritte eines Codeabschnitts unterscheiden.
- Ablaufverfolgungen, die im Code eng gekoppelt sind, können jeweils eine unterschiedliche Anzahl von Abtastungen aufweisen.
Wir haben die Registerkarte Probleme durch die Einführung von Warnungen ersetzt, die Sie automatisch benachrichtigen, wenn die von Ihnen festgelegten Schwellenwerte überschritten werden. Sie müssen die Firebase-Konsole nicht mehr manuell überprüfen, um den Status eines Schwellenwerts zu ermitteln. Weitere Informationen zu Warnungen finden Sie unter Einrichten von Warnungen bei Leistungsproblemen .
Wir haben den Abschnitt „Leistungsüberwachung“ der Firebase-Konsole neu gestaltet, sodass auf der Registerkarte „Dashboard “ Ihre wichtigsten Messwerte und alle Ihre Spuren an einem Ort angezeigt werden. Im Rahmen der Neugestaltung haben wir die Seiten „Auf Gerät“ und „Netzwerk“ entfernt.
Die Ablaufverfolgungstabelle unten auf der Registerkarte „Dashboard “ enthält dieselben Informationen wie die Registerkarten „Auf Gerät “ und „Netzwerk “, jedoch mit einigen zusätzlichen Funktionen, einschließlich der Möglichkeit, Ihre Ablaufverfolgungen nach der prozentualen Änderung für eine bestimmte Metrik zu sortieren. Um alle Metriken und Daten für eine bestimmte Ablaufverfolgung anzuzeigen, klicken Sie auf den Ablaufverfolgungsnamen in der Ablaufverfolgungstabelle.
Zeigen Sie Ihre Ablaufverfolgungen in den folgenden Unterregisterkarten der Ablaufverfolgungstabelle an:
- Netzwerkanforderungs-Traces (sowohl vorkonfigurierte als auch benutzerdefinierte) – Unterregisterkarte „Netzwerkanforderungen“ .
- Traces für benutzerdefinierten Code – Unterregisterkarte für benutzerdefinierte Traces
- Ablaufverfolgungen für App-Start, App-im-Vordergrund, App-im-Hintergrund – Unterregisterkarte Benutzerdefinierte Ablaufverfolgungen
- Bildschirmwiedergabespuren – Unterregisterkarte Bildschirmwiedergabe
- Seitenladespuren — Unterregisterkarte Seitenladevorgang
Einzelheiten zur Ablaufverfolgungstabelle und zum Anzeigen von Metriken und Daten finden Sie auf der Übersichtsseite der Konsole ( iOS+ | Android | Web ).
Langsame Rendering-Frames und eingefrorene Frames werden mit einer angenommenen Aktualisierungsrate des Geräts von 60 Hz berechnet. Wenn die Aktualisierungsrate eines Geräts niedriger als 60 Hz ist, hat jeder Frame eine langsamere Renderzeit, da weniger Frames pro Sekunde gerendert werden. Längere Renderzeiten können dazu führen, dass mehr langsame oder eingefrorene Frames gemeldet werden, da mehr Frames langsamer gerendert werden oder einfrieren. Wenn die Aktualisierungsrate eines Geräts jedoch höher als 60 Hz ist, hat jeder Frame eine schnellere Renderzeit. Dies kann dazu führen, dass weniger langsame oder eingefrorene Frames gemeldet werden. Dies ist eine aktuelle Einschränkung im Leistungsüberwachungs-SDK.
Wenn Sie die BigQuery-Integration für Firebase Performance Monitoring aktiviert haben, werden Ihre Daten 12 bis 24 Stunden nach Tagesende (Pacific Time) nach BigQuery exportiert.
Beispielsweise sind die Daten für den 19. April am 20. April zwischen 12:00 Uhr und Mitternacht in BigQuery verfügbar (alle Daten und Uhrzeiten sind Pacific Time).
Near real-time data processing and display
Firebase Performance Monitoring processes collected performance data as it comes in, which results in near real-time data display in the Firebase console. Processed data displays in the console within a few minutes of its collection, hence the term "near real-time".
To take advantage of near real-time data processing, make sure your app uses a real-time compatible SDK version .
To take advantage of near real-time data processing, you only need to make sure that your app uses a Performance Monitoring SDK version that's compatible with real-time data processing.
These are the real-time compatible SDK versions:
- iOS — v7.3.0 or later
- tvOS — v8.9.0 or later
- Android — v19.0.10 or later (or Firebase Android BoM v26.1.0 or later)
- Web — v7.14.0 or later
Note that we always recommend using the latest version of SDK, but any version listed above will enable Performance Monitoring to process your data in near real time.
These are the SDK versions compatible with real-time data processing:
- iOS — v7.3.0 or later
- tvOS — v8.9.0 or later
- Android — v19.0.10 or later (or Firebase Android BoM v26.1.0 or later)
- Web — v7.14.0 or later
Note that we always recommend using the latest version of SDK, but any version listed above will enable Performance Monitoring to process your data in near real time.
If your app doesn't use a real-time compatible SDK version, you will still see all your app's performance data in the Firebase console. However, the display of performance data will be delayed by roughly 36 hours from the time of its collection.
Yes! Regardless of which SDK version an app instance uses, you'll see performance data from all your users.
However, if you're looking at recent data (less than roughly 36 hours old), then the displayed data is from users of app instances using a real-time compatible SDK version. The non-recent data, though, includes performance data from all versions of your app.
Contacting Firebase Support
If you reach out to Firebase Support , always include your Firebase App ID. Find your Firebase App ID in the Your apps card of your Project settings .
,This page provides troubleshooting tips for getting started with Performance Monitoring or using Performance Monitoring features and tooling.
First checks for troubleshooting
The following two checks are general best practices recommended for anyone before further troubleshooting.
1. Check log messages for performance events
Check your log messages to be sure that the Performance Monitoring SDK is capturing performance events.
Enable debug logging, as follows:
- In Xcode (minimum v13.3.1), select Product > Scheme > Edit scheme .
- Select Run from the left menu, then select the Arguments tab.
- In the Arguments Passed on Launch section, add
-FIRDebugEnabled.
Check your log messages for any error messages.
Performance Monitoring tags its log messages with
Firebase/Performanceso that you can filter your log messages.Check for the following types of logs which indicate that Performance Monitoring is logging performance events:
-
Logging trace metric: TRACE_NAME , FIREBASE_PERFORMANCE_CONSOLE_URL -
Logging network request trace: URL
-
Click on the URL to view your data in the Firebase console. It may take a few moments for the data to update in the dashboard.
If your app isn't logging performance events, review the troubleshooting tips .
2. Check the Firebase Status Dashboard
Check the Firebase Status Dashboard in case there is a known outage for Firebase or for Performance Monitoring.
Getting started with Performance Monitoring
If you're getting started with Performance Monitoring ( iOS+ | Android | Web ), the following troubleshooting tips can help with issues that involve Firebase detecting the SDK or displaying your first performance data in the Firebase console.
Firebase can detect if you've successfully added the Performance Monitoring SDK to your app when it receives event information (like app interactions) from your app. Usually within 10 minutes of starting your app, the Performance dashboard of the Firebase console displays an "SDK detected" message. Then, within 30 minutes, the dashboard displays the initial processed data.
If it's been more than 10 minutes since you added the latest version of SDK to your app, and you're still not seeing any change, check your log messages to make sure that Performance Monitoring is logging events. Try the appropriate troubleshooting steps as described below to troubleshoot a delayed SDK detection message.
If you're still developing locally, try generating more events for data collection:
Continue to develop your app using a simulator or test device.
Generate events by switching your app between background and foreground several times, interacting with your app by navigating across screens, and/or triggering network requests.
Make sure that your Firebase configuration file (
Google-Service-Info.plist) is correctly added to your app and that you haven't modified the file. Specifically, check the following:The config file name isn't appended with additional characters, like
(2).The config file is in the root of your XCode project and added to the correct targets.
The Firebase Apple App ID (
GOOGLE_APP_ID) listed in the config file is correct for your app. Find your Firebase App ID in the Your apps card of your Project settings .
If anything seems wrong with the config file in your app, try the following:
Delete the config file that you currently have in your app.
Follow these instructions to download a new config file and add it to your Apple app.
If the SDK is logging events and everything seems to be set up correctly, but you're still not seeing the SDK detection message or processed data (after 2 hours), contact Firebase Support .
Make sure that the Performance Monitoring SDK is not disabled through either of the following flags in your
Info.plistfile:-
firebase_performance_collection_enabled -
firebase_performance_collection_deactivated
-
Make sure that Performance Monitoring is not disabled at runtime ( Swift | Obj-C ).
If you can't find anything that's disabled in your app, contact Firebase Support .
Performance Monitoring processes performance event data before displaying it in the Performance dashboard .
If it's been more than 24 hours since the "SDK detected" message appeared , and you're still not seeing data, then check the Firebase Status Dashboard in case there is a known outage. If there is no outage, contact Firebase Support .
General troubleshooting
If you've successfully added the SDK and are using Performance Monitoring in your app, the following troubleshooting tips can help with general issues that involve Performance Monitoring features and tooling.
If you're not seeing log messages for performance events , try the following troubleshooting steps:
Make sure that the Performance Monitoring SDK is not disabled through either of the following flags in your
Info.plistfile:-
firebase_performance_collection_enabled -
firebase_performance_collection_deactivated
-
Make sure that Performance Monitoring is not disabled at runtime ( Swift | Obj-C ).
If you can't find anything that's disabled in your app, contact Firebase Support .
If you're missing data for screen rendering traces, try the following troubleshooting steps:
Are you seeing performance data for automatically collected traces but not for custom code traces ? Try the following troubleshooting steps:
Check the setup of custom code traces instrumented via the Trace API , especially the following:
- Names for custom code traces and custom metrics must meet the following requirements: no leading or trailing whitespace, no leading underscore (
_) character, and max length is 32 characters. - All traces must be started and stopped. Any trace that is not started, not stopped, or stopped before started will not be logged.
- Names for custom code traces and custom metrics must meet the following requirements: no leading or trailing whitespace, no leading underscore (
Check your log messages to make sure that Performance Monitoring is logging expected custom code traces.
If Performance Monitoring is logging events, but no data displays after 24 hours, contact Firebase Support .
If you're missing network request data, try the following troubleshooting steps:
Check for network library incompatibility. Performance Monitoring automatically collects metrics for network requests that use the following networking libraries:
- For Swift: URLSession and URLConnection
- For Objective-C: NSURLSession and NSURLConnection
Note that you can add custom monitoring for network requests .
Be aware of the following:
Depending on the behavior of your code and networking libraries used by your code, Performance Monitoring might only report on network requests that are completed. This means that HTTP/S connections that are left open might not be reported.
Performance Monitoring does not report on network requests with invalid
Content-Typeheaders. However, network requests without theContent-Typeheaders will still be accepted.
Learn more about how Performance Monitoring aggregates network request data under URL patterns.
You can also try out custom URL patterns !
FAQ
We replaced Top Issues with Recent Alerts as a follow-up to our recent introduction of alerts, which automatically notify you when the thresholds you set are crossed. Issues are now deprecated and replaced by alerts.
The apps selector at the top of the Performance card filters the alert entries under Recent Alerts . Only the three most recent alerts for the app(s) selected are displayed.
To learn more about alerts, see Set up alerts for performance issues .
Performance Monitoring supports alerts for metrics that exceed defined thresholds. To avoid confusion with these configurable thresholds for performance metrics, we removed the ability to configure thresholds for issues .
We replaced the Details and Metrics pages with a newly redesigned, centralized user interface (UI) to improve how you troubleshoot issues. This new troubleshooting UI offers the same core functionality that Details and Metrics offered. To learn more about troubleshooting, see View more data for a specific trace .
Performance Monitoring collects performance data from your app's user devices. If your application has many users or if the app generates a large amount of performance activity, Performance Monitoring might limit data collection to a subset of devices to reduce the number of processed events. These limits are high enough so that, even with fewer events, the metric values are still representative of your user's app experience.
To manage the volume of data that we collect, Performance Monitoring uses the following sampling options:
On-device rate limiting : To prevent a device from sending sudden bursts of traces, we limit the number of code and network request traces sent from a device to 300 events every 10 mins. This approach protects the device from looped instrumentations that can send large amounts of performance data, and it prevents a single device from skewing the performance measurements.
Dynamic sampling : Performance Monitoring collects approximately 100M events for code traces and 100M for network request traces per app across all app users. A dynamic sampling rate is fetched on devices (using Firebase Remote Config) to determine whether a random device should capture and send traces. A device that is not selected for sampling does not send any events. The dynamic sampling rate is app-specific and adjusts to ensure that the overall volume of collected data remains below the limit.
User sessions send additional, detailed data from a user's device, requiring more resources to capture and send the data. To minimize the impact of user sessions, Performance Monitoring might also restrict the number of sessions.
Server-side rate limiting : To ensure that apps don't exceed the sampling limit, Performance Monitoring might use server-side sampling to drop some events received from devices. Although this type of limiting doesn't change the effectiveness of our metrics, it may cause minor pattern shifts, including the following:
- The number of traces can differ from the number of times that a piece of code was executed.
- Traces that are closely coupled in code may each have a different number of samples.
We replaced the Issues tab with the introduction of Alerts, which automatically notifies you when the thresholds you set are exceeded. You no longer need to manually check the Firebase console to determine the status of a threshold. To learn about Alerts, see Set up alerts for performance issues .
We've redesigned the Performance Monitoring section of the Firebase console so that the Dashboard tab displays your key metrics and all your traces in one space. As part of the redesign, we removed the On device and Network pages.
The traces table at the bottom of the Dashboard tab has all the same information that the On device and Network tabs displayed, but with some added features, including the ability to sort your traces by the percentage change for a specific metric. To view all the metrics and data for a specific trace, click the trace name in the traces table.
View your traces in the following subtabs of the traces table:
- Network request traces (both out-of-the-box and custom) — Network requests subtab
- Custom code traces — Custom traces subtab
- App start, app-in-foreground, app-in-background traces — Custom traces subtab
- Screen rendering traces — Screen rendering subtab
- Page load traces — Page load subtab
For details about the traces table and viewing metrics and data, visit the console overview page ( iOS+ | Android | Web ).
Slow rendering frames and frozen frames are calculated with an assumed device refresh rate of 60Hz. If a device refresh rate is lower than 60Hz, each frame will have a slower rendering time because fewer frames are rendered per second. Slower rendering times can cause more slow or frozen frames to be reported because more frames will be rendered slower or will freeze. However, if a device refresh rate is higher than 60Hz, each frame will have a faster rendering time. This can cause fewer slow or frozen frames to be reported. This is a current limitation in the Performance Monitoring SDK.
If you have enabled the BigQuery integration for Firebase Performance Monitoring, your data will be exported to BigQuery 12 to 24 hours after the end of the day (Pacific Time).
For example, the data for April 19th will be available in BigQuery on April 20th between 12:00pm and midnight (all dates and times are Pacific Time).
Near real-time data processing and display
Firebase Performance Monitoring processes collected performance data as it comes in, which results in near real-time data display in the Firebase console. Processed data displays in the console within a few minutes of its collection, hence the term "near real-time".
To take advantage of near real-time data processing, make sure your app uses a real-time compatible SDK version .
To take advantage of near real-time data processing, you only need to make sure that your app uses a Performance Monitoring SDK version that's compatible with real-time data processing.
These are the real-time compatible SDK versions:
- iOS — v7.3.0 or later
- tvOS — v8.9.0 or later
- Android — v19.0.10 or later (or Firebase Android BoM v26.1.0 or later)
- Web — v7.14.0 or later
Note that we always recommend using the latest version of SDK, but any version listed above will enable Performance Monitoring to process your data in near real time.
These are the SDK versions compatible with real-time data processing:
- iOS — v7.3.0 or later
- tvOS — v8.9.0 or later
- Android — v19.0.10 or later (or Firebase Android BoM v26.1.0 or later)
- Web — v7.14.0 or later
Note that we always recommend using the latest version of SDK, but any version listed above will enable Performance Monitoring to process your data in near real time.
If your app doesn't use a real-time compatible SDK version, you will still see all your app's performance data in the Firebase console. However, the display of performance data will be delayed by roughly 36 hours from the time of its collection.
Yes! Regardless of which SDK version an app instance uses, you'll see performance data from all your users.
However, if you're looking at recent data (less than roughly 36 hours old), then the displayed data is from users of app instances using a real-time compatible SDK version. The non-recent data, though, includes performance data from all versions of your app.
Contacting Firebase Support
If you reach out to Firebase Support , always include your Firebase App ID. Find your Firebase App ID in the Your apps card of your Project settings .