Eine gute Dosis Java-Performance-Weisheit

Die Java-Engine frisieren: Interview mit Kirk Pepperdine

Redaktion JAXenter

© Shutterstock.com/Dejan Lazarevic

Sind Sie darauf aus, ihr Java-basiertes System zu optimieren? Dann sollten Sie den weisen Worten von Kirk Pepperdine, Allround Java-Mechaniker und Performance-Spezialist, lauschen.

Kirk, du bist seit Jahren ein Pionier im Bereich Java Performance Tuning. Ich würde mit dir gerne über deine „Geheimrezepte“ für die Beschleunigung Java-basierter Systeme sprechen. Aber zunächst einmal: Könntest du uns bitte einen Überblick darüber geben, welche verschiedenen Bereiche du im Markt identifizierst und welche davon am  Performance-orientiertesten sind?

Kirk Pepperdine: Ich muss hier gleich eine Sache richtigstellen: Der wahre Pionier ist Jack Shirazi. Er schrieb das erste echte Buch über das Thema Java Performance Tuning, das über die aktuelle Version hinausgehend anwendbare Tipps beinhaltete. Ich hatte bei dem Buch zwar auch meine Hände mit im Spiel, aber Jack war derjenige, der es zusammenstellte.

Um die zweite Frage als erste zu beantworten: Ich glaube, alle Bereiche des Marktes stehen vor der Herausforderung, dass die User immer schnellere Systeme erwarten. Und es wird erwartet, dass die Systeme immer größere Datenmengen umfassen und verarbeiten können. Eine etwas allgemeiner gestellte Frage wäre: Biete ich meinen Kunden ein besseres Performance-Profil als mein Mitbewerber? Oder: Wenn sich eine Geschäftsmöglichkeit ergibt, ist mein System dann fein genug abgestimmt, um das Rennen um sie zu gewinnen? Mit dieser Frage im Hinterkopf würde ich sagen, es gibt nur sehr wenige Bereiche, in denen Performance nicht wichtig ist.

Nun zu den Geheimrezepten. Das erste große Geheimnis ist, dass es keine Geheimnisse gibt. Bei Performance geht es vor allem darum, ein Verständnis für die Hardware zu haben, mit der man arbeitet, damit man das beste aus ihr herausholen kann. So war es schon damals, als ich mit Supercomputern von Cray gearbeitet habe, und das ist auch heute so, wenn ich mit gewöhnlicher Standardhardware arbeite. Mancher sagt, die Hardware will schnell sein, also steh ihr nicht im Weg. Sobald man versteht wie sie arbeitet weiß man auch besser, wie man ihr nicht im Weg steht.

Performance ist ganz offensichtlich eine komplexe Angelegenheit: Einerseits die vielen Tuning-Aspekte, all diese Schrauben und Muttern auf der Basisebene von Java, andererseits gibt es die End-to-End-Sicht auf Systeme, vom Datenspeicher bis zum Interface des Endnutzers. Kannst du uns einen Tipp geben, wo man im Allgemeinen beginnen sollte?

Pepperdine: Es existieren zwei Arten des Performance Tuning, Top-down und – Überraschung – Bottom-up. Die größten Zugewinne lassen sich immer mittels Top-down-Tuning realisieren. Man betrachtet das System sozusagen vom höchsten Punkt aus, identifiziert die größten Verbraucher des Latency-Budgets und konzentriert seine Anstrengungen in diese Richtung. Hört der Hardware zu, sie wird euch sagen, was ihr im Weg steht!

Bei der Bottom-up-Methode beginnt man auf der Hardware-Ebene und lässt sich von ihr sagen, wie man ihr im Weg steht. Man kann sich zum Beispiel die maschinenspezifischen Register (MSR) ansehen. Diese speziellen diagnostischen Register innerhalb der CPU können einem wertvolle Informationen wie z.B. die Hit/Miss-Verhältnisse des Cache liefern. Nochmals: Keine Geheimrezepte, sag mir bloß, wo ich im Weg stehe, damit ich Platz machen kann.

Java Code CampPurely Code: Erleben Sie Angelika Langer, Arno Haase, Kirk Pepperdine und Thilo Frotscher als Speaker auf dem Java Code Camp 2015 in Berlin! In einem komprimierten 2-Tage-Trainingsprogramm erhalten Sie wertvolle Tipps für besseren Code.

Alle weiteren Infos und Anmeldung auf java-code-camp.de

 

Ist es im Zeitalter der Cloud nicht viel einfacher, dem System zusätzliche Instanzen hinzuzufügen, anstatt seine Interna zu optimieren? Oder anders ausgedrückt: Bis zu welchem Grad helfen zusätzliche Ressourcen (vormals CPUs, im Cloud-Zeitalter Instanzen) und in welchen Bereichen kann nur die sprichwörtliche Schweizer Genauigkeit auf der Kernebene der Software etwas ausrichten?

Pepperdine: Sicher, ein großer Pluspunkt für die Clouds ist der Umstand, dass sie die Administrationslast verringern und die Skalierung erleichtern. Wenn dein System allerdings nicht auf Skalierung ausgelegt ist, ist die zusätzliche Hardware nutzlos. Hinzu kommt, dass man nicht beliebig viel auf ein Stück Hardware aufsetzen kann, ohne die Hardware zu überfordern. Virtualisierung erkauft einem nicht mehr Hardware. Das bedeutet, du musst wissen, ob deine Anwendung mit jeder anderen Anwendung klar kommt, die auf derselben physischen Hardware läuft.

