Performanceprobleme – Lokalisieren des Problems

Jeder Software Architekt oder Entwickler kann in die Situation kommen, dass die implementierte Lösung partout nicht performt, wie man sich vorgestellt hat. Die heutige Informatikwelt ist so komplex, dass es oft schwer fällt, genau sagen zu können, wo eine Applikation langsam wird und eine gewisse Zeit benötigt für einen Request. Wenn man eine Webapplikation hat, die als VM in einer geteilten Serverlandschaft läuft, und welche dann mit etlichen Threads eine bestimmte Aufgabe in einer Datenbank vornehmen muss, wie soll man da noch wissen, wo Zeit verloren geht? Oder liegt es vielleicht doch an diesem unscheinbaren Webservice Aufruf, der mir eigentlich zu einer ID nur den Kundennamen geben soll? Oder ist die Datenbank nicht richtig indexiert?

Gelobt seien Monitoring Tools

Glücklich kann sich dann schätzen, wer ein Monitoring Tool verwenden kann, welches bei einem Aufruf genau auflistet, welche Zeit von einer Komponente zur nächsten vergeht. Am Besten noch hübsch mit grünen/gelben/roten Balken visualisiert.

Falls man dieses Glück nicht hat, muss man sich selber helfen. Der erste Schritt dabei ist, herauszufinden, wo die Zeit verloren geht. Dazu erstellt man möglichst viele Logging Einträge in seinem System, welche detailliert Aufschluss geben soll.

Nutzt man etwa in Java eine Logging Library wie SLF4J gibt es die Möglichkeit, Logging Einträge nur auszugeben, wenn der DEBUG Modus eingeschalten ist. So kann man die Applikation im Normalmodus im INFO Modus mit einer geringen Anzahl von Logeinträgen laufen lassen. Muss man nun die Performance untersuchen, setzt man den Logging Level auf DEBUG und erhält gleich viel mehr Einträge in seinem Applikationslog.

START und ENDE loggen

An möglichst vielen Stellen soll dabei jeweils ein START und ein END Logeintrag erstellt werden, um die vergangene Zeit herausfinden zu können.

Hier etwa sehen wir, dass die Kontoerstellung genau 100 Millisekunden gedauert hat:

21.10.2016 – 04.40.20.103 – T1400 – START Konto erstellen
21.10.2016 – 04.40.20.203 – T1400 – ENDE Konto erstellen

Dies hört sich trivial an, doch habe ich schon viele Beispiele gesehen, wo zwar der START Eintrag, jeder weitere Logeintrag aber nur in einem Fehlerfall geschrieben wurde. Der „Normalfall“, der erfolgreiche Fall wurde einfach vergessen. Oder es wurde gesagt: „Ist ja logisch, wenn der folgende START Eintrag kommt, der vorherige zu Ende“. Warum einfach, wenn es auch kompliziert geht?

Threads nicht vergessen

Vergessen Sie auch nicht, dass mehrere Threads in dasselbe Logfile schreiben können, wenn Sie nur ein Logfile pro Applikation oder pro Server haben. In diesem Fall gibt man beim Logeintrag die Thread-ID gleich mit an, um die Einträge auseinanderhalten zu können – Im Beispiel oben etwa sind die beiden Einträge vom Thread mit der ID T1400 gschrieben worden.

Auch müssen Sie aufpassen, dass sich in Ihrem Code kein „Synchronized“ Block befindet, welcher als Flaschenhals fungiert und die Threadverarbeitung so bremst.

performanceproblemelokalisierendesproblemsgliffy

Klick mich für das Bild in gross

Die roten Pfeile in diesem Bild sollen jeweils ein START und ENDE Paar darstellen. Natürlich ist der Einsatz dieser Logeinträge pro Applikation individuell.

Wenn ich mal einen konkreten Fall dokumentieren kann werde ich diesen hier anfügen.

Software Architektur Grundprinzipien

