Das Performance Prinzip

Was habe ich über Performance zu sagen? Eine ganze Menge. Es gibt viele Details und viele Wege sich dem Thema zu nähern. Aber im Grunde sind es „nur“ ein paar einfache Prinzipien, die man verstehen muss. Die erkläre ich gerne anhand von einfachen metaphorischen Beispielen. Um die passenden Methoden und Vorgehensweisen zu wählen und aus den Ergebnissen die richtigen Rückschlüsse zu ziehen is es vor allem wichtig, diese einfachen Prinzipien zu verstehen und anzuwenden. Daher finde ich, dass solche vereinfachenden Beispiele dies am besten verdeutlichen. Ich versuche hier zumindest einige von diesen Prinzipen zu erklären und beginne mit dem was ich das Performance Prinzip nenne, welches ich gerne anhand eines einfachen Beispiels erkläre, meinem „Bäckerei Beispiel“:

Das Prinzip, wie sich die Performance einer Transaktion insbesondere unter der Einbeziehung der Dimension Last verhält ist im Grunde immer und für jede Transaktion gleich.

Abstrakt gesprochen ergibt sich die Performance einer Transaktion aus der Menge der zu verrichtenden Aufgaben bzw. der dafür benötigten Ressourcen und der Menge der zur Verfügung stehenden Ressourcen. Wobei verschiedene Aufgaben auch verschiedene Ressourcen benötigen können.

Aber das ist alles sehr Abstrakt, deshalb will ich das ganze anhand einer kleinen Analogie etwas zum Leben erwecken.

Wir stellen uns eine Bäckerei vor. In der arbeiten 2 Fachverkäuferinnen und ich betrete morgens diese Bäckerei um meine Brötchen zu kaufen. Für die Abwicklung der Transaktion „Brötchen kaufen“ in dem System „Bäckerei“ wird eine Minute benötigt. Bestandteil dieser Transaktion ist:

• Die Aufgabe der Bestellung durch mich
• Die Annahme der Bestellung durch eine der Verkäuferinnen
• Das Einpacken und übergeben der Brötchen
• Und das kassieren.Betritt nun mit mir ein 2. Kunde den Laden, so kann meine Bestellung weiterhin optimal durchgeführt werden. Das gleiche gilt für den 2. Kunden. Für uns beide wird die Bestellung jeweils eine Minute dauern, da auch für den 2. Kunden noch optimal viele Ressourcen (die 2. Verkäuferin) zur Verfügung stehen.Wir nennen dies den „elastischen Bereich“, weil in diesem Lastbereich noch jederzeit ausreichend von allen benötigten Ressourcen zur Verfügung stehen auch wenn die Last innerhalb dieses Bereiches erhöht wird.Steigern wir die Last weiter, so ergeben sich bei 4 Kunden ca. 1,5 Minuten bei 5Kunden auf ca. 1,8 Minuten usw.Soweit, so gut. Es gibt aber noch eine weitere Grenze, die von großer Bedeutung ist. Im stabilen Bereich scheint die Antwortzeit unter einer bestimmten Last voraussehbar, weil sich die Erhöhung der Antwortzeit ja anscheinend Linear mit der Erhöhung der Last entwickelt. Aber Vorsicht! In ausnahmslos jedem System gibt es auch noch einen Punkt, an dem die Verarbeitung gestört wird.Unser System Bäckerei wäre an diesem Punkt überlastet. Wir sprechen daher vom Überlastbereich.In einem Last- und Performancetest geht es uns also in der Regel darum diese Punkte zu finden, in denen das System jeweils von einem Bereich in den nächsten übergeht, denn anhand dessen können wir zumindest 3 grundlegende Feststellungen treffen:
• Diese drei Bereiche sind im Prinzip immer und für jede Transaktion in jedem System gültig und vorhanden. Leider können wir niemals ohne Test sagen wie groß der jeweilige Bereich ist. Manchmal ist er auch gar nicht messbar. Hätte es in unserer Bäckerei beispielsweise nur eine Verkäuferin gegeben, so hätten wir den elastischen Bereich beispielsweise gar nicht messen können.
• In unserer Bäckerei würde beispielsweise der 10. Kunde in der Schlange nach 3. Minuten nervös werden und den Laden verlassen, weil er fürchtet seinen Bus zu verpassen. Wir hätten also einen Timeout. Ebenso ist es möglich, dass die unruhigen Kunden in der Schlange beginnen laut zu werden und die Verkäuferinnen dadurch nervös machen wodurch sie beginnen kleine Fehler zu machen und sich die Transaktion verlangsamt.
• Diesen Lastbereich nennen wir den stabilen Bereich, da hier gilt erhöht sich die Last, erhöht sich auch die Antwortzeit. Das ist das Prinzip, dass wohl den meisten Menschen spontan einleuchtet.
• Aber gehen wir weiter und nehmen an, dass zudem ein 3. Kunde die Bäckerei betritt um Brötchen zu kaufen. Nun wird es interessant. Denn zwar kann ich weiterhin meine Brötchen in einer Minute kaufen. Der 2, Kunde ebenso. Jedoch der 3. Kunde hat Pech. Er muss eine Minute warten, bis ich oder der 2. Kunde fertig bedient sind und kann erst dann seine Aktion starten. Er wird also insgesamt 2 Minuten benötigen um Brötchen kaufen zu können. Die Durchschnittsgeschwindigkeit für die Transaktion „Brötchen kaufen“  ist nun nach weiterer Erhöhung der Last also auf ca. 1,33 Minuten gestiegen.
• Die Last auf dem System „Bäckerei“ hat sich also nun erhöht von einem Brötchenkauf pro Minute auf 2 Brötchenkäufe pro Minute. Die durchschnittliche Performance ist jedoch mit 1. Minute gleich geblieben.
• Die Zeit von einer Minute stellt also die optimale Performance für die Transaktion „Brötchen kaufen“ dar, da alle benötigten Ressourcen (In diesem Fall die Verkäuferin) optimal und vollständig zur Verfügung standen.