Ich habe unternehmenskritische Anwendungen gesehen, die in einer VM auf derselben Hardware wie eine Oracle DB liefen. Das kann einfach nicht funktionieren, egal wie man es betrachtet. Ich habe auch Kisten gesehen, in der bestimmte Ressourcen – normalerweise die Netzwerkkarte – mehr als ausgeschöpft waren. Dazu kommt, eine Cloud-Instanz zu verschwenden, ist wie die Verschwendung einer jeden anderen Ressource: der Return on Investment schrumpft. Also ja, Clouds sind sehr nützlich.

Sie sind allerdings nicht die sprichwörtliche silberne Kugel. Du musst bei der Bereitstellung von Hardware nach wie vor vorsichtig sein. Sicher, zur Zeit muss man sehr umsichtig sein, wenn man niedrige Latenzanforderungen hat. Für extrem niedrige Latenzen braucht man notwendigerweise immer noch „blankes Metall“.

Wie steht es mit verteilten Systemen, oder sagen wir Microservices (die dazu neigen, die Komplexität aus dem Innern eines Monolithen ins Netzwerk zu verlagern)?

Pepperdine: Mensch, es macht schon Spaß wie sich die Technologie wandelt. Vor kurzem erst habe ich auf einen Tweet von Eberhard Wolff geantwortet, in dem er eine Definition von Microservices formulierte. Wenn man dieser Definition folgt, dann haben wir Systeme mit Microservices schon zu einer Zeit gebaut, als an Java überhaupt noch nicht zu denken war.

1992 arbeitete ich an einem System, das ich als Microservices-basiert bezeichnen würde. Selbst nach heutigen Standards war das ein gut gebautes System. Alle Workflows durch die Microservices konnten mit einer DSL spezifiziert werden; alle Microservices konnten auf dem Compute-Cluster herum migriert werden. Es war sehr flexibel, sehr, sehr robust und lieferte eine gute Performance. Die einzige Kehrseite war das Netzwerk – und so ist es auch heute.

Wenn dein Workload nicht groß genug ist, um die Kosten der Netzwerkverteilung aufzuwiegen, dann wird die Netzwerklatenz zum dominierenden Kostenpunkt. Und das sind große Kosten. Manch einer würde sagen: Kosten, die dich dazu bewegen, deine Microservices nicht zu verteilen.

Du berätst viele verschiedene Entwicklerteams überall in Europa und dem Rest der Welt – würdest du sagen, dass sich Community im Hinblick auf „Performance-Weisheit“ auf einem guten Niveau befindet?

Pepperdine: Das sind im Grunde mehrere Fragen. Lass mich die offenkundigste zuerst beantworten. Ich würde sagen, das Niveau eines Teams befindet sich in der Regel auf einem Stand, den das Team die meiste Zeit über braucht. Teams bekommen dann Schwierigkeiten, wenn sie nicht erkennen dass sie vor einem Problem stehen, dass sie nicht lösen können bzw. zu lange warten, bevor sie sich nach Hilfe umsehen. Ein Beispiel: Erst kürzlich bekam ich einen Anruf von einem Unternehmen, dass über ein sehr starkes, Performance-fokussiertes Entwicklerteam verfügt. Sie hatten ein Problem mit einer Anwendung, die immer wieder einen 5-fachen Anstieg der Antwortzeiten erfuhr. Das Team verbrachte mehrere Monate mit der Suche nach der Ursache, bevor sie schließlich Hilfe suchten. Die Diagnose dauerte mehrere Stunden und umfasste auch eine Betrachtung des Teils der JVM, von dem viele noch nicht einmal wissen, dass er existiert – geschweige denn, wie er funktioniert. Das ist meine Antwort auf die offensichtliche Frage. Die nicht ganz so offensichtliche Frage dreht sich eher um die Versäumnisse des Bildungssystems; darum, dass nicht genügend diagnostisches Wissen vermittelt wird.

Mir ist keine postsekundäre Bildungseinrichtung bekannt, die Kurse im Bereich Performance Tuning anbietet. Sie sind zwar sehr gut darin, den Leuten Fakten und Anleitungen für das Bauen von Systemen zu vermitteln, aber im Hinblick auf die Diagnostik klafft im Curriculum ein großes Loch. Die Wichtigkeit wissenschaftlicher Methoden, der statistischen Analyse und des Performance-Benchmarking spielt kaum eine Rolle. Vor allem die Kurse im Grundstudium konzentrieren sich auf Optimierungen wie „Mergesort ist schneller als Bubblesort“ oder Performance-Schätzungen, die von statischer Kompilierungen in statischen Laufzeiten ausgehen. Einige Universitäten planen zwar, diese Dinge in ihr Curriculum aufzunehmen, aber bis jetzt habe ich davon noch nichts gesehen. Die Leute stehen also vor gewissen Aufgaben, haben aber nicht die notwendigen Werkzeuge an der Hand, um diese zu bewältigen. Was tun sie also? Sie wursteln sich durch, erledigen die Arbeit so gut sie können – und meistens kriegen sie es auch hin. Allerdings wären sie dabei um ein vielfaches effizienter gewesen, wenn sie sich an einem formalisierten Prozess hätten orientieren könnten, der ihnen dabei hilft.

Zum Abschluss sei gesagt: Das ist es, was ich glaube zu bieten; eine Methodologie die damit beginnt, den Performance-Tuning-Prozess zu formalisieren. Ich behaupte nicht, dass die Methodologie komplett ist oder dass sie den einzig gangbaren Weg darstellt. Allerdings ist es eine Methodologie, die schon vielen Leuten dabei geholfen hat, Struktur in diesen Kuddelmuddel, genannt Performance Troubleshooting, zu bringen.

Der Originalartikel erschien auf Jaxenter.com

Aufmacherbild: Metallic background of the internal combustion engine. von Shutterstock.com / Urheberrecht: Dejan Lazarevic

Geschrieben von
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: