Whitepaper: Die kosteneffiziente Performance Engineering Lösung. Sicherstellung hoher Anwendungsperformance zu niedrigen Kosten

Transkript

1 Whitepaper: Die kosteneffiziente Performance Engineering Lösung Sicherstellung hoher Anwendungsperformance zu niedrigen Kosten

2 Inhaltsverzeichnis Kosteneffiziente Überwachung der Anwendungsperformance 5 Sicherstellung der Anwendungsperformance ist nicht teuer 6 Erhältliche Werkzeuge für das Application Performance Engineering 6 Warum nicht einfach Werkzeuge zur Performancemessung in den Anwendungscode einbinden? 7 Wichtige Hinweise für die Überwachung einer Anwendung 8 inspectit hilft Ihnen dabei Ihre Performanceprobleme zu lösen 11 Fact Sheet inspectit 14 Seite 2

3 Kosteneffiziente Überwachung der Anwendungsperformance Ende gut, alles gut? Nachdem zwei Jahre lang an einer verbesserten Version der betrieblichen Anwendung entwickelt wurde, die auf der neuesten Technologie basierte und die gesammelten Anforderungen der Mitarbeiter mit berücksichtigte, war der Entwicklungsleiter stolz, verkünden zu können: Die Anwendung wurde erfolgreich ausgerollt und wir gehen ab sofort live. Wir haben es geschafft, Leute, den schwierigen Teil haben wir hinter uns. Nach monatelangen Überstunden, die erforderlich waren, um den Endtermin zu halten, war das Entwicklungsteam erleichtert, dass der schwierige Teil erledigt zu sein schien. Ab dem folgenden Tag würden die Mitarbeiter das neue System verwenden und von den Zusatzfunktionen und dem verbesserten Durchsatz profitieren. Jede Funktionalität war ausgiebig getestet worden, also was kann schon schiefgehen? Am nächsten Morgen, nachdem der erste Server aufgrund von Speicherproblemen abgestürzt war und eine Vielzahl von den Mitarbeitern über die schlechten Antwortzeiten und die lange Zeit, die jeder einzelne Geschäftsvorfall dauerte, beklagten, wurde dem Entwicklungsteam klar, dass der schwierige Teil tatsächlich erst begonnen hatte. Bis zur Mittagszeit stürzten drei weitere Server ab und die Flut der Beschwerden nahm stetig zu. Der Druck wurde von Stunde zu Stunde größer und das Management beschwerte sich, dass keiner der Mitarbeiter wie erwartet arbeiten konnte. Von allen Beteiligten wurden wilde Behauptungen geäußert und jeder zeigte mit dem Finger auf die anderen Abteilungen. Nach zwei Tagen, an denen an dem System nicht gearbeitet werden konnte, entschloss sich das Management auf das alte System zurückzuwechseln. Eingehende Performancetests der entwickelten Lösung zeigten, dass die geplante Architektur nie und nimmer die Anzahl Anfragen bewältigen konnte, die von den Benutzern gestellt wurden. Die gesamte Architektur sowie ein Großteil des Programmcodes hätten überarbeitet, neu implementiert und angepasst werden müssen. Es verging ein Jahr bis die Software neu ausgerollt wurde - diesmal war sie eingehend auf Stabilität und Performance getestet worden. Bis auf ein paar kleinere Migrationsprobleme lief das System reibungslos und die Mitarbeiter konnten von der neuen Funktionalität und der verbesserten Performance profitieren. Performance und Stabilität Sie können von Glück reden, wenn Sie nie ein Szenario wie eingangs beschrieben erlebt haben. Aber aller Wahrscheinlichkeit nach ist das der Fall. Anwendungsperformance und -stabilität wird mehr und mehr zum maßgeblichen Faktor für das Scheitern eines Software-Projekts. Für Programmfehler sowie für Performance- und Stabilitätsprobleme gilt gleichermaßen: Je früher das Problem erkannt wird, desto billiger wird die Behebung (bezogen auf Zeit, Komplexität und Geld). Unzufriedenstellende Performance bringt oft eine Überarbeitung und Änderung der gesamten Architektur mit sich, was zur Folge hat, dass ganze Komponenten neu geschrieben und optimiert werden müssen. Je später im Entwicklungsprozess Performanceprobleme entdeckt werden, desto stärker sind die Auswirkungen. Diese sind oft um ein Vielfaches höher als bei Programmierfehlern. Noch komplizierter wird die Angelegenheit, da die Lösung von Performanceproblemen mehr Softwarekomponenten betrifft als bei üblichen Programmierfehlern. Software ohne angemessene Prozesse für das Performancemanagement zu entwickeln ist hochriskant. Es könnte zwar funktionieren, aber - was wahrscheinlicher ist - tut es das nicht. In der letzten Zeit wurde Application Performance Engineering zunehmend wichtiger. In vielen Projekten wird nach wie vor keine geeignete Umgebung zur frühzeitigen Erkennung von Problemen in der Anwendungsperformance aufgebaut. Es wird keine geeignete Systemumgebung für die Durchführung von Auslastungstests eingerichtet und die Implementierung von Unterstützungswerkzeugen, die Informationen über die Anwendung liefern, erfolgt erst während der Auslastungstests oder der Produktion. Tritt ein Performanceproblem auf hat dies Seite 3