1. Wie gut (schnell) ist eine Transaktion im besten Fall. In unserem Beispiel 1 Minute, die Performance im elastischen Bereich
2. Wie hoch ist die maximale Kapazität des Systems. Das ist die verarbeitete Menge Transaktionen an dem Punkt kurz bevor der elastische Bereich verlassen wird. In unserem Beispiel also 2 Brötchenverkäufe pro Minute
3. Wie hoch ist die angeforderte Belastung, die das System fehlerfrei verarbeiten kann. In unserem Fall also 9 Kunden/Minute

Um die Performance und die Kapazität des Systems jedoch beurteilen zu können reicht dies nicht aus. An diesem Punkt werden die Anforderungen zentral, denn wenn ich nicht weiss, mit wie vielen Kunden ich in dieser Bäckerei rechnen muss und wenn ich nicht weiß, ab welcher Dauer ein Kunde vielleicht nie wieder in meinen Laden kommt, kann ich nicht sagen ob die Performance meiner Bäckerei gut oder schlecht ist.

Liegen mir diese Anforderungen jedoch vor, so kann ich dieses beurteilen. Und daraus wiederrum kann ich ggf. auch Maßnahmen ableiten, um die Performance oder die Kapazität zu erhöhen.

In diesem Beispiel wurde die Ressource „Verkäuferin“ zum Bottleneck. Vielleicht kann ich durch gute Schichtpläne dafür sorgen, dass eine 3. Oder 4. Verkäuferin in den bekannten Stoßzeiten anwesend ist. Oder ich schaue mir an, ob die Verkäuferin vielleicht unnötige Aufgaben hat um die Transaktion grundsätzlich zu beschleunigen.

Hier konnte ich bisher nur andeuten, welch wichtige Rolle die Anforderungen spielen um aus den Ergebnissen eines Performancetests auch nutzbringende Maßnahmen ableiten zu können. Ich denke dieses Thema ist so groß, dass ich dazu irgendwann mal einen eigenen Beitrag schreiben werde.

Das gleiche gilt für die Frage nach den geeigneten Maßnahmen. Pauschale Änderungen am System wie mehr CPUs oder mehr Speicher ohne die Bottlenecks seines Systems zu kennen sind tendenziell Geldverschwendung.

Diese Beispiel habe ich auch schon einmal ein einem Artikel auf www.performanceblog.org erklärt zu finden unter https://performanceblog.org/?p=44