Das Performance Prinzip

Als ersten Eintrag in unserem neuen Blog möchte ich mal was allgemeines schreiben. Ich nenne es das Performance Prinzip, welches ich gerne anhand eines einfachen Beispieles 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.

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.

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.

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.

Wir nennen dies den „elastischen Bereich“, weil in diesem Lastbereich noch jederzeit ausreichend von allen benötigten Ressorcen zur Verfügung stehen auch wenn die Last innerhalb dieses Bereiches erhöht wird.

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.

Steigern wir die Last weiter, so ergeben sich bei 4 Kunden ca. 1,5 Minuten bei 5Kunden auf ca. 1,8 Minuten usw.

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.

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.

In unserer Bächerei 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.

Unser System Bäckerei wäre an diesem Punkt überlastet. Wir sprechen daher vom Überlastbereich.

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 gross 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 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:

  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 Massnahmen 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, wech 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 gross, dass ich dazu irgendwann mal einen eigenen Post 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 System zu kennen sind tendenziell Geldverschwendung.

Bis zum nächsten Mal

Sancho

1 Gedanke zu “Das Performance Prinzip”

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.