4 zur Folge, dass das Finden und Lösen des Problems erst möglich ist, sobald die gesamte Unterstützungsumgebung aufgesetzt wurde. Während unserer Beratungsaufträge treffen wir auf eine Reihe von Entwicklern, die verzweifelt auf der Suche nach Werkzeugunterstützung sind um ihre Komponenten auf Performance zu testen, ohne dass zuviel Overhead dabei generiert wird. Oft werden die Wünsche nach Performancewerkzeugen oder sogar nach Performancetests vom Management wegen der erwarteten hohen Kosten abgewiesen. Nun können Manager und Entwickler erleichtert aufseufzen. inspectit von NovaTec wird ihre Probleme für kleines Geld lösen. Sicherstellung der Anwendungsperformance ist nicht teuer Häufig werden die hohen Kosten als Grund angeführt, warum keine Werkzeuge zur Sicherstellung der Performance eingesetzt werden. Während der Projektplanung werden die Aktivitäten zum Performance-Engineering oft vergessen oder kurz vor dem Rollout des Produktionssystems - wenige Tage vor Livegang - kurzfristig verschoben. Oft reicht die Zeit vor dem Abgabetermin nicht mehr aus, um überhaupt Performancetests auszuführen. Tatsächlich führt die Sicherstellung der Anwendungsperformance auf lange Sicht zu signifikanten Einsparungen. Die Funktionstests sind wie das Application Performance Engineering vollkommen risikogesteuert. Tatsächlich werden Funktionstests nur aus dem einzigen Grund ausgeführt, weil die Kosten (in Bezug auf Zeit, Geld und Qualität) höher sind, wenn diese Probleme erst in der Produktion beim Kunden auftreten. Das Budget für Funktionstests wird direkt aus dem Risiko und den Auswirkungen von Funktionsproblemen abgeleitet. Das gleiche gilt für Performanceprobleme. Es ist naiv zu denken, dass komplizierte Anwendungen irgendwie automatisch hohe Performance leisten. Wenn man das Risiko und die Auswirkungen abwägt und das geringere Risiko von Performanceproblemen bei der Integration von Performance- Engineering mitberücksichtigt, kann das Budget für diese Tätigkeiten leicht freigegeben werden. Performance-Engineering ist deshalb keineswegs teuer, sondern es handelt sich tatsächlich um einen billigeren und sichereren Ansatz, da es Ihnen hilft, das Risiko von Performanceproblemen und damit das Risiko von noch höheren Kosten (mit und bis zum vorzeitigen Abbruch des Projekts!) zu reduzieren. Es gibt nicht die Performance-Engineering-Lösung und nicht für jedes Projekt ist ein hoch standardisierter Performance-Engineering-Prozess notwendig. Oft wird Performance- Engineering mit Performance Testing verwechselt. Performance-Engineering ist ein Prozess, der gleichzeitig mit dem Projektstart beginnt, der den Entwicklungsprozess der Software begleitet und den gesamten Software-Lifecycle unterstützt. Performance-Tests sind ein Schritt innerhalb des Performance Engineering, in welchem die tatsächlichen Performance-Tests ausgeführt werden. Es ist von unschätzbarem Wert, wenn bei der Definition von Projektzielen auch Performanceziele definiert werden. Die hierdurch gefundenen Informationen (Anzahl der Benutzer auf dem System, Verteilung der Last, Pläne zur Vergrößerung des Systems nach dem Rollout, detaillierte Informationen darüber, wie lange jeder wichtige Use Case dauern kann) ist eine große Hilfe bei der Definition der Softwarearchitektur und während der Implementierung. Anhand dieser Informationen können Tests aufgesetzt werden, die sicherstellen, dass die Performance-Ziele erreicht werden können. Für diese Prüfung sind Werkzeuge erforderlich. Erhältliche Werkzeuge für das Application Performance Engineering Seit einigen Jahren sind geeignete kosteneffiziente Alternativen zu teuren Auslastungsgenerierungswerkzeugen verfügbar. Projekte, die die - zweifellos unübertroffene - Funktionalität der Marktführer nicht benötigen, können immer noch kostenlose Open-Source- Werkzeuge wie JMeter oder Grinder für Auslastungstests verwenden. Aber das Generieren von Auslastung auf der Applikation ist nur der erste Schritt. Die Identifikation der Ursache für ein Performanceproblem und dessen anschließende Optimierung bzw. Beseitigung kann ohne eine werkzeuggestützte Analysemöglichkeit nicht effektiv und effizient stattfinden. Das bedeutet Auslastungstests ohne die Überwachung der Anwendungen ermöglichen keinen Einblick in die Anwendung und sollten nur als notwendiger erster Schritt für eine tiefer gehende Analyse betrachtet werden. Seite 4

5 Natürlich wissen Sie, dass Sie ihr Ziel nicht erreichen werden, Sie können aber über den Grund nur spekulieren. Normalerweise erleben wir an diesem Punkt Vermutungen. Es könnte dieses Datenbankstatement sein oder schlimmer noch Abteilungen oder Teams fangen an mit dem Finger aufeinander zu zeigen: Unsere Komponente läuft hervorragend, aber die Komponente X ist immer so langsam. Die Integration einer Überwachung innerhalb der Anwendung erlaubt es dem Entwickler zu überprüfen, warum die Anwendung langsamer wird. Er kann gezielt den Problembereich finden und weiß welcher Teil der Anwendung nachgebessert und gegebenenfalls optimiert werden muss. Bis jetzt waren wirtschaftliche Anwendungsüberwachungslösungen nicht auf dem Markt erhältlich. Also musste sich das Projektteam entscheiden, ob es eins der bekannten Werkzeuge einer der Marktführer benutzt oder eigene Überwachungslogik innerhalb des Programmcodes implementiert und die Protokolldateien für die Fehlersuche verwendet. Leider haben die Projekte oft einen dritten Weg gewählt und überhaupt keine Performance Sicherheitsprozesse implementiert. Die Performance Überwachungswerkzeuge, die derzeit erhältlich sind, können in zwei Kategorien unterteilt werden: Eigenentwicklungen und Standard-Performancelösungen mit überschüssiger Funktionalität Warum nicht einfach Werkzeuge zur Performancemessung in den Anwendungscode einbinden? Die Antwort ist einfach: Flexibilität und Wartbarkeit. Wenn Sie versuchen Ihre Anwendung auf Performance zu prüfen, können Sie nicht so flexibel sein wie Sie möchten. Je mehr Messinstrumente Sie in Ihrer Software integrieren, desto weniger Durchsatz wird die Software erreichen. Das liegt daran, dass das Sammeln der Überwachungsinformationen Zeit kostet. Tatsächlich kann das Einbinden von zuviel Überwachung zu einer Situation führen, in welcher die Anwendungsperformance so stark reduziert ist, dass die Überwachung nicht die genauen Performancedaten liefert. Performanceprobleme können überall in der gesamten Softwarelösung auftreten: In eigenen Komponenten, in Programmbibliotheken anderer Hersteller, innerhalb des verwendeten Applikationsservers, in Datenbankabfragen, im Betriebssystem usw. Wenn Sie Zeitmessungen nur innerhalb ihres eigenen Programmcodes einbinden, werden deshalb nur einige dieser möglichen Bereiche abgedeckt. Um Performanceprobleme zu isolieren, müssen normalerweise die gesammelten Überwachungsinformationen schrittweise verfeinert werden. Die beste Lösung ist es zuerst die Funktionalität zu betrachten, die erwiesenermaßen langsamer als erwartet läuft, und Messpunkte in die Komponenten einzubinden, die innerhalb dieser Funktionalität aufgerufen werden. Wenn diese Information nicht ausreicht, verfeinern Sie die Überwachung und fügen Sie weitere Messpunkte ein. Sobald das Performanceproblem isoliert und behoben wurde, sollte zumindest ein Messpunkt zum Zweck der dauerhaften Prüfung beibehalten werden. Dann sollte diese Einstellung gespeichert und alle anderen Messpunkte sollten gelöscht werden. Wenn Sie Code von Hand einfügen um Ihre Anwendungskomponenten zu überwachen, wird die Definition, Verbesserung und Entfernung der Überwachung sehr viel Zeit in Anspruch nehmen. Außerdem wirkt sich das Einfügen von nicht geschäftsbezogenem Programmcode negativ auf die Lesbarkeit und damit auch die Wartbarkeit aus. Mit verschiedenen Open-Source- Frameworks kann die Überwachung direkt in den Code integriert werden und sie ermöglichen eine elementare Visualisierung der Ergebnisse. Eine oft zu beobachtende Herangehensweise ist, Überwachungs- und/oder Performanceinformationen, z.b. mit Hilfe Seite 5

6 von Tools wie dem berühmten log4j, in die Standard-Protokollierfunktion einzubinden. Zur Lösung der aktuellen Probleme wurde in den meisten Fällen die Vorgehensweise, quick and dirty gewählt um Überwachungsfunktionalitäten einzubinden. Wir haben eine Vielzahl von Projekten gesehen, in welchen eine solche Herangehensweise für die punktuelle Performanceüberwachung sich zu dem Standardvorgehen im Gesamtprojekt entwickelte. Wir empfehlen daher dringend Performanceüberwachung nicht direkt in den Programmcode einzubinden. Diese Lösung ist unflexibel und kann nicht alle Informationen liefern, die Sie benötigen um Performanceprobleme zu finden. Außerdem kann hiermit normalerweise nur die Ausführungsdauer überprüft werden. Am anderen Ende der Skala liegen professionelle Lösungen für das Performance-Engineering - kommerzielle Werkzeuge wie z.b. CA Wily Introscope oder dynatrace. Performanceprobleme zu bewältigen und stellt transparente Anwendungsüberwachung für Auslastungstests zur Verfügung. Mit inspectit können auf einfache Weise mindestens 80% der Vorgaben zu Performance-Engineering realisiert werden. Wichtige Hinweise für die Überwachung einer Anwendung Es muss stark unterschieden werden zwischen der Überwachung eines produktiven Systems und dem Aufspüren von Performanceproblemen. Für die Überwachung einer produktiven Anwendung, bei welcher keine größeren Performanceprobleme auftreten, sollten einige wenige Überwachungspunkte definiert werden, die eine Trendanalyse ermöglichen. Das Ziel dieser Methode ist es Abweichungen vom normalen Verhalten zu erkennen und zu beheben, bevor die Benutzer davon betroffen sind. Weniger ist mehr ist der Schlüsselsatz. Das optimale Überwachungspaket enthält so wenig Informationen wie möglich, aber dennoch alle Informationen, die nötig sind, um die Anwendung zu überwachen und das aktuelle Problem zu finden. Um die Ursache von bestehenden Performanceproblemen genau zu bestimmen, kann die Anzahl der Messpunkte erhöht werden. In diesem Szenario sollte das Werkzeug dabei helfen, so viele Informationen wie möglich über die internen Abläufe der Anwendung und deren Performancedaten zu liefern - und dabei so wenig Overhead wie möglich zu produzieren. Alle verfügbaren Informationen zu sammeln ist kontraproduktiv, weil dies zuviel Overhead generiert und die erhobenen Informationen zu sehr verfälscht, um hilfreich zu sein (dieses Problem haben die meisten Profiler-Werkzeuge). Es gibt bestimmte entscheidende Informationen, welche immer gesammelt werden sollten, wenn eine Anwendung auf Performance getestet wird. Fast alle Performancewerkzeuge bieten dem Tester die Funktionalität, die für das Überprüfen von Anwendungen auf Performance notwendig ist. Alle Lösungen in diesem Bereich bringen aber hohe Kosten mit sich. Diese Werkzeuge stellen unübertroffene Funktionalität zur Verfügung. Sie sind ausgiebig getestet und unterstützen fast alle Umgebungen (sogar exotische). Trotzdem können sich manche Projekte ein teures Werkzeug für die Überwachung der Anwendung und das punktgenaue Aufspüren von Performanceproblemen einfach nicht leisten. Deswegen ist NovaTec stolz die Freigabe von inspectit zu verkünden. inspectit ist eine Überwachungslösung für Java. Sie konzentriert sich auf die Kernfunktionalität, die nötig ist um Abbildung 1: inspectit liefert wichtige Informationen über die Plattform, auf welcher die Anwendung läuft Seite 6

