Letztes Mal habe ich über die Bedeutung von Überwachung und Diagnose in der Produktion gebloggt, um Vorfälle schnell zu lösen und zukünftige Probleme zu vermeiden. Dieses Mal spreche ich über Tuning auf der Grundlage von Beweisen. Wenn sich eine Anwendung als zu langsam erweist, kann Tuning eine Lösung sein. Das Tuning kann auf mehreren Ebenen erfolgen. Das Hinzufügen von Hardware kann eine billige Lösung sein. Wenn Sie jedoch Hardware an einer Stelle hinzufügen, an der sich der Engpass nicht befindet, hat dies wenig Sinn.
Wichtige Schritte bei der Optimierung sind daher die Identifizierung der Seiten oder Dienste, die die angegebenen Anforderungen nicht erfüllen, und die Isolierung des Problems: wo befindet es sich, in welcher Schicht, in welcher Komponente. Dies kann durch Tests und Überwachung von Anwendungsteilen deutlich gemacht werden. Der nächste Schritt ist die Diagnose. Im Grunde genommen geht es darum, eine Hypothese aufzustellen, warum diese Komponente so langsam ist.
Abbildung 1. Performance-Tuning-Zyklus. Dies kann zum Beispiel ein fehlender oder falscher Index auf einer Datenbanktabelle oder der Aufruf zu vieler kleiner Abfragen sein. Als nächstes wird die Komponente auf der Grundlage dieser Hypothese verbessert. Schließlich muss überprüft werden, ob die Verbesserung tatsächlich den erwarteten Geschwindigkeitszuwachs bringt. Wenn ja, dann ist die vorgeschlagene Hypothese wahr und der Geschwindigkeitszuwachs ist das Ergebnis. Wenn nicht, dann stimmt etwas mit der Hypothese nicht und wir brauchen eine alternative Hypothese. Sobald die Leistung des Systems den Anforderungen entspricht, ist die Optimierung abgeschlossen.
Abbildung 2. Beweise finden. Die richtigen Tools sind unverzichtbar: Leistungstesttool, Enterprise Profiler, Heap Monitor usw. Ich habe gesehen, wie Entwickler an vermeintlichen Leistungsverbesserungen gearbeitet haben, die sich als überhaupt nicht hilfreich herausstellten oder die Anwendung sogar verlangsamten und außerdem die Wartbarkeit und Flexibilität verschlechterten. Das liegt daran, dass die Entwickler daran gewöhnt sind, Funktionen aus dem Quellcode zu formen und daher vom Quellcode aus arbeiten, um die Leistung zu verbessern. Was hier fehlt, ist das Messen, nicht das Raten. Das ist etwas, das Entwickler in meinem Performance-Training lernen. Die Erfahrung hat mich auch gelehrt, jeden Verbesserungsvorschlag einzeln zu beurteilen und die Verbesserung nur dann umzusetzen, wenn wir bewiesen haben, dass sie wirklich hilft. Ohne diesen systematischen Ansatz kann eine Handvoll Schritte zusammengenommen Sie am Ende des Tages zurück statt vorwärts bringen. Nächstes Mal werde ich über die gemeinsame Verantwortung für die gesamte Kette sprechen.
Verfasst von
Jeroen Borgers
Contact



