Anwendungsleistungsanalyse: Kennzahlen, Tests und Überwachung

Informatec Digital » Ressourcen » Anwendungsleistungsanalyse: Metriken, Tests und Überwachung

Um dieses Qualitätsniveau zu erreichen, reicht es nicht aus, einfach nur „vor der Veröffentlichung ein bisschen zu testen“. Es bedarf einer Kombination aus kontinuierlichem Monitoring (APM und RUM) , gut konzipierten Performance-Tests, klaren Kennzahlen und Tools, die alles vom täglichen Gebrauch bis hin zu extremen Traffic-Spitzen simulieren können. Darüber hinaus muss dies strategisch erfolgen: Es gilt zu messen, was für das Unternehmen wirklich wichtig ist, und so viel wie möglich zu automatisieren, um nicht ständig auf Probleme reagieren zu müssen.

Anwendungsleistung: Was sie ist, warum sie wichtig ist und was wir messen

Wenn wir von Anwendungsperformance sprechen, meinen wir die Fähigkeit einer App, schnell zu reagieren, stabil zu bleiben und mit steigender Nutzerzahl oder zunehmendem Datenvolumen zu skalieren, ohne den Ressourcenverbrauch drastisch zu erhöhen oder die Benutzerfreundlichkeit zu beeinträchtigen. Dies gilt für mobile, Web- und Desktop-Anwendungen , APIs, Microservices und komplexe Unternehmenssysteme.

Der Schlüssel liegt in der systematischen Messung einer Reihe von Anwendungsleistungsmetriken (KPIs) , die es ermöglichen, zu verstehen, ob die App die technischen und geschäftlichen Ziele erreicht, und rechtzeitig zu erkennen, wenn etwas schiefgeht, bevor der Endbenutzer es bemerkt oder Alarme in der Produktion ausgelöst werden.

Zu den am häufigsten verwendeten Kennzahlen zur Bewertung der App-Performance gehören:

• CPU auslastung: wie viel Prozessorleistung die Anwendung verbraucht und ob es Spitzenwerte gibt, die auf übermäßige Berechnungen, schlecht konzipierte Schleifen oder Prozesse hinweisen, die die Antwort blockieren.
• Speichernutzung: Speicherauslastung, Auftreten von Speicherlecks, Seitenfehlern oder Hyperpaging, die darauf hindeuten, dass das System mehr Zeit mit dem Verschieben von Daten als mit der Ausführung der Geschäftslogik verbringt.
• Anfragen pro Minute und Bytes pro AnfrageDies zeigt, wie viele Anfragen die App oder API verarbeitet und wie viele Daten pro Anfrage verarbeitet werden. So lässt sich die Skalierbarkeit des Backends beurteilen und feststellen, ob das Datenvolumen pro Aufruf angemessen ist.
• Latenz und Reaktionszeit: wie lange die Anwendung für eine Antwort benötigt, von dem Zeitpunkt, an dem der Benutzer eine Aktion ausführt oder der Client eine Anfrage sendet, bis er eine brauchbare Antwort erhält.
• Betriebszeit und VerfügbarkeitProzentsatz der Zeit, in der der Dienst verfügbar und betriebsbereit ist, üblicherweise überwacht durch wiederkehrende Pings oder synthetische Prüfungen.
• Fehlerrate: Anteil der Anfragen, die mit einem Fehler enden (HTTP 4xx/5xx-Codes, unbehandelte Ausnahmen, Funktionsausfälle).
• Apdex-Wert und Kundenzufriedenheit: Index, der in einem einzigen Wert den Prozentsatz der zufriedenen, toleranten oder frustrierten Nutzer auf Basis der Reaktionszeiten zusammenfasst.
• Leistung der Müllabfuhr (GC)Auf Plattformen mit automatischer Speicherverwaltung (Java, .NET, Android) wird untersucht, wie viel Zeit für die Garbage Collection aufgewendet wird, wie viele Pausen dadurch entstehen und wie sich dies auf die CPU-Auslastung und die Flüssigkeit auswirkt.
• Durchsatzrate oder Leistung: Anzahl der Transaktionen oder Anfragen, die pro Zeiteinheit verarbeitet werden; von entscheidender Bedeutung in Systemen mit hoher Parallelität.