7 Nehmen Sie die Ressourcen unter die Lupe Alle Anwendungen benötigen während der Laufzeit Ressourcen. Wird die Auslastung einer Anwendung erhöht, führt dies in aller Regel auch zu einer Steigerung der Ressourcenauslastung (oder zur Steigerung der Anzahl der Ressourcen). Sobald eine Anforderung für eine bestimmte Ressource deren Verfügbarkeit übersteigt, wird die Anforderung in den Wartestatus versetzt, wodurch sich die Performance der Anwendung verringert. Durch diese enge gegenseitige Abhängigkeit zwischen der Ressource und der Anwendungsperformance müssen maßgebliche Ressourcen ebenfalls überwacht werden. Sobald die Überwachung Ressourcenknappheit anzeigt, muss darauf angemessen reagiert werden. Die nahe liegenden Ressourcen sind Systemressourcen wie CPU und Speicherauslastung oder Datenbankressourcen wie eine Datenbankanbindung. Ressourcen werden oft zentral vorgehalten (z.b. in einem Applikationsserver), also müssen diese Einheiten ebenfalls überwacht werden. Mit inspectit wird die Überwachung von Systemressourcen ohne Konfigurationsaufwand zur Verfügung gestellt. Der inspectit Agent greift direkt auf die Plattform zu, auf der er läuft und sammelt Informationen über das Betriebssystem und über die Java Virtual Machine. Nehmen Sie die Anwendung unter die Lupe Mit der Anwendungsüberwachung sind Sie in der Lage die Blackbox der Java Virtual Machine zu öffnen und während der Laufzeit Informationen über Ihre Anwendung zu sammeln. Nachdem jede Anwendung unterschiedlich ist, sind die Anzahl und die Stellen für die Überwachung ebenfalls unterschiedlich. Der häufigste Ansatz ist es zumindest die wichtigen Geschäftschnittstellen Ihrer Komponenten zu überwachen. Abhängig von Ihrem Informationsbedarf können weitere Messpunkte eingefügt werden um weitere Informationen über Ihre Anwendung einzuholen. Mit inspectit können Sie innerhalb Ihrer Anwendung (oder sogar in Bibliotheken anderer Hersteller, sofern sie ebenfalls in Java geschrieben sind) jederzeit Messpunkte auf jede Methode jeder Klasse platzieren. Diese Messpunkte liefern Ihnen die Information über die Häufigkeit und die Ausführungsdauer der jeweiligen Methode. Mit dieser Vorgehensweise können Sie auf einfache Weise die Ausführungshäufigkeit ihrer Komponenten überwachen und sind stets über alle Ausführungszeiten Ihrer Methoden informiert. Indem Sie einen Messpunkt auf die Eintrittsmethode einer Benutzertransaktionen setzen, können Sie die Zeit, die Ihre Anwendung benötigt, die Benutzeranforderung zu beantworten, direkt überwachen. Diese Information wird - wie alle Information innerhalb inspectit- für weitere Analysen einer Datenbank gespeichert. Basierend auf diesen Informationen können Trends erkannt und entsprechende Reaktionen erfolgen. Nehmen Sie den Anwendungsablauf unter die Lupe Für eine tiefer gehende Analyse von Use Cases ist es notwendig ein konkretes Verständnis zu entwickeln, was die Anwendung macht und welche Schritte innerhalb des Anwendungsablaufs langsam sind. Leider ist der Anwendungsablauf oft ziemlich komplex und umfasst eine riesige Baumstruktur. Der Ablaufpfad durch diesen Baum hängt oft direkt von den Eingabevariablen ab. Häufig führt dies zu Situationen, dass bestimmte Use Cases unregelmäßig verlangsamt auftreten oder zumindest eingabeabhängig große Unterschiede in ihrer Performance aufweisen. Für diese Situationen ist es die beste Analysemethode jeden Aufruf des Use Cases als unabhängige Informationsmenge zu behandeln. Um dies zu ermöglichen muss das Werkzeug für jeden Aufruf des Use Cases die einzelnen Schritte des Anwendungsablaufs liefern. inspectit hat dieses Konzept mit seinem Ablaufverfolger für Aufrufe implementiert. Diese Funktionalität erlaubt es den Startpunkt eines Use Cases zu definieren und verfolgt jeden Aufruf dieser Methode gesondert. Seite 7

