JavaSpektrum Juni/Juli 2005 [antikvár]

w Leistung zählt! Gerade in der Soft-^ wareentwicklung spielt Geschwindigkeit" eine essentielle Rolle. Nicht nur für die Entwicklungszeiten der Projekte, sondern auch für das Laufzeitverhalten der daraus resultierenden Softwareprodukte. Kein Wunder, dass entsprechende Tuningwerkzeuge heute eine breite Marktdurchdringung besitzen. Leider betrachten viele Projektbeteiligte Perfor-manztuning als ungeliebtes Kind, dem man allenfalls nach der Geburt etwas Aufmerksamkeit schenken muss. Dem-entsprechende Qualität besitzt so manche Softwarearchitektur.Um es gleich vorwegzunehmen, nicht in jedem Softwaresystem besitzen Per-formanzkriterien eine hohe Bedeutung. Tauchen derartige Kriterien nicht explizit im Anforderungskatalog auf, so sollten sich die Aufwände für entsprechende Tuningmaßnahmen auf ein Minimum beschränken. Es gelten in diesem Fall die traditionellen Grundregeln für Optimierungsmaßnahmen: don't do it" beziehungsweise don't do it now!". Für eine einfache GUI-Komponente, die in jeder Sekunde die aktuelle Uhrzeit darstellt, dürften sich nur schwer plausible Gründe für umfassende Tuningmaßnahmen finden. Ein möglicher Fallstrick ergibt sich bisweilen daraus, dass im Projekt unterschiedliche Stakeholder" divergierende Vorstellungen besitzen. Performanz kann ein ganzes Spektrum von Themen subsumieren, etwa Eingabe-/Ausgabe-Geschwindigkeit, Skalierbarkeit, Reaktivität der GUI, Initialisierungszeit oder Durchsatz. Neben der Festlegung der detaillierten Performanzmaßnahmen sollteGeschwindigkeit ist keine Hexereiebenfalls eine realistische Schätzung der Machbarkeit erfolgen. Als typisches Beispiel gilt die angestrebte Performanzstei-gerung durch Nebenläufigkeit. In den meisten Projekten sind maximal 20 % der Aktivitäten parallelisierbar. Selbst durch raffinierteste Performanzmaßnahmen ließe sich somit die Laufzeit auf maximal 80+x % verringern.Wie am Beispiel objektorientierter Middleware ä la EJB oder CORBA ersichtlich, streben Softwarearchitekten nach maximaler Transparenz. Sie nutzen eine Vielzahl von Abstraktionsschichten, um architektonische Brüche zu vermeiden. Maximale Transparenz bedeutet auf der anderen Seite aber auch minimale Einflussmöglichkeiten, woraus wiederum negativer Einfluss auf die Performanz resultiert. Kein Wunder, dass zum Beispiel Datenbankentwickler am liebsten aus dem Client direkt auf Entity-Beans zugreifen würden. Um diesen Konflikt sowohl für Architekturfetischisten als auch für Performanzfanatiker erträglich zu gestalten, bedarf es einer Softwarearchitektur, die Transparenz als strategisches Prinzip nutzt, aber dieses Prinzip aufweicht, wo Effizienz essentielle Bedeutung besitzt. Speziell generative und aspektorientierte Ansätze können in diesem Kontext gute Hilfestellung leisten. Eine weitere Implikation lautet freilich, dass Entwickler sowohl fundiertes technisches als auch architektonisches und domänenspezifisches Wissen benötigen.In der Praxis steht jedes Softwareprojekt einem Performanz/Flexibilitäts-Di-lemma gegenüber. Soll heißen: Integrieren Entwickler Performanzmaßnahmen fest in ihre Architektur, lassen sich auf der einen Seite höhere Effizienz und stabilere Architekturen erzielen. Auf der anderen Seite verhält es sich wie bei Allwetterreifen. Diese erweisen sich zwar in den meisten Umgebungen als zufriedenstellend, aber niemals als optimal. Ein erfahrener Entwickler öffnet die Architektur daher gemäß dem Open/Close-Prinzip mit dem Ziel, dass sich die Software dynamisch an ihre Umgebung anpasst. Als goldene Regel gilt: So viel statisches Tuning wie möglich und so viel dynamisches Tuning wie notwendig.Dynamisches Tunen kann unterschiedlich erfolgen, zum Beispiel während der Initialisierungszeit oder kontinuierlichan festgelegten Zeitpunkten. Für Echtzeitsysteme erscheint die erste Option in vielen Fällen als die sinnvollere Variante. Bei stark variierenden Laufzeitumgebungen kann eine auf initiales Tuning beschränkte Strategie aber einen gravierenden Nachteil darstellen. Hier verhält es sich wie beim Einsatz von Regenreifen in der Formel 1. Herrscht kurz nach Rennbeginn ständiger Sonnenschein, erweist sich die falsche Reifenwahl später als signifikanter Nachteil. Kontinuierliches Tuning repräsentiert in diesen Fällen die wesentlich praktikablere Lösung. Allerdings bedarf es zu diesem Zweck geeigneter Messgrößen als Grundlage für die dynamische Optimierung.Durch Performanzmaßnahmen und das Aufzeichnen von Messdaten erfolgt eine unmittelbare Beeinflussimg des Systemverhaltens, quasi eine Art Heisenberg-Effekt. Bisweilen resultieren daraus unbeabsichtigte oder unberücksichtigte Nebeneffekte. Diese Nebeneffekte können im Extremfall zu langsamerem Laufzeitverhalten führen. Ein 100m-Sprinter dürfte zum Beispiel nur selten auf die Idee kommen, mitten im Rennen die Laufschuhe zu wechseln. Entwickler müssen also sicherstellen, dass die Nachteile einer Performanzmaßnahme nicht überwiegen. Insofern bedarf es auch in diesem Fall einer klaren Kosten/Nut-zen-Rechnung.Performanz stellt also summa summa-rum ein wichtiges Thema für Entwicklungsprojekte dar. Das dazugehörige Performanztuning erfordert allerdings einen ganzheitlichen, expliziten und systematischen Ansatz, der von der Anforderungsanalyse, über die Architektur bis zur Implementierung und Laufzeitadministration reicht. Partielle Maßnahmen nach dem Zufallsprinzip bewirken meistens genau das Gegenteil: mangelhafte Performanz und eine verunstaltete Architektur.Ich hoffe, auch die Performanz der vorliegenden Ausgabe von JavaSPEKTRUM entspricht Ihren Vorstellungen.Ihr Michael Stalhttp://www.javaspektrum.de