Ziel der Erfassung dieser Kennzahlen ist nicht das Sammeln von Diagrammen, sondern das Verstehen des tatsächlichen Zustands der Anwendung , das Antizipieren von Engpässen, das Priorisieren von Verbesserungen und das Aufzeigen anhand von Daten, dass Optimierungen sowohl die Benutzererfahrung als auch die Geschäftsergebnisse beeinflussen.

APM, RUM und Echtzeit-Leistungsüberwachung

In modernen Umgebungen mit verteilten Architekturen, Containern, Hybrid-Clouds und Microservices ist es praktisch unmöglich, die Performance ohne ein gutes Application Performance Monitoring (APM)-Tool in Kombination mit Real User Monitoring (RUM)-Techniken und zunehmend fortschrittlichen Observability-Komponenten zu kontrollieren.

APM/RUM-Lösungen (wie beispielsweise die von Elastic, Instana, Applications Manager, Turbonomic in Kombination mit APM usw.) bieten eine durchgängige Transparenz darüber, was in Ihrer Anwendung geschieht: Antwortzeiten, verteilte Traces, Datenbankabfragen, externe Aufrufe, Fehler und Anomalien, integriert mit Infrastrukturmetriken.

Real User Monitoring (RUM) erfasst, was echte Nutzer erleben: Ladezeiten des Bildschirms, Einfrieren der Benutzeroberfläche, Browser- oder App-Fehler und wahrgenommene Latenzzeiten in verschiedenen Regionen und auf unterschiedlichen Geräten. Dies ergänzt synthetische Benchmarks und Labortests, die zwar unerlässlich sind, aber reale Anwendungsdaten nicht ersetzen können.

Moderne APM-Plattformen bieten hingegen Funktionen wie:

• Echtzeitüberwachung Wichtigste KPIs: Verfügbarkeit, Apdex, Fehlerrate, Übertragungsgeschwindigkeit Ressourcenverbrauch.
• Verteilte Spuren Eine Transaktion über mehrere Microservices, Warteschlangen, Datenbanken und externe Dienste hinweg zu verfolgen und das langsamste Glied zu identifizieren.
• Abhängigkeitskarten Automatisierte Tools, die die Zusammenhänge zwischen Diensten, Datenbanken, Warteschlangen und Frontends aufzeigen und so die Ermittlung der Ursache eines Fehlers erleichtern.
• Code- und Thread-Profiling um Methoden, SQL-Abfragen oder Codeabschnitte zu finden, die zu viel CPU verbrauchen oder den Schnittstellenthread blockieren.
• Intelligente Warnmeldungen und AIOps die maschinelles Lernen und Zeitreihenanalyse kombinieren, um Anomalien zu erkennen, Fehlalarme zu reduzieren und kritische Ereignisse zu priorisieren.

Durch die Kombination von APM, RUM und synthetischem Monitoring erhalten Sie einen umfassenden Überblick über die Performance : Was der Benutzer sieht, was die Anwendung intern tut und wie die zugrunde liegende Infrastruktur reagiert. Dies ermöglicht DevOps- und ITOps-Teams, schnell auf Vorfälle zu reagieren und diese idealerweise sogar zu verhindern.

Wichtige Leistungskennzahlen in mobilen und Webanwendungen

Bei mobilen und Webanwendungen sind bestimmte Leistungskennzahlen besonders sensibel, da sie die Nutzerwahrnehmung und den Produkterfolg direkt beeinflussen. Die genaue Überwachung dieser Indikatoren entscheidet darüber, ob eine App die Nutzer begeistert oder nach dem zweiten Mal deinstalliert wird.

Ein kritischer Punkt bei mobilen Anwendungen ist die Startverzögerung , also die Zeitspanne zwischen dem Antippen des App-Symbols (oder einer Benachrichtigung) und dem Erscheinen relevanter Daten auf dem Bildschirm. Man kann verschiedene Arten unterscheiden:

• KaltstartDie App befindet sich nicht im Speicher; das System muss einen Prozess erstellen, Code laden, Bibliotheken initialisieren und den ersten Bildschirm anzeigen.
• Halbwarmer StartDer Prozess existiert, aber die Aktivität wird neu erstellt oder in einen vorherigen Zustand zurückversetzt.
• HeißstartSie müssen lediglich Ihre Ansicht wiederherstellen oder Ihre Aktivitäten fortsetzen, was nur sehr wenig zusätzlichen Aufwand bedeutet.

Als Richtwert wird dringend empfohlen, Kaltstartzeiten unter 500 ms anzustreben , da dies die Latenzwerte p95 und p99 (höchste Perzentile) nahe an den Median bringt. Wenn manche Nutzer mehrere Sekunden warten, während andere die App in einer halben Sekunde öffnen, stimmt etwas nicht.

Ein weiterer kritischer Aspekt ist das Scrollen und das Einfrieren der Benutzeroberfläche . Auf sich bewegenden Bildschirmen (Feeds, Listen, Galerien) erwarten Nutzer flüssige Darstellung. Wenn das System die Bilder nicht mit der Bildwiederholfrequenz des Geräts (60 Hz, 90 Hz oder sogar 120 Hz) generieren kann, kommt es zu Rucklern und Stottern. Diese Ruckler treten auf, wenn die App länger als die Dauer eines Einzelbildes (z. B. mehr als 16,7 ms bei 60 FPS) zum Rendern von Inhalten benötigt.

Neben der flüssigen Darstellung müssen auch die Bildschirmübergänge sorgfältig überwacht werden . Das Wechseln von Tabs, das Öffnen von Details aus einer Liste oder das Anzeigen eines Dialogfelds sollte nahezu verzögerungsfrei erfolgen, mit ruckelfreien Animationen und ohne Flackern oder längere leere Bildschirme.

Im Hintergrund, aber ebenso wichtig, spielen Akkuverbrauch und Energieeffizienz eine Rolle. Unnötige Prozesse, massive Speicherbelegungen und intensive CPU-Auslastung verkürzen die Akkulaufzeit und führen zu Überhitzung des Geräts. Die Android Runtime (ART) hat die Effizienz zwar verbessert, aber wenn die interne Schleife Ihrer App Tausende neuer Objekte pro Sekunde erzeugt, werden die Kosten für Speicherbelegung und Garbage Collection spürbar sein.

Arbeitsablauf zur Identifizierung und Behebung von Leistungsproblemen

Um nicht auf Glück angewiesen zu sein, ist es sehr hilfreich, einen systematischen Workflow für die Leistungsanalyse zu etablieren , der detaillierte manuelle Tests im Labor mit der Erfassung aggregierter Kennzahlen im Produktivbetrieb kombiniert. Ein typischer Ansatz umfasst folgende Schritte:

Zunächst müssen die kritischen Nutzerabläufe identifiziert werden , also jene Abläufe, die den größten Einfluss auf das Nutzererlebnis und das Geschäft haben:

• Häufige App-Starts (Symbol, Benachrichtigungen, Deep Links).
• Bildschirme mit kontinuierlichem Scrollen über große Datenmengen.
• Wichtige Übergänge zwischen Ansichten und Aktivitäten.
• Längere Vorgänge wie z. B. Surfen, Audio-/Videowiedergabe, Bezahlvorgänge usw.

Sobald sie definiert sind, werden sie instrumentiert und analysiert. Dabei kommen Profiling- und Tracing-Tools wie Perfetto oder Systrace zum Einsatz, um mit Mikrosekundenpräzision zu sehen, was das Gerät tut, Speicherprofilgeneratoren, um Lecks und Allokations-Hotspots zu erkennen, oder Tools wie Simpleperf, um herauszufinden, welche Funktionen die meiste CPU-Leistung verbrauchen.

Es ist wichtig zu betonen, dass eine detaillierte Leistungsanalyse das Debuggen einzelner Durchläufe dieser Routen erfordert, wobei die Probleme kontrolliert reproduziert werden müssen. Die Analyse aggregierter Daten ist zwar wertvoll, um Muster und Regressionen zu erkennen, ersetzt aber nicht die eingehende Analyse spezifischer Ablaufverfolgungen.

Parallel dazu empfiehlt es sich, in automatisierten Testumgebungen und in der Produktion eine kontinuierliche Metrikenerfassung einzurichten : Startzeiten, Blockierungsraten, Frame-Metriken (z. B. über FrameMetricsAggregator unter Android), Play Console-Feldmetriken, Scrolling-Makro-Benchmarks usw. Mithilfe dieser Metriken lässt sich die tatsächliche Variabilität zwischen Geräten, Betriebssystemversionen und Netzwerkbedingungen erkennen.

App- und Systemeinstellungen für genaue Messung

Eine der häufigsten Fehlerquellen ist die Leistungsmessung unter unrealistischen Bedingungen. Damit die Ergebnisse aussagekräftig sind, müssen sowohl die APK als auch das System sorgfältig konfiguriert werden, um sicherzustellen, dass die Testumgebung der Produktionsumgebung ähnelt und gleichzeitig Störfaktoren minimiert werden.

Auf App-Seite ist es unerlässlich, keine Messungen mit Debug-Builds durchzuführen . Debug-Varianten fügen Prüfungen, Protokolle und Flags hinzu, die die Laufzeitumgebung erheblich verändern. Ab Android 10 können Sie das Attribut `profileable android:shell="true"` im Manifest verwenden, um das Profiling mit Release-Builds zu aktivieren und so ein nahezu realistisches Verhalten zu gewährleisten.

Es empfiehlt sich außerdem, Code-Reduzierung (z. B. mit ProGuard, R8) einzusetzen , da Code-Größe und -Organisation die Performance spürbar beeinflussen. Beachten Sie jedoch die Regeln: Manche Konfigurationen können wichtige Messpunkte entfernen, die für die Testversion angepasst werden müssen.

Bezüglich der Kompilierung empfiehlt es sich, die Anwendung in einen definierten Zustand zu versetzen, typischerweise in den Geschwindigkeitsmodus oder den Geschwindigkeitsprofilmodus . Beide reduzieren die Menge des von DeX interpretierten Codes und den Bedarf an JIT-Kompilierung im Hintergrund, was die Ergebnisse stabilisiert. Der Geschwindigkeitsprofilmodus versucht, das Verhalten in realen Produktionsumgebungen besser nachzubilden, erfordert jedoch ein „Aufwärmen“ der Anwendung und die Verwaltung von Profilen (z. B. Basisprofile).

Aus Systemperspektive ist es üblich, das Gerät zu kalibrieren , wenn sehr hochpräzise Messungen (Mikro-Benchmarks) erforderlich sind : Man führt A/B-Tests auf demselben Terminal und mit derselben Betriebssystemversion durch, legt die CPU-/GPU-Frequenzen fest und deaktiviert kleine Kerne oder die thermische Begrenzung mithilfe von Skripten wie lockClocks usw. Dies bildet zwar nicht die reale Welt ab, reduziert aber das Rauschen in sehr spezifischen Szenarien.

Für Messungen, die näher an der Benutzererfahrung liegen (Startvorgang, Batterieverbrauch, Abstürze der Benutzeroberfläche), empfiehlt es sich, Testframeworks wie Macrobenchmark zu verwenden , die viele dieser Schritte automatisieren und subtile, aber kritische Konfigurationsfehler vermeiden.

Typische Muster von Leistungsproblemen

Bei fast allen Anwendungen, die einer gründlichen Analyse unterzogen werden, treten bestimmte wiederkehrende Problemmuster auf , über die es sich zu wissen lohnt, da es in der Regel recht klare Lösungen gibt, wenn sie rechtzeitig erkannt werden.

Eines der häufigsten Probleme ist ein langsamer Start aufgrund einer sogenannten „Jumper Activity“ . Dies tritt auf, wenn nach einem Startsignal (Symbol, Benachrichtigung, Deep Link) eine Zwischenaktivität gestartet wird, die keine Frames zeichnet, bevor die eigentliche Aktivität beginnt. In den Protokollen erscheint dies als zwei aufeinanderfolgende `activityStart`-Ereignisse ohne visuelle Aktionen dazwischen. Dieser „Sprung“ verlängert die Startzeit unnötig. Die Lösung besteht üblicherweise darin, die Initialisierung in eine wiederverwendbare Komponente auszulagern oder sie direkt in die Hauptaktivität zu integrieren.

