Follow my new blog

Donnerstag, 7. Februar 2013

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.

image

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.

image

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.

Kommentare:

Anonym hat gesagt…

Die Darstellung ist vollkommen richtig für die betrachteten Szenarien.

Was ist eigentlich Performance? Allein Zeit (die Performance ist umso besser, je geringer die Zeitspanne)? Oder geht es Informationsmenge pro Zeit?

Es gibt aber auch andere Systeme als die von dir beschriebenen und dort gelten andere Bedingungen und Ansprüche an "Performance".

Der Auslöser kann übringens auch an Performance interessiert sein, wenn er durch langsame Empfänger beeinflusst wird (Rückstau). Der Auslöser hat nicht wirklich "Interesse", wird stattdessen negativ beeinflusst bzw. man muss Vorkehrungen treffen um das abzufangen bzw. man beschleunigt die Empfangsseitw.

Ralf Westphal - One Man Think Tank hat gesagt…

Hm... Ich denke, ein Auslöser so wie hier beschrieben, kann nicht durch den Empfänger beeinflusst werden. Es kann auch keinen Rückstau geben.

Es geht ja um den Moment einer Datenveränderung. Auslöser ist der, der die ins System einpflegt, z.B. durch Eintragung in einen Dialog und dann klicken. Oder Auswahl einer Datei für den Import und dann klicken.

Das ist das auslösende Ereignis. Was interessiert ihn da ein Empfänger, also einer, der die Daten verarbeiten will?

Auf technischer Ebene mag es blocking queues geben. Da wird einer eingefroren, der Daten in eine Queue stellen will, solange bis wieder ein Platz in der Queue frei ist.

Aber da sind wir bei einem anderen Szenario. Da geht es nicht um die Verarbeitung, sondern eben um den Start der Verarbeitung, also die Übernahme von Daten in die eigentliche Verarbeitung. Da ist der Auslöser interessiert daran, dass das in jedem Fall schnell geht, weil er der Empfänger des "Ack" ist.

Eine bounded queue, die blockieren kann, ist da misslich. Sowas ist ja aber gegenüber menschlichen Benutzern eher kein Problem. Einen User kann ich immer schnell zufriedenstellen, indem ich seine Datenerfassung in eine quasi beliebig große Queue stelle.

Das tut man nur so selten. Zu selten, finde ich. Das Potenzial durch Latenzverbergung statt Latenzverringerung wird nicht ausgeschöpft. Weil User in einem "Synchronizitätswahn" leben. Sie wollen ganz einfach, dass bei nicht nur die Verarbeitung angestoßen wird, sondern auch gaaaanz schnell abgeschlossen wird. Weil sie das so wollen. Einfach so. Es muss! Wie kleine Kinder, die auch was wollen. Da ist ne Menge Aufklärnungsarbeit nötig.

McZ hat gesagt…

Ich bin ein wenig baff, muss ich gestehen. Und ich fühle, hier werden Dinge vermischt, die nur periphär miteinander zu tun haben.

Zunächst mal ist für mich Performance = Produktivität = Output / Input. Es ist dabei für Amazon als Besitzer der Serverinfrastruktur sehr wohl wichtig, wie viele Transaktionen pro Sekunde auf einer gegebenen Hardware verarbeitet werden können.

Etwas anderes ist die Wirtschaftlichkeit. Wenn ich jede Transaktion um 1 Sekunde beschleunige, meine Ressourcen-Sekunde 0,5 ct kostet und der Entwickler 10 Mannstunden a 100 € benötigt, dann habe ich eine klare Aussage, ob und wann eine Änderung etwas bringt oder nicht. Leider ist es häufig so, dass keinerlei Zahlenmaterial vorliegt, so dass hier meistens nach rein subjektiven Gesichtspunkten reagiert wird.

Davon unbhängig ist die messbare oder gefühlte Reaktivität einer Benutzeroberfläche. Wie viele Applikationen gibt es, die heute noch komplette Tabellen in ein Grid laden und währenddessen das GUI blockieren? Oder die beim Speichern einen ablaufenden Workflow in-process abwickeln? Beides führt für den Benutzer natürlich dazu, dass er wartet, und beides rüttelt an der Akzeptanz der Software.

Es gib auch Schnittmengen. Bei Web-Applikationen sind niedrige Seitenerzeugungszeiten für beide Seiten vorteilhaft. Dabei kommt Amazons Wunsch, möglichst viele Seiten möglichst schnell auszuliefern dem Wunsch des Empfängers entgegen, die Seite möglich schnell zu laden.

Ein völlig getrennter Sachverhalt ist das Weitergeben von Datenänderungen. Das würde ich unter dem Begriff Kollaboration einordnen. Dabei sind zwei Faktoren für mich ausschlaggebend: sachliche Zwänge und Prozesseffizienz.

Nehmen wir an, ich möchte eine Reise buchen. Ich habe lange überlegt, ob ich mir die leisten kann und will. Dann rufe ich dass Buchungsportal auf, es sagt 500 €, das ist OK. Genau in diesem Moment wird der Preis auf 600 € geändert, nicht OK. Aber ich merke davon nix, bin schon bei der Eingabe der Personendaten. Betrug!, rufe ich, als ich die Auftragsbestätigung lese. Das Landgericht stimmt mir zu.

Wenn ich einen Geschäftsprozess habe, dann ermöglicht eine Benachrichtigung der nachfolgenden Stelle über den Abschluss eines Prozessschritts eine schnelle Reaktion.

Dass diese Benachrichtigung für den Datenerfasser asynchron erfolgt, also eben nicht in-process, ist leider aber keine Selbstverständlichkeit.

Ralf Westphal - One Man Think Tank hat gesagt…

@McZ: Ich hab doch nix gegen Reaktivität. Ich hab sogar betont, dass die wichtig ist: da sind Auslöser und Empfänger nämlich dieselbe Person.

Durch die Trennung der beiden Rollen habe ich es zumindest für mich besser erklärbar gemacht, wann welche Performance wichtig ist.

Was muss für Reaktivität hohe Performance haben? Wenn ich eine Query absetze, dann muss die Query hohe Performance haben - aber nicht das Einpflegen von Daten. Und wenn ich Daten einpflege, dann muss nur die Annahme der Daten hohe Performance haben, aber nicht die komplette Bearbeitung.

Und was den Fall mit der Reisebuchung angeht: Der hat nichts mit Performance zu tun, sondern mit Konsistenz. Das gilt ja auch im Laden: wenn am Regal 28,99 EUR steht, dann darf an der Kasse nicht 29,99 EUR abgerechnet werden. Ist mir neulich so passiert - und der Laden hatte kein Problem mit der Korrektur, als ich ihn darauf aufmerksam gemacht habe.