Folgende Grundprinzipen können einem Software Architekten helfen, den Prozess der Applikationserstellung besser zu verstehen und sich während eines Projektes korrekt zu verhalten – beziehungsweise sich keine Sorgen zu machen, wenn die angestrebte Architektur überhaupt nicht so funktioniert, wie man es geplant hat. In diesem Fall heisst es: Kühlen Kopf bewahren und mit allen involvierten Projektmitgliedern eine Lösung zu finden.

  • Sie sollten sich in jedem Fall über mögliche Wiederverwendung informieren: Wer hat eine ähnliche Aufgabe vor Ihnen gelöst und wie? Sammeln Sie Lösungsideen, anstatt immer neu zu entwerfen.

 

  • Seien Sie sich als Softwarearchitekt der Tatsache bewusst, dass Sie die Konsequenz mancher Ihrer Entscheidungen erst viel später bewerten können.

 

  • Eine essenzielle Leistung von Architekten besteht darin, die für eine bestimmte
    Aufgabe nicht benötigten Informationen gezielt wegzulassen, zu abstrahieren.

 

  • Design bezeichnet den Prozess der Erstellung der Architektur.

 

  • Am besten treffen Architekten ihre Entwurfs- und Technologieentscheidungen in einem Team, statt alleine über eine Situation zu grübeln.

 

  • Als Diplomaten schliessen Architekten Kompromisse zwischen widersprüchlichen oder konkurrierenden Forderungen.

 

  • Gute Softwarearchitekten zeichnen sich dadurch aus, dass sie ihre Ideen, Entwürfe und Entscheidungen aktiv an die übrigen Projektbeteiligten kommunizieren können.

 

  • Heuristik bezeichnet die Kunst, mit begrenztem Wissen (unvollständigen Informationen) und wenig Zeit dennoch zu wahrscheinlichen Aussagen oder praktikablen Lösungen zu kommen.

 

  • Oft erleichtern Architekten dem Team die ungeliebten Dokumentations- und Kommunikationsaufgaben.

 

Noch mehr software Architektur Prinzipien

Microservices Einführung

Jeder moderne Software Architekt sollte wissen, um was es sich beim Thema Microservices handelt. Man findet im Internet alle möglichen technischen Erklärungen dafür, dabei ist es überhaupt nichts Übersinnliches.

Die simpelste Erklärung ist: Ein Microservice ist eine Einheit für sich, hat genau eine spezifische Aufgabe, und kann in nicht mehr als zwei Wochen gebaut werden.

Dies scheint wirklich zu einfach zu sein, nicht wahr?

Schauen wir uns drei wichtige Punkte dazu genauer an:

  1. Ein Microservice fokussiert sich auf genau eine Aufgabe, ähnlich der Kohäsion einer Methode oder einer Klasse. Wenn etwa Amazon als Microservice gebaut werden würde, dann gäbe es genau ein Modul für das Kaufen und Verkaufen eines Artikels, ein Modul für die Anzeige und das Hinzufügen der Benutzerkommentare etc. Im Gegenzug dazu sind die meisten Applikationen heutzutage grosse, schwere Kreuzer, die über Jahrzehnte gewachsen sind und innerlich sehr vernetzt sind.

  2. Microservices laufen für sich alleine, unabhängig von anderen Modulen. Wenn ein Microservice also abstürzt, wenn man andere Teile der Applikation ändert, ist es dieser nicht gut designt.

  3. Einer der wichtigsten Punkte ist allerdings: Ein Microservice ist in kurzer Zeit zu erstellen und in genauso kurzer Zeit nochmals zu erstellen. Wie oben geschrieben, spricht man von einer Zeitspanne von etwa zwei Wochen. Warum man einen Service nochmals schreiben sollte, fragen Sie? Nun, stellt man fest, dass der Microservice entweder das falsche macht oder ganz einfach nicht mehr aktuell ist, kann dieser in kurzer Zeit durch ein modernes Pendant ersetzt werden. Dies gilt natürlich auch für Performance: Läuft ein Microservice nicht schnell genug, kann dieser in kürzester Zeit durch eine neue Variante ersetzt werden.

Dazu kommt, dass jeder Microservice für sich ein API zur Verfügung stellt, welches unabhängig von der verwendeten Sprache oder Technologie ist. Dies bedeutet beispielsweise, dass man bei Amazon die ganze Applikation mit Java & Spring bauen könnte bis auf den wichtigsten Teil, das Anzeigen der Werbung. Weil dieser Teil für das Business unglaublich wichtig ist, wird dieser kurzerhand in C++ geschrieben, um sicherzustellen, dass dieser gut performt.

Dasselbe gilt natürlich auch für die dahinterliegende Datenbank. Für die Artikel könnte man eine MongoDB verwenden, während ein anderer Teil mit Oracle arbeitet.

Fokussierte Teams

Was nun bei Microservices dazukommt ist die kleiner granulierte Organisation. Statt ein grosses Team zu haben, welche die Herrschaft über alle Services hat, arbeiten viele kleine Teams an einer überschaubaren Anzahl von Microservices.

Fazit

Diese Einführung sollte reichen, um eine Idee zum Thema Microservices zu erhalten.