Ein weiteres klassisches Beispiel sind unnötige Speicherzuweisungen, die die automatische Speicherbereinigung auslösen . Zeigen Systrace oder Speicherprofile an, dass während einer langlaufenden Operation alle paar Sekunden eine automatische Speicherbereinigung stattfindet, ist es sehr wahrscheinlich, dass Code innerhalb intensiver Schleifen wiederholt und ständig Objekte allokiert. Die Lösung besteht nicht darin, jedes neue Objekt zu entfernen, sondern die Speicherengpässe zu beheben, indem Strukturen wiederverwendet oder gegebenenfalls Pooling-Muster angewendet werden.

Auch in der Grafikpipeline treten häufig Frames mit Blockierungen auf . In einem fehlerfreien Ablaufdiagramm erfolgen Aufrufe von `Choreographer.doFrame()` in regelmäßigen Abständen (z. B. alle 16,7 ms). Durch Vergrößern von Bereichen mit diesem Rhythmus lassen sich ressourcenintensive Ansichten, übermäßig komplexe Layouts, auf dem UI-Thread ausgeführte E/A-Operationen oder falsch konfigurierte RecyclerViews aufdecken.

RecyclerView ist genau die Ursache zahlreicher Probleme: Das gesamte Dataset wird mit `notifyDataSetChanged()` ungültig gemacht, obwohl sich nur wenige Elemente geändert haben; die wiederverwendeten View-Pools in verschachtelten RecyclerViews werden nicht korrekt konfiguriert; und es werden nicht genügend Daten vorab geladen , wenn das Ende der Liste erreicht ist. All dies führt zu aufwändigem Rendering, ruckartigen Scrollvorgängen und spürbaren Wartezeiten für den Benutzer.

Leistungstests: Arten, Schritte und bewährte Vorgehensweisen

Neben der Produktionsüberwachung benötigt jede ernsthafte Strategie einen soliden Plan für Anwendungsleistungstests in kontrollierten Umgebungen. Diese Tests ermöglichen es Ihnen, Kapazität, Stabilität und Skalierbarkeit zu validieren, bevor Sie Benutzer mit Änderungen oder neuen Versionen konfrontieren.

Es gibt verschiedene Arten von Tests, von denen jede ihr spezifisches Ziel verfolgt:

• BelastungstestsSie bewerten das Verhalten der App unter einer vorhergesagten Last von Benutzern oder Transaktionen und messen Antwortzeiten, Durchsatz und Ressourcenverbrauch, um Engpässe vor der Bereitstellung zu erkennen.
• StresstestsSie testen das System bis an seine normalen Grenzen, um herauszufinden, wie weit es belastet werden kann, wo es versagt und wie es sich erholt. Sie sind entscheidend für die Kapazitätsplanung und die Bewältigung von Spitzenlasten wie am Black Friday.
• Ausdauer-/EinweichtestsSie halten die Last über Stunden oder Tage aufrecht, um Probleme wie langsamen Verschleiß, Speicherlecks oder Ressourcenerschöpfung aufzudecken.
• SpitzentestsSie simulieren plötzliche und wiederholte Laststeigerungen (z. B. Kampagnen, Produkteinführungen, Live-Übertragungen), um zu überprüfen, ob die Anwendung und die Infrastruktur plötzliche Änderungen bewältigen können.
• VolumentestsSie analysieren, wie sich die App verhält, wenn die Anzahl der Nutzer deutlich ansteigt. Datenmenge (Datenbankgröße, Dateien, Nachrichten), Validierung von Antwortzeiten, Speichersicherheit und Datenverlust.
• SkalierbarkeitstestsSie prüfen, wie die Anwendung reagiert, wenn die Last schrittweise erhöht wird, und ob eine horizontale oder vertikale Skalierung die erwartete Leistungsverbesserung bewirkt.

Der typische Prozess für Leistungstests umfasst mehrere Phasen. Zunächst erfolgt eine Anforderungsanalyse : Dabei wird ermittelt, welche Antwortzeiten, Durchsatzraten, Verfügbarkeitsgrade und Fehlergrenzen für das Unternehmen akzeptabel sind. Anschließend folgt eine Planungs- und Strategiephase, in der der Umfang der Tests, die Testumgebung, die Tools und die zu überwachenden Metriken definiert werden.

Anschließend werden Testfälle entworfen , die verschiedene Lastszenarien, Netzwerkbedingungen und Datenmengen abdecken; die Testumgebung wird konfiguriert (Hardware, Software, Netzwerk, Lasteinspeisungs- und Überwachungstools); und die Tests werden durchgeführt, wobei sorgfältig Leistungsdaten erfasst werden.

Die entscheidende Phase ist die Überwachung und Analyse : Hierbei werden Antwortzeiten mit der CPU-Auslastung, Netzwerklatenzen mit Fehlerraten, Traffic-Spitzen mit Datenbanküberlastungen usw. korreliert. Nachdem die Ergebnisse in übersichtlichen Berichten für die Stakeholder dokumentiert wurden, folgt die Optimierung und das erneute Testen : Code, Konfigurationen oder Ressourcen werden angepasst und die Tests wiederholt, bis die Verbesserungen bestätigt sind.

Werkzeuge und Frameworks für Leistungstests

Um all dies in die Praxis umzusetzen, ist es notwendig, auf spezifische Performance-Test-Tools zurückzugreifen – sowohl Open-Source- als auch kommerzielle –, die Automatisierung, Lastgenerierung, Überwachung und Analyse abdecken. Einige relevante Kategorien sind:

• Open-Source-ToolsProjekte wie Apache JMeter, Gatling, k6, Locust, Taurus, nGrinder oder Unit- und Funktionstest-Frameworks (JUnit, XCTest, Appium), die um Performance-Szenarien erweitert wurden, ermöglichen den Aufbau sehr leistungsfähiger Test-Suites mit geringen Lizenzkosten.
• Kommerzielle Lasttests und APM-ToolsLösungen wie WebLOAD, LoadNinja, NeoLoad, LoadView, BlazeMeter, Rational Performance Tester, Silk Performer, Eggplant, CloudTest oder Parasoft bieten integrierte Umgebungen mit cloudbasierter Lastgenerierung, fortschrittlichem Reporting und professionellem Support.
• Spezialisierte und beobachtbare LösungenProdukte wie Applications Manager, Instana, Dynatrace, IBM Turbonomic oder Netzwerküberwachungsplattformen wie SolarWinds, die sich auf kontinuierliche Überwachung, Anomalieerkennung und Korrelation zwischen Anwendungsleistung, Infrastruktur und Benutzererfahrung konzentrieren.
• Plattformspezifische WerkzeugeIm Fall von Android ermöglichen beispielsweise Tools wie Perfetto, System Tracing, der Android Studio Memory Profiler, Simpleperf, Systrace oder die Frame-Metriken der Play Console eine sehr detaillierte Analyse des Systemverhaltens.

Bei der Wahl zwischen den beiden Optionen empfiehlt es sich, Faktoren wie Benutzerfreundlichkeit, Unterstützung von Protokollen und Technologien, Skalierbarkeit, Integration mit CI/CD , das Lizenzmodell, Erweiterbarkeit und die Qualität des Supports (Community- oder kommerzieller Support) zu berücksichtigen. Es ist auch nicht unüblich, mehrere zu kombinieren: eine für die Lastgenerierung, eine weitere für APM und eine dritte für die Überwachung der Infrastruktur.

Kurz gesagt, die Analyse und Überwachung der Anwendungsleistung erfordert eine Kombination aus gut gewählten Metriken, geeigneten Werkzeugen und Disziplin bei den Testprozessen, aber das Ergebnis entschädigt dafür mehr als genug: schnellere, stabilere und effizientere Anwendungen , zufriedenere Benutzer, weniger Produktionsvorfälle und natürlich ein direkter positiver Einfluss auf den Markenruf und den Umsatz.

In Verbindung stehender Artikel:

Entdecken Sie Qt Creator IDE: Die leistungsstärkste Umgebung zum Erstellen plattformübergreifender Apps