8 Abbildung 2: Aufrufsequenz innerhalb von inspectit Abbildung 2 zeigt eine Aufrufsequenz innerhalb inspectit, welche von einer web-basierten Online-Shop- Anwendung aufgezeichnet wurde. Dieser Aufrufablaufsensor wurde so konfiguriert, dass er jeden Aufruf der Methode ordercartforcustomer getrennt aufzeichnet. Diese Methode wird von der Applikation aufgerufen, sobald der Einkaufskorb vom Kunden bestätigt wurde und die Bestellung verschickt werden kann. inspectit zeigt alle zuletzt erfolgten Aufrufe dieser Methode (oberes Fenster) und liefert die Dauer von jedem Aufruf. Der untere Teil zeigt den genauen Ablauf für den ausgewählten Aufruf. Der Performancetester kann den Aufrufbaum durchgehen und jeden Schritt überprüfen. Mit Hilfe dieser Funktionalität kann der Performancetester sehr schnell erkennen, dass das Problem in der VIP Customer inspection der Methode ordertocalculatesomebonus discount liegt. Eine genauere Überprüfung zeigt, dass viele Bestellobjekte aus der Datenbank geholt werden müssen, um den VIP-Status des Kunden zu überprüfen. Um zu berechnen, ob der Kunde VIP-Status hat, holt diese Implementierung immer alle Bestellungen des Kunden, rechnet sie zusammen und prüft, ob der Gesamtbetrag einen bestimmten Betrag übersteigt. Für relativ neue Kunden wird die Gesamtmenge der Bestellungen klein sein, deswegen läuft die Anwendung hier reibungslos. Für Langzeitkunden - mit einer hohen Anzahl von Bestellungen - wird die Applikation immer langsamer und langsamer. Probleme wie dieses sind ohne ein geeignetes Überwachungswerkzeug nur schwer zu erkennen. Zusätzlich zur Prüfung des Anwendungsablaufes kann oft die Ursache von Problemen mit Hilfe einer Zusammenfassung einfacher bestimmt werden. Basierend aus dem Beispiel in diesem Kapitel zeigt die nächste Abbildung eine Zusammenfassung aller Methoden, die bei dieser Anfrage aufgerufen werden (inspectit stellt auch eine Zusammenfassung für alle Datenbankabfragen zusammen, die vom Aufrufablauf aufgerufen werden). Bei der Verwendung dieser Ansicht kann man leicht erkennen, dass die Methode findbyartikelid sehr oft aufgerufen wird und fast 29 Sekunden benötigt. Nehmen Sie Datenbankabfragen unter die Lupe Aktuelle Schätzungen stellen unnötige oder unwirtschaftliche Datenbankabfragen an die Spitze der Performanceprobleme. Dies passiert häufig durch die Abstrahierung der Datenbank durch zusätzliche Frameworks. Die Entwickler werden die tatsächliche Abfrage, die durch das Framework ausgeführt wird, nie zu Gesicht bekommen. Ein weiteres häufiges Szenario basiert auf der Tatsache, dass die Definition neuer Datenbankabfragen für jedes Persistance Framework einige Zeit in Anspruch nimmt. Entwickler tendieren deshalb dazu existierende Abfragen weiter zu verwenden, selbst wenn diese Abfragen viel zu viele Informationen zurückgeben. Aber das Schreiben von neuen Abfragen führt zur Implementierung von einem neuen Programmcode, der von neuen Schnittstellen zu neuen Datentransferobjekten reicht. inspectit erlaubt Ihnen alle Datenbankabfragen nachzuvollziehen, die innerhalb Ihrer Anwendung erstellt und ausgeführt wurden. Standardmäßig ist das Datenbank- Tracing aktiviert und erfordert keine zusätzliche manuelle Konfiguration. Die gelieferten Informationen erlauben es schnell alle Abfragen auf ihre Ausführungshäufigkeit und ihre Ausführungsdauer zu prüfen. Da alle Daten in einer Datenbank gespeichert werden, können Trends leicht erkannt werden. Außerdem erlaubt inspectit direkt innerhalb einer Aufrufsequenz SQL- Informationen anzuzeigen, wodurch sich schnell zeigt, ob eine Methode aufgrund eines komplexen und ineffizienten Algorithmus oder aufgrund der aufgerufenen Datenbankabfragen langsam war. Seite 8

