Systemcheck: 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?

1) Unnötig viele Datenbankabfragen

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.

2) Zu Tode synchronisiert

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.

3) Zu viele Remote-Verbindungen

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.

4) Inkorrekte Verwendung von O/R-Mapper

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.

5) Memory Leaks

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.