Performance vom Schwanz her aufzäumen

Wer ist es eigentlich, der höhere Performance fordert? Der Kunde, ist doch klar. Den meine ich aber nicht. Mir geht es um etwas Grundlegenderes.

Wenn wir über Performance reden, dann haben wir ein Delta im Hinterkopf, eine Dauer zwischen zwei Ereignissen. Es geht um ein auslösendes Ereignis, an dem Input hängt, und ein abschließendes Ereignis, an dem Output hängt.

Das kann die Dauer zwischen der Eingabe einer URL und der Anzeige der Webseite sein; das kann die Dauer zwischen der Eingabe von Zahlen und der Anzeige einer Funktionskurve sein; das kann die Dauer zwischen dem Bewegen eines Mauszeigers und der Reaktion einer Figur auf dem Bildschirm sein.

Immer geht es um Delta = T_Ergebnis – T_Auslöser. Höhere Performance bedeutet, dass Delta kleiner wird.

Jetzt zurück zur Ausgangsfrage: Wer fordert denn aber, dass Delta kleiner wird?

Es sind zwei Rollen im Spiel: der Auslöser und der Empfänger. Der Auslöser startet die Verarbeitung, deren Performance in Frage steht. Er liefert den Input oder zumindest Teile davon; der Rest kann aus Zustand kommen, auf den die Verarbeitung Zugriff hat.

Der Empfänger andererseits ist derjenige, den das Ergebnis der vom Auslöser gestarteten Verarbeitung interessiert. Er betrachtet den Output und fällt daraufhin Entscheidungen. Output ist ein Unterschied, der für ihn einen Unterschied macht, d.h. Information.

Nun zum dritten Mal: Und wer interessiert sich nun für ein kleineres Delta? Immer nur der Empfänger.

Das ist mir heute aufgegangen. Es ist immer nur der Empfänger von Output, dem daran gelegen sein kann, den Abstand zum auslösenden Ereignis zu reduzieren, weil das irgendeinen Vorteil für ihn hat.

Es hat lange für mich gedauert, bis ich das begriffen habe. Bis heute. Jahr um Jahr hab ich geglaubt es sei der Auslöser, den Performance interessiert. Oder genauer: Ich habe Auslöser und Empfänger nicht einmal unterschieden. Sie sind oft dieselbe Person oder ich habe vor allem mit dem Auslöser als Kunde gesprochen.

Aber es gibt in Performancefragen immer beide Rollen und nur der Empfänger ist maßgeblich.

Das hat nun Auswirkungen auf die Performancediskussion, würde ich sagen. Denn eine Steigerung der Performance ist nur da relevant, wo ein Empfänger erstens eine Ahnung davon hat, wann das auslösende Ereignis vor dem Empfang stattgefunden hat. Oder es ist generell von Wert, dass das Delta zwischen Auslöser und Empfang klein ist, auch wenn unklar ist, wann das auslösende Ereignis stattgefunden hat. Beispiele:

• Sie sind Empfänger von Informationen über Bücher. Die Performance ist für Sie dabei vor allem wichtig, wenn Sie Auslöser der Beschaffung dieser Informationen sind. Sie stöbern bei amazon und wünschen sich natürlich möglichst zügig ein Abfrageergebnis. In dieser Doppelrolle ist Performance für Sie wichtig.
• Sie sind wieder Empfänger von Informationen über Bücher. Dieses Mal haben Sie jedoch keine Kontrolle über eine Auslösung. Das initiale Ereignis für eine Verarbeitung ist nicht eine Abfrage, sondern das Einpflegen von Titelinformationen. In diesem Fall interessiert Sie die Performance des online Shops nicht. Wenn überhaupt, machen Sie sich Gedanken über die Performance von amazon als Organisation mit ihren Prozessen.
• Jetzt sind Sie Empfänger von Adressinformationen in einer Faktura-Anwendung. Sie müssen Kunden mahnen. Was ist das für Sie auslösende Ereignis in Bezug auf Adressen? Das Einpflegen. Damit haben Sie nichts zu tun. Das macht eine andere Abteilung, z.B. der Verkauf, jedenfalls nicht die Buchhaltung. Wie lange das Softwaresystem also braucht, um eine Adresse “zu verarbeiten”, ist für Sie nicht wichtig.
• Auf der anderen Seite sitzt nun der Auslöser einer Adressveränderung. Ist der an der Performance einer Adressenspeicherung interessiert? Nein. Er ist ja nur Auslöser. Wenn er eine Datenänderung erfasst hat, will er nur schnell weiter zur nächsten Datenerfassung. Wie lange es dauert, bis eine Adressenänderung überall wirksam wird, ist ihm einerlei, da er kein Empfänger ist.
• Schließlich sind Sie Geschäftsführer einer Pizzakette. Sie sind Empfänger von Verkaufszahlen. Was ist Ihre Erwartung an die Performance der Unternehmenssoftware? Auf Ihre Abfrage wollen Sie schnell eine Antwort. Da sind sie sowohl Auslöser wie Empfänger. Aber der Auslöser einer Veränderung im Datenbestand sind Sie nicht. Sekunden- oder auch nur stundengenaue Auskunft müssen Sie nicht über die Zahlenentwicklung haben. Ihnen reichen die Zahlen des Vortages oder gar der Vorwoche.

Sie ahnen, worauf ich hinaus will. Ich möchte eine Lanze für mehr asynchrone Verarbeitung brechen. Und ich möchte dafür sensibilisieren, dass Performance im Auge des Empfängers liegt. Die Frage ist immer, was der für ein Verhältnis zu welchem auslösenden Ereignis hat.

Ist das auslösende Ereignis eine Query oder die Ankunft von Daten im System?

Mein Empfinden ist, dass das zu oft nicht unterschieden wird. Der Auslöser wird naiv gleichgesetzt mit dem Empfänger. Und beim Empfänger denkt man nicht an den Unterschied zwischen Datenankunft und Abfrageauslösung.

Solange hohe Performance billig herzustellen ist, macht die fehlende Unterscheidung auch nichts. Wenn Performance aber anfängt die Diskussion zu dominieren, wenn sie sich immer wieder in den Weg der Arbeit an anderen Aspekten wirft, dann sollten Sie genauer hinschauen.

Mir scheinen drei Begriffe dafür interessant: Änderungsfrequenz, Abtastfrequenz und Reaktionszeit.

Die Änderungsfrequenz gibt an, wie häufig sich Daten in relevanter Weise ändern. Mein Lieblingsautor schreibt jedes Jahr ein Buch. Der Benzinpreis ändert sich vielleicht 5 Mal am Tag bei meiner Tankstelle. Die Temperatur draußen ändert sich unter Umständen stündlich.

Wenn für mich diese Ereignisse grundsätzlich interessant sind, so ist nicht unbedingt jedes Ereignis auch relevant. Ich möchte zwar keine Neuerscheinung meines Lieblingsautors verpassen, interessiert mich der Benzinpreis nur alle paar Tage und die Temperatur auch nur gelegentlich während des Tages.

Während die Änderungsfrequenzen 1/Jahr, 5/Tag und 24/Tag sind, sind meine Abtastfrequenzen vielleicht 12/Jahr, 1/Woche und 2/Tag.

Wenn ich häufiger abtaste als das Ereignis eintritt, dann ist mir an möglichst kleinem Verzug gelegen. Besser als solches Polling wäre natürlich eine Benachrichtigung. Leider bietet amazon so etwas bisher nicht an, wenn ich es recht sehe. Beim Buch möchte ich im Mittel also nicht später als 2 Wochen nach Erscheinen (halbe Periode der Abtastfrequenz) darüber informiert sein. amazons Performance muss nur so gut sein, wie mein Anspruch an meine Reaktionszeit ist.

Wenn sich Daten jedoch häufiger ändern als ich abtaste… dann ist mir die Aktualität offensichtlich nicht so wichtig. Zwischen zwei Abtastungen kann sich ja viel ändern. Der Benzinpreis könnte um 50% schwanken, ohne dass ich es merke, auch ohne dass es für mich relevant wäre, weil mein Tank noch so voll ist, dass sich nachtanken nicht lohnte. Was bedeutet das für die Performance der Datenpflege? Ich denke, die Performance ist in diesem Fall nicht so wichtig. Denn ob ich den tatsächlich aktuellen Wert erfahre, wo mich doch zwischenzeitliche Werte nicht interessiert haben, oder einen etwas älteren, weil die Verarbeitung des aktuellen noch nicht abgeschlossen ist, das scheint mir einerlei.

Daraus ergibt sich für mich zusammenfassend:

In Performancefragen ist zuerst zu klären, wer Auslöser und Empfänger einer Datenveränderung sind.

Dass sowohl Auslöser wie Empfänger in Bezug auf ihre unmittelbare Interaktion mit der Software immer beides sind, ist trivial. Dadurch darf man sich nicht verwirren lassen. Wenn einer von beiden einen Befehl absetzt, dann will er schnellstmöglich danach weitermachen. Die Software soll nicht einfrieren. Das ist jedoch unabhängig von den dahinter stehenden Datenänderungen im System!

Wer Daten einpflegt, will nur sicher sein, dass die Daten der weiteren Verarbeitung verlässlich übergeben wurden. Das muss schnellstmöglich geschehen.

Und wer Daten abfragt, der will schnellstmöglich eine Antwort. Wie aktuell die Daten jedoch sind, die in die Antwort eingehen, das ist eine ganz andere Sache.

Zwischen Übergabe an die Verarbeitung und Abfrage kann eine lange Zeit liegen. Nur diese Zeit ist maßgeblich für die Verarbeitungsgeschwindigkeit. Ausschlaggebend ist die gewünschte Reaktionszeit. Denn danach wird sich ein Empfänger für seine Abtastfrequenz richten; die muss seinem Anspruch an Datenaktualität entsprechen.

Performanceoptimierung ist mithin eine Sache des Zugs: Wie oft zieht ein Interessent an den Daten? Wie ist seine Abtastfrequenz in Bezug auf die Änderungsfrequenz der Daten?

Zäumen Sie das Performance-Pferd von diesem Schwanz her auf. Nur wenn die Abtastfrequenz über der Änderungsfrequenz liegt, scheint mir Tuningaufwand gerechtfertigt. Und unterscheiden Sie deutlich zwischen dem, der Datenänderungen anstößt (Einpfleger) und dem, der sie empfängt (Abfrager). Meine Vermutung ist: Sie werden viele Möglichkeiten finden, die Datenverarbeitung asynchron zu machen. Und das ist eine sehr entspannende Aussicht, finde ich.