Continuous APM von dynaTrace ist eine APM-Lösung, die es ermöglicht Performance- und Skalierbarkeits-Probleme zu isolieren und zu beheben, noch bevor diese Auswirkungen auf die Produktionsumgebungen haben. Ein herausragendes Unterscheidungsmerkmal ist die Einsatzmöglichkeit in Produktiv-Umgebungen ohne nennenswerten Overhead. Das hilft Entwicklern bei der Ermittlung von Problem-Ursachen, ohne den Problemfall reproduzieren zu müssen. Sie integriert mit mehreren ALM-und IT-Management-Tools und liefert so einen ganzheitlichen Einblick in die Application Performance. Unternehmen können mit diesem Produkt Performance-Probleme aufdecken: während der Software-Entwicklung, Performance- und Lasttests, sowie in der Produktion. Im Unterschied zu konkurrierenden Lösungen, die lediglich aggregierte Analysedaten liefern, fokussiert die Lösung von dynaTrace auf das Tracen einzelner Transaktionen, sammelt dabei hoch granulare Daten aus einer Vielzahl von Quellen und unterstützt damit die rasche Ursachenanalyse und Problemlösung.

Linux oder Windows, Java oder .Net, Open-Source- oder kommerzieller Applikations- und Datenbankserver – bei heutigen Geschäftsanwendungen ist nahezu alles vertreten. Das erschwert die Test- und Diagnostizierbarkeit solcher Systeme erheblich. Dem will Dynatrace mit Diagnostics begegnen.

Der Markt bietet viele Profiling-, Diagnose- und Monitoring-Werkzeuge, mit teilweise stark unterschiedlichen Funktionen. Der Artikel beleuchtet einige dieser Tools, zeigt deren Unterschiede auf und gibt Hinweise für die Auswahl geeigneter Tools.

TSS recently had a discussion with Randy Arseneau, Ted Feyler, and Kathy Harsanyi from DynaTrace, discussing their flagship product, which helps isolate performance problems in Java throughout the entire development cycle. This is a summary of the technology and its value proposition.

In den vorangegangenen Artikeln haben wir uns mit Performance- und Skalierbarkeitsproblemen und deren technischem Umfeld beschäftigt. Im letzen Artikel der Performancereihe werden wir auf die Themen „Performancemanagement“ und „Performance-Engineering“ sowie die Umsetzung im Unternehmensumfeld eingehen.

Diesmal verlassen wir unseren „heimischen“ Java-Boden und begeben uns in die Welt von Ajax-Anwendungen. Im letzten Artikel haben wir uns mit generellen serverseitigen Performance- und Skalierbarkeitsproblemen beschäftigt. Die Performance von JavaScript, dessen Konzepte und Ausführungsumgebungen stehen dieses Mal im Vordergrund der Betrachtungen.

Continuous Integration (CI) und automatisiertes Testen finden immer mehr Einzug in Softwareentwicklungsprozesse. Speziell in agilen Entwicklungsprozessen ist der Ansatz ein zentraler Baustein. Test Driven Development (TDD) führt bei richtigem Einsatz zu besserer Qualität und mehr Stabilität trotz kontinuierlicher Erweiterungen und Änderungen eines Softwaresystems. Neben funktionalen Tests sollten auch Skalierbarkeits- und Lasttests kontinuierlich vorgenommen werden.

In den letzten Artikeln dieser Reihe haben wir uns eingehend mit unterschiedlichen Bereichen im Umfeld von Softwareperformance auseinandergesetzt. Unsere Themen waren Datenbankzugriffe, verteilte Anwendungen und Garbage Collection. Mit dem nötigen Basiswissen ausgestattet, können wir diese Konzepte nun im Umfeld einer konkreten Anwendungsdomäne (Webanwendungen) anwenden.

In den letzten beiden Artikeln haben wir uns bereits mit dem Thema Speichermanagement in Java beschäftigt. Nach der Vorstellung allgemeiner Antipatterns wurden die Entstehung und das Auffinden von Memoryleaks genauer beleuchtet. In diesem Artikel werden wir uns detaillierter mit dem Thema Garbage Collection befassen.

Oft gestaltet sich die Suche nach Memory Leaks als echtes Abenteuer und man muss sich durch einen Dschungel an Objekten und Referenzen kämpfen. Speziell wenn Produktivsysteme betroffen sind, heißt es, schnell handeln. So wie Indiana Jones immer wieder auf verblüffende Art Hinweise interpretiert und Rätsel löst, um verlorene Schätze zu finden, wollen wir uns auf die Suche nach Memory Leaks begeben.

Memory Leaks und andere Speicherprobleme gehören zu den beliebtesten Skalierbarkeits- und Performance-Killern im Java-Umfeld – hier lohnt sich eine genauere Analyse.

In letzter Zeit wird die Debatte, ob man für Web-Services-orientierte Anwendungen SOAP oder REST verwenden soll, zunehmend stärker. Mehr und mehr Stimmen behaupten, dass REST gegenüber SOAP zu bevorzugen sei. Der Konflikt entwickelt sich immer stärker zu einem Glaubenskrieg, bei dem die Fakten in den Hintergrund treten. Neben der Einfachheit wird oft auch die Effizienz als Grund für die Entwicklung von REST-basierten Services genannt. Alles in allem Grund genug, diese Frage auch einmal aus Performancesicht zu beleuchten.

Sehr häufig bleiben Details, wie Daten erzeugt und übertragen werden, im Verborgenen. Ein wesenticher Grund ist hier, dass sich der Anwendungsentwickler um diese Teile keine Gedanken machen muss, da ihm diese Aufgabe von Remoting-Frameworks abgenommen wird. Da Serialisierung aber einer der Hauptbestandteile einer verteilten Anwendung ist, sollen die Serialisierungskonzepte in diesem Artikel detailliert betrachtet werden.

Verteilung und Kommunikation zwischen Anwendungen und Services ist ein wesentliches Konzept moderner Softwarearchitekturen. Um von Verteilung allerdings profitieren zu können, müssen einige Grundlagen beachtet werden, damit man nicht unweigerlich in massive Performance- und Skalierbarkeitsprobleme läuft. In der Entwicklung bleiben diese Probleme oft verborgen. Erst im Lasttest oder Produktivbetrieb stellt man fest, dass die gewählte Verteilungsarchitektur Performance- und Skalierbarkeitsanforderungen nicht erfüllen kann. Es ist daher erforderlich, die Ursachen für die Probleme zu verstehen.

Sehr häufig bleibt die JDBC-Schicht innerhalb von Datenbankszugriffs-Frameworks verborgen. Speziell in dieser Schicht gibt es aber einige Bereiche, die zu Performanceproblemen führen können. Dieses Problem sowie das Testen der Performance von Datenbankanwendungen soll Thema dieses Artikels sein. Die Erfahrung zeigt, dass es ein sehr vernachlässigter Teil in der Entwicklung von Datenbankanwendungen ist.

Für Java-Anwendungen, die Daten in einer relationalen Datenbank speichern, bieten O/R-Mapper eine einfache Möglichkeit, den Status von Objekten auf Tabellen in der Datenbank abzubilden. Der gesamte JDBC-Datenbankzugriff ist innerhalb des Frameworks gekapselt und der Code beinhaltet fast ausschließlich fachliche Logik. Diese Kapselung führt aber auch zu Missverständnissen und fehlerhaftem Einsatz der Frameworks.

Die Vereinfachung des Datenzugriffs mittels O/R-Mappern wie Hibernate oder Toplink führt nicht selten dazu, dass dem Datenzugriff in der Architekturphase zu wenig Aufmerksamkeit gewidmet wird. Dabei lassen sich gerade in der Architektur und im Design des Datenzugriffs sehr häufig Performance- und Skalierbarkeitsprobleme finden.

Dieser Artikel erläutert warum die mangelnde bzw. verspätete Fokussierung auf Performance fatale Probleme nach sich ziehen kann. Zudem wird gezeigt wie die Dynamik eines Systems messbar wird und welche dabei Rolle Diagnosewerkzeuge der zweiten Generation spielen.

Performance ist eine kritische Anforderung in Java EE-Projekten. In vielen Tuning-Projekten konnten Anti-Patterns identifiziert werden, die einen hohen Wiedererkennungswert haben und so in den eigenen Projekten vermieden werden können.