Sparen mit Application Performance Engineering
Sparen mit Application Performance Engineering
So können beispielsweise Probleme, die in der Produktion unter Last auftreten und sich von den Entwicklern kaum oder nur mit extremem Aufwand reproduzieren lassen, anhand der Einzeltraces wesentlich schneller punktgenau lokalisiert werden. Der Austausch und die Analyse von mehreren GByte grossen Logfiles entfällt, das «Fingerpointing» zwischen Betrieb und Entwicklern sinkt und die Mean Time To Repair wird drastisch verkürzt.
Die Architektur der zweiten Generation lässt dieses Wunschszenario zur Realität werden: Die Daten können ebenso vom Betriebsteam (Service- und Ressourcen-Monitoring) als auch vom QA-Team (Test und Triage) oder den Architekten/Entwicklern (Diagnose und Profiling) verwendet werden. Jeder Beteiligte erhält die für seine Aufgabe nützlichste Abstraktionsebene. Durch die Einzeltraces liegen den Entwicklern schlussendlich genügend Informationen vor, die ihnen eine exakte Problemlokalisierung ermöglichen, ohne dass sie die Problemfälle reproduzieren müssen.
Integration in den Application Lifecycle
Zuletzt muss erkannt werden, dass auch die Konfiguration des Diagnose-Systems zwingend in den Application Lifecycle eingebettet werden muss.
Parallel zum eigentlichen Softwaresystem wird die Monitoring/Diagnose/Analyse-Konfiguration schrittweise vorbereitet, definiert, getestet und dann in die Produktionsumgebung deployed. Die Monitoring/Diagnose/Analyse-Ergebnisse jeder Phase fliessen zurück in vorhergehenden Phasen. Natürlich verursacht die Verwendung verschiedener Werkzeuge und Methoden (Profiling, Diagnose, Logging, Monitoring) Medienbrüche im Kommunikationszyklus und beeinträchtigt damit die effiziente Datenweitergabe, Datenauswertung und somit die Problemlösung. Ein übergreifender Ansatz und ein zentraler Konfigurationsmechanismus für sämtliche beteiligten JVMs oder CLRs ist daher unerlässlich.
Parallel zum eigentlichen Softwaresystem wird die Monitoring/Diagnose/Analyse-Konfiguration schrittweise vorbereitet, definiert, getestet und dann in die Produktionsumgebung deployed. Die Monitoring/Diagnose/Analyse-Ergebnisse jeder Phase fliessen zurück in vorhergehenden Phasen. Natürlich verursacht die Verwendung verschiedener Werkzeuge und Methoden (Profiling, Diagnose, Logging, Monitoring) Medienbrüche im Kommunikationszyklus und beeinträchtigt damit die effiziente Datenweitergabe, Datenauswertung und somit die Problemlösung. Ein übergreifender Ansatz und ein zentraler Konfigurationsmechanismus für sämtliche beteiligten JVMs oder CLRs ist daher unerlässlich.
Fazit
Praxisorientiertes und kostensparendes A-pplication Performance Engineering und Management bedingt die frühzeitige Erkennung von Architektur- und Performance-Problemen, einen effizienten Austausch der Diagnosedaten, schnelle Fehlerlokation und eine zentrale, in mehreren Umgebungen verwendbare Konfiguration des Monitoring/Diagnose-Systems. Alles zusammen ergibt in der Entwicklung und im Betrieb komplexer Software-Systeme ein markantes Sparpotenzial bei Personal-, Hardware- und Software-Ressourcen.
Begriffserklärung
Diagnosewerkzeuge der zweiten Generation
Tools, die dieser Bezeichnung gerecht werden, vereinen Profiling-, Tracing-, Diagnose- und -Monitoring-Funktionen und bieten damit erstmals allen Stakeholdern des Application Lifecycles eine gemeinsame Sprache und ein gemeinsames Kommunikationsmittel. Ihre Architektur ermöglicht ein laufendes Mitverfolgen, Aufzeichnen und Auswerten von Benutzertransaktionen, ohne das überwachte oder diagnostizierte System zu überlasten.
Thomas Mahringer