Die 10 schlimmsten Performance-Bremsen

Bernd Greifeneder, Gründer und Chief Technology Officer von DynaTrace, geht für Computerworld den zehn häufigsten Performance-Bremsen auf den Grund. Sein Unternehmen DynaTrace hat sich auf Performance-Optimierung und Business-Transaktionsmanagement spezialisiert. Lösungen, die echten Business-Mehrwert bringen sollen, müssen laut Greifeneder das Gesamtesystem überwachen (full coverage), Geschäftsprozesse end-to-end vermessen und Problemanalysen mit dem nötigen Tiefgang (bis auf Quellcode-Level) durchführen. In der Schweiz gehören der Gesundheitsversicherer CSS, die Mobiliar und die UBS zum Kundenstamm. Der Schweizer IT-Dienstleister Centris habe mithilfe von DynaTrace seine Performance um 90 Prozent steigern können, sagt Greifeneder. Woran liegt es, wenn die IT den Geduldsfaden der Anwender mal wieder extrem strapaziert?

Das am häufigsten auftretende Problem sind zu viele Datenbankzugriffe pro Anfrage oder Transaktion. Das kann mehrere Ursachen haben: Entweder werden mehr Daten von der Datenbank angefordert als nötig - zum Beispiel alle Kundendaten anstatt nur die tatsächlich für die Anzeige erforderlichen - oder es werden unnötigerweise dieselben Daten mehrfach angefordert. Die dritte Problemursache: Abfragen zur Datenbank laufen ineffizient über mehrere Queries, obwohl dasselbe Resultat über ein einziges Query erzielt werden könnte.

Synchronisation ist notwendig um den Zugriff auf gemeinsame Daten zu schützen. Entwickler tappen aber leicht in die Falle der Übersynchronisierung, synchronisieren also zu grosse Codeteile. Unter geringer Last (etwa am lokalen Entwicklungsrechner) kommt es hierbei zu keinerlei Performance-Problemen. In der Lastumgebung oder im Echtbetrieb lösen jedoch nicht optimal implementierte Synchronizationsblöcke Performance- und Skalierungsprobleme aus.

Moderne Bibliotheken machen Remote-Kommunikation zum leichten Spiel. Für den Entwickler macht es meist keinen Unterschied, ob er eine lokale Methode oder eine Methode über ein Objekt in einer anderen Anwendung aufruft. Latenz, Serialisierung, Netzwerkverkehr und Speicherverbrauch für die Remoteaufrufe wird hierbei jedoch leicht unterschätzt. Die leichtfertige Verwendung von Remote-Technologien führt zum massiven Kommunikations-Overhead zwischen den einzelnen Endstellen. Performance- und Skalierungsproblemen sind die Folge.

Object-Relational Mapper nehmen dem Entwickler die lästige Arbeit des Ladens und Speicherns von Objekten in der Datenbank ab. Wie bei jedem anderen Framework auch gibt es eine Vielzahl an Konfigurationseinstellungen, um den Einsatz des Frameworks für den bestehenden Anwendungsfall zu optimieren. Falsche Einstellungen führen zu ineffizienter Nutzung der Datenbank und des Speichers.

Verwaltete (managed) Laufzeitumgebungen wie Java und .NET nehmen zwar lästige Details bei der Speicherverwaltung ab - sie schützen jedoch nicht vor Memory Leaks. Objekte, die ,,herumliegen", belegen unnötig Speicher und können schlussendlich zu "Out of Memory"-Exceptions führen. Es ist daher wichtig, Objekte frühestmöglich freizugeben und sicherzustellen, dass es keine versteckten Referenzen auf diese Objekte gibt. Weiter gehts auf der nächste Seite.

Resourcen wie Speicher, CPU, I/O-Kanäle oder die Datenbank sind nur begrenzt verfügbar. Der verschwenderische Umgang mit ihnen führt dazu, dass Anwender nicht zeitnah bedient werden können. Ein weit verbreitetes Beispiel ist die zu lange Verwendung von Datenbankverbindungen. Verbindungen sollen nur so lange in Anspruch genommen werden, wie sie auch tatsächlich - zum Beispiel für eine Abfrage - benötigt werden. Viel zu häufig werden Verbindungen aber zu früh angefordert und zu spät freigegeben, was klassische Bottleneck-Problemen nach sich zieht.

Breitband verschafft vielen Endanwender eine reichere Erfahrung im Web. Die schnellere Bandbreite verführt jedoch dazu, Web-Anwendungen aufzublasen und damit wieder langsamer zu machen. Vor allem für Anwender mit langsameren Zugängen wird dadurch das Browsen zur Qual. Zu viele und zu grosse Bilder, falsche oder fehlende Verwendung von Client-Side-Caching oder eine zu aggressive Verwendung von JavaScript/AJAX führen oft zu Performance-Problemen im Browser des Endanwenders. Die aufmerksame Adaption bestehender Best-Practices im Bereich Web Site Performance Optimization beugt diesen Tempobremsen vor.

Objekte im Speicher zu halten - anstatt sie ständig von der Datenbank anzufordern - ist eine praktikable Möglichkeit, die Performance zu optimieren. Speichert man allerdings zu viele, also auch nur sporadisch benötigte Objekte, im Cache-Speicher, werden die Vorteile des Cachings zunichte gemacht. Ganz im Gegenteil: Der Aufwand für Speicher und Garbage Collection steigt.

Bei der Remote-Kommunikation - zum Beispiel via Web Services, Remote Method Invocation (RMI) oder der Windows Communication Foundation (WCF) - werden Objekte vor der Übermittlung serialisiert. Der Empfänger de-serialisiert die gesendeten Objekte wieder. Auf beiden Seiten stellt diese Art der Transformation einen nicht zu unterschätzenden Overhead dar. Es ist deshalb wichtig, sich genau zu überlegen, welcher Serialisierungstyp zum Einsatz kommen soll, um Sender und Empfänger gleichermassen zufrieden zu stellen. Unterschiedliche Serialisierungsoptionen haben ganz unterschiedliche Auswirkungen auf die Performance, den Speicherverbrauch und die Netzwerkauslastung.

Schon lange programmieren Software-Entwickler nicht mehr jede Funktionalität einer Applikation selbst, sondern greifen auf Bibliotheken von Drittherstellern zurück. Dieses effiziente Vorgehen erhöht jedoch nicht nur die Produktivität, sondern auch das Risiko von Performance-Problem.Denn wie die 3rd-Party-Bibliothjeken intern funktionieren, bleibt häufig im Dunkeln. Vor der Verwendung empfiehlt sich daher eine gründliche Analyse der Libraries.