9 Nehmen Sie die Architektur unter die Lupe Eine weitere wichtige Aufgabe von Überwachungswerkzeugen ist es zu bewerten, ob Architekturspezifikationen befolgt wurden. Wird ein Aufrufsensor auf die Eintrittsmethoden der Layer und Komponenten der Anwendung gesetzt kann auf einfache Weise nachvollzogen werden, welche Layer und Komponenten jeweils durch die Use Cases angesprochen wurden. Diese Information ist unschätzbar für Architekten um zu überprüfen, ob die Abhängigkeiten zwischen Anwendungen angemessen ist und um zu verstehen, welche Komponenten derzeit eingesetzt werden um einen Use Case abzubilden. inspectit hilft Ihnen dabei Ihre Performanceprobleme zu lösen NovaTec besitzt jahrelange Erfahrung im Umgang mit Anwendungsperformance. Diese reicht von der Definition und Integration von Performanceprozessen für die Sicherstellung der Anwendungsentwicklung bis hin zu Feuerwehreinsätzen in kritischen Projekten, bei welchen die Performance unmittelbar verbessert werden muss. Wir sind stolz werkzeugunabhängige Performanceberatung anzubieten. Um die bestmögliche Performanceberatung anzubieten haben wir starke Beziehungen mit den beiden Big Players in den heutigen Anwendungsperformance-Märkten aufgebaut: dynatrace und CA Wily Introscope. Unsere Ingenieure verfügen über eine langjährige und praxiserprobte Erfahrung mit den gängigen und am Markt erhältlichen Werkzeugen. Seit vier Jahren arbeiten die Ingenieure in der Geschäftseinheit Application Performance Engineering von NovaTec an der Implementierung einer Lösung für die Überwachung der Anwendungsperformance. Wir sind stolz offiziell die erste Freigabe dieser Anwendung inspectit verkünden zu können. Die Entwicklung von inspectit beinhaltet die Erfahrung von vielen hoch qualifizierten NovaTec- Ingenieuren, die Ihnen bei der Lösung Ihrer Performanceprobleme helfen. Mit inspectit können Sie auf einfache Weise für weniger als ein Zehntel der Kosten der meisten anderen kommerziellen Überwachungswerkzeuge eine Anwendungsüberwachung in ihren Entwicklungsprozess einbinden. Trotzdem ist inspectit absolut in der Lage sicherzustellen, dass die Anwendung die definierten Performance-Anforderungen erfüllt. inspectit funktioniert durch die transparente Integration von Callback- Hooks in die Anwendung indem der Java-Code während der Ladezeit dynamisch verändert wird. Diese Hooks werden später von den Sensoren von inspectit verwendet um eine Reihe von Überwachungsinformationen über die Anwendung zu sammeln. Diese Vorgehensweise der Überwachung wird durch eine minimale (transparente) Änderung des Codes ermöglicht und ist damit der bestmögliche Weg zur Integration einer Überwachung. Alle Messlogik erfolgt durch die Sensoren, die außerhalb des geschäftsrelevanten Codes laufen und ist somit von ihrer Anwendung getrennt. Das flexible und zuverlässige Kernframework von inspectit erlaubt die einfache Integration weiterer Sensoren. So können neue Sensoren erstellt werden um die Informationen zu sammeln, die Sie benötigen. Eine inspectit-installation besteht aus mindestens einem Agenten, der auf der Java Virtual Machine der Anwendung läuft und die Anwendungen überwacht, einer (oder in seltenen Fällen mehrere) zentralen Mess-Repository (CMR), die die Daten, die von den Agenten gesandt werden persistent speichert und mehreren Clients, die mit dem CMR verbunden sind, welche die gesammelten und verdichteten Abbildung 3: inspectit Datenbank-Sensor: Prüfen Sie in kürzester Zeit Ihre SQL-Abfragen auf Performance Seite 9

10 Daten auf eine aussagefähige Weise darstellen. Der inspectit-agent ist die Komponente, die Messpunkte innerhalb der überwachten Anwendung ermöglicht. Sie muss in dem Startskript Ihrer Anwendung (oder dem Anwendungsserver) integriert werden und fügt in den konfigurierten Methoden die definierten Sensoren ein. Alle Konfigurationseinstellungen erfolgen in einer Konfigurationsdatei, die im Konfigurationsordner des Agenten liegt. Die Integration des Agenten erfolgt einfach durch das Hinzufügen einer zusätzlichen JVM-Option zum Startskript Ihrer Anwendung. Das Aufsetzen der CMR und des GUI ist noch einfacher: Kopieren Sie einfach die Releases an die gewünschte Stelle und führen Sie die Startskripte aus. Interesse? Nehmen Sie unter Kontakt mit uns auf oder rufen Sie uns unter +49 (0) an. Sie können auch die u. a. Kontaktinformation verwenden. M.Sc. Stefan Siegl Business Unit Manager Application Performance Engineering Projektleitung inspectit M.Sc. Patrice Bouillet Leiter Systemarchitektur für inspectit Seite 10

11 NovaTec - Ingenieure für neue Informationstechnologien GmbH Alle anderen hierin erwähnten Marken oder Produktnamen sind Marken oder eingetragene Marken der jeweiligen Eigentümer. Version / Okt 2009 Seite 11

12 Fact Sheet inspectit Anwendungsperformance und -stabilität wird mehr und mehr zum maßgeblichen Faktor für das Scheitern eines Software-Projekts. Das Erkennen eines Performanceproblems in einer Produktivumgebung kann - in Extremfällen - eine vollständige Erneuerung der Softwarearchitektur nach sich ziehen. Behalten Sie die Oberhand im Kampf um Performance indem Sie die Black Box von Java öffnen. Dies ermöglicht Ihnen den Blick darauf, welche Teile Ihrer Anwendung wie erwartet arbeiten und welche verbessert werden müssen. Gewinnen Sie den Performance-Wettstreit durch das Integrieren von transparenten inspectit- Sensoren innerhalb Ihres Programmcodes. Das Integrieren von Messpunkten erfordert nur eine einzige Zeile in der Konfiguration, in welcher die Stelle für diesen Messpunkt festgelegt wird. Sparen Sie Zeit, Mühe und Kundensupport indem Sie mögliche Engpässe in der Performance erkennen bevor Sie die Anwendung an Ihren Kunden ausliefern. Je früher Sie Performanceprobleme erkennen und beheben, desto besser. Features Schnelle und einfache Installation und Konfiguration Beginnen Sie mit der Implementierung in Ihre Anwendung ohne die komplizierte und zeitaufwändige Einrichtung von Werkzeugen. inspectit kann innerhalb einer Stunde aufgesetzt werden. Anschließend können Sie Ihre Messpunkte definieren und die Überprüfung starten. Nahtlose Integration inspectit fügt sich nahtlos in eine Java-Applikation ein indem das ausführbare Programm mit Markern versehen wird. Beim Laden der Klasse wird der Code für die Messung hinzugefügt, so dass Ihr anwendungsrelevanter Code wie bisher bestehen bleibt - die Anwendungslogik wird nicht beeinträchtigt. Moderne Technologien und Verwendung offizieller Standards inspectit ist vollständig in Java geschrieben und verwendet offiziell verabschiedete und standardisierte Schnittstellen. Alle Komponenten von inspectit basieren auf bekannte und standardisierte Bibliotheken wie Spring, Eclipse RCP, PicoAgent. Dezentrale Architektur Die flexible, dezentrale Architektur erlaubt den Einsatz eines oder mehrerer zentraler Server für das Sammeln, Speichern und Verdichten der Daten von mehreren Agenten sowie der Bereitstellung dieser Daten an mehrere Standalone-Clients um sie zu analysieren. Optimiert auf wenig Overhead inspectit wurde entwickelt damit so wenig Overhead wie möglich produziert wird - selbst in komplexen, geclusterten Umgebungen. Überwachungsfunktionalität inspectit kann dazu verwendet werden Ihre Live-Anwendung zu überwachen und maßgebliche Informationen über den aktuellen Status Ihrer Anwendung zu liefern. Seite 12

13 Flexible Architektur erlaubt schnelle Integration der Sensoren inspectit basiert auf einer hochflexiblen Agentenarchitektur, die eine nahtlose Integration von Sensoren in den Anwendungscode ermöglicht. Die Standardanwendung beinhaltet eine Vielzahl von Sensoren zum sofortigen Gebrauch. Weitere Sensoren können auf einfache Weise integriert werden. Zur Zeit beinhaltet inspectit folgende Sensoren: Zeitmessung (Timer-Sensor) Überwachen Sie auf einfache Weise die Ausführungszeit der Methoden in Ihrer Anwendung um zu sehen, welche Methoden am Längsten dauern. Der Sensor liefert die reinen CPU-Zeiten. Diese erlauben es zu überprüfen, ob der Grund für die lange Ausführungsdauer der Methode die komplexe Logik war oder ob sie lediglich gewartet hat. Plattform Sensor Der Plattform Sensor ermöglicht die Überwachung von Systemressourcen wie CPU-Auslastung, Speicherauslastung, Threading usw. Datenbanksensor Performanceprobleme können oft auf ineffiziente oder unnötige Datenbankabfragen zurückgeführt werden. inspectit erlaubt es die Dauer und Struktur von Datenbankabfragen zu überwachen und liefert die Abfrage wie sie an die Datenbank gesendet wird, selbst inklusive aller aktuellen Parameter. Aufrufsequenz-Sensor Verwenden Sie Aufrufsequenzen um eine detaillierte Auflistung der Aufrufstruktur zu erhalten. Wenn Sie diesen Sensor verwenden erhalten Sie direkt die Information, welche Methoden vom Benutzer aufgerufen wurden und welche Methoden bei der Ausführung der Logik lange gedauert haben. Diese Funktion ist von unschätzbarem Wert um Aufrufe zu prüfen, die nur sporadisch langsam sind bzw. eine tiefer gehende Analyse einer bestimmten Funktionalität durchzuführen. Flexible Möglichkeiten für die Sensorkonfiguration inspectit beinhaltet eine flexible Konfiguration der Sensoren. Validierung der Architektur Architekten können die Messpunkte einsetzen um Informationen zur Überprüfung der Architektur zu sammeln. Dies erlaubt ihnen zu überprüfen, ob die Entwickler die Architektur so benutzen wie sie vom Architekten vorgesehen war. Visualisierung Eine individuell anpassbare standardisierte Benutzeroberfläche ermöglicht eine einfache Analyse der gesammelten Daten. Unterstützung für alle Java Applikationen auf allen Plattformen inspectit kann alle Java-Anwendungen (JVM Version > 1.3) überwachen und unterstützt alle bekannten Applikationsserver. Die wirtschaftlichste Lösung für die Java-Überwachung inspectit liefert alle notwendigen Funktionen für die Anwendungsüberwachung von Java-Anwendungen. Sie kostet aber nur einen Bruchteil dessen, was andere Werkzeuge kosten. Seite 13

14 NovaTec - Ingenieure für neue Informationstechnologien GmbH Alle anderen hierin erwähnten Marken oder Produktnamen sind Marken oder eingetragene Marken der jeweiligen Eigentümer. Version / Okt 2009