Wenn üblicherweise ein bestimmter Teil einer Software beschrieben wird, kann die Beschreibung in zwei Abschnitte gegliedert werden - dem Abschnitt WAS und dem Abschnitt WIE. Im Abschnitt WAS wird beschrieben, was dieser Teil des Codes tut. Der Abschnitt WIE gibt an, wie er das tut. Die meisten neigen dazu, sich auf den WAS-Abschnitt zu konzentrieren und den WIE-Abschnitt zu ignorieren. Der Grund dafür ist einfach und in vielen Fällen gerechtfertigt. Indem Sie so vorgehen, reduzieren Sie die Kopplung zwischen Ihren Komponenten und füllen Ihren Kopf nicht mit Informationen, die in vielen Fällen irrelevant sind. In vielen Fällen jedoch kann das Ignorieren des WIE-Abschnitts zu Lasten der Leistung gehen.
Diese Fallstudie untersucht die Art und Weise, wie die Engine geclusterte Metriken berechnet (d. h. wie sie auf den WIE-Abschnitt reagiert) und beschreibt die Leistungskosten für bestimmte Implementierungen. Sie geht auch näher auf einige Möglichkeiten ein, wie diese Kosten durch die Änderung der Implementierung geändert werden kann.
Was sind geclusterte Metriken?
Geclusterte Metriken sind Metriken, die eine bestimmte Gruppe von Ressourcen in ihrer Definition eingebettet haben. Diese Gruppe wird als Cluster der Metrik bezeichnet, und jede der Ressourcen in dieser Gruppe wird als Cluster-Objekt bezeichnet. Wenn man eine geclusterte Metrik berechnet, wird eine gesonderte Berechnung für jedes dieser Cluster-Objekte ausgeführt. Die Berechnungen für jedes dieser Cluster-Objekte entsprechend einander, außer:
So werden geclusterte Metriken berechnet
Das wichtigste, was man bei der Berechnung einer geclusterten Metrik verstehen muss, ist, dass alle Cluster-Objekte parallel berechnet werden. Parallel bedeutet in diesem Fall nicht, dass sie von verschiedenen Threads berechnet werden, sondern, dass die Events während der Verarbeitung zahlreicher Events, die von verschiedenen Cluster-Objekten verarbeitet werden sollten, sequenziell verarbeitet werden. Für jedes Event werden die zugehörigen Cluster-Objekte aufgerufen, die dann dieses Event verarbeiten. Zum Beispiel gibt es viele Events, die von vielen Cluster-Objekten verarbeitet werden sollten. Es gibt zwei Optionen, dies zu tun:
Beispiel: Option 1
Für jedes Cluster-Objekt C
Für jedes Event E, das von C verarbeitet werden soll
Lassen Sie E von C verarbeiten
Beispiel: Option 2
Für jedes Event E
Für jedes Cluster-Objekt C, das E verarbeiten soll
Lassen Sie E von C verarbeiten
Die Engine verarbeitet geclusterte Metriken nach der Option 2.
Ein weiterer wichtiger Punkt, den Sie verstehen sollten, ist, dass die Ausführung des VBScript im PslWriter von einer Komponente mit dem Namen Skript-Steuerelement ausgeführt wird. Es gibt nur eine einzelne Instanz dieser Komponente pro Metrik und diese Instanz wird für die Berechnung zahlreicher Cluster-Objekte wieder verwendet. Da die Cluster-Objekte wie zuvor erwähnt parallel berechnet werden und die Komponente Skript-Steuerelement zu jedem Zeitpunkt nur die Daten eines einzelnen Cluster-Objekts enthalten kann, müssen Sie die Daten in der Komponente Skript-Steuerelement häufig umschalten.
Um diesen Vorgang zu erklären, ist nachfolgend ein detaillierter Pseudocode dargestellt, der die Berechnungen durchführt.
1- Für jede Metrik M 2- Lassen Sie X das früheste Event sein, dass noch nicht von M verarbeitet wurde 3- Lassen Sie T den Zeitstempel des letzten Status vor X sein 4- Lassen Sie L die Liste aller Events sein, die von M registriert wurden (alle Cluster-Objekte), beginnend mit dem Zeitstempel T bis hin zur aktuellen Zeit 5- Für jedes Event E in L 6- Für jedes Cluster-Objekt C, das E verarbeiten sollte 7- Lassen Sie C’ das Cluster-Objekt sein, das gegenwärtig ins Skript-Steuerelement geladen wird 8- Nehmen Sie die Werte der globalen Variablen vom Skript-Steuerelement und speichern Sie sie für C’ 9- Nehmen Sie die Werte der globalen Variablen, die für C gespeichert wurden, und laden Sie sie in das Skript-Steuerelement 10- Verarbeiten Sie das Event E
Dieser vollständige Prozess, um einen Zeitpunkt eines Events zu finden, der noch nicht berücksichtigt wurde, und dann die Berechnung von diesem Zeitpunkt an durchzuführen, wird Neuberechnung genannt. Der Prozess, bei dem die Werte der globalen Variablen ersetzt werden (Schritte 8 und 9 im obigen Code), wird als Kontextumschaltung bezeichnet.
Wie Sie anhand des obigen Codes leicht sehen können, ergeben sich die folgenden beiden Hauptprobleme:
Neuberechnung von geclusterten Metriken
Wie bereits erläutert, werden alle Cluster-Objekte in einer geclusterten Metrik als Ganzes neu berechnet. Dies bedeutet Folgendes: Wenn Sie eine Metrik haben, die in über 1000 Cluster-Objekte geclustert ist, und eines dieser Objekte einer Neuberechnung des letzten Jahres bedarf, da einige neue Events empfangen wurden, dann werden alle 1000 Cluster-Objekte für das letzte Jahr neu berechnet.
Die folgenden Lösungsvorschläge können die Auswirkungen dieses Problems reduzieren. Sie sind jedoch nicht immer anwendbar und jeder Vorschlag hat auch seine eigenen Nachteile. Es ist wichtig, das Problem und seine geschätzten Kosten zu verstehen, und diese Kosten mit den Kosten der vorgeschlagenen Lösungen zu vergleichen.
Kontextumschaltung
Wie bereits erläutert, erfolgt die Kontextumschaltung in der innersten Schleife. Mit anderen Worten, für jedes Event, das von jedem Cluster-Objekt verarbeitet werden sollte. Wenn eine Metrik viele Events empfängt und jedes Event von vielen Cluster-Objekten verarbeitet wird, kann dieser Wert sehr hoch sein. Hinzu kommt noch, dass der Kontextumschaltungsvorgang relativ kostenintensiv ist (im Vergleich zur Verarbeitung des Events selbst in der Business-Logik), und schon haben Sie ein Problem.
Die Kosten des Kontextumschaltungsvorgangs sind proportional zur Größe der Daten, die "umgeschaltet werden". Die Daten, die Sie während der Kontextumschaltung umschalten, sind die Werte der globalen Variablen in Ihrer Business-Logik (auch "der Status" genannt). Je mehr globale Variablen Sie also haben und je größer die Größe dieser globalen Variablen ist, desto kostenintensiver ist der Kontextumschaltungsvorgang.
Es wird vor allem nicht empfohlen, Zuordnungsgrafiken für die Business-Logik in geclusterten Metriken zu verwenden, insbesondere dann, wenn die Größe dieser Zuordnungsgrafiken sehr groß sein kann.
Die Idee dahinter ist, die Statusgröße zu reduzieren (globale Variable). Dies kann ausgeführt werden, indem die Business-Logik neu geschrieben wird, sodass es keine Zuordnungsgrafiken enthält. Natürlich ist dies nicht immer möglich, aber sollte das der Fall sein, wird diese Vorgehensweise empfohlen.
Wenn der Cluster klein ist, ist es möglich, eine gesonderte Metrik für jedes Cluster-Objekt zu erstellen.
Vermeiden Sie geclusterte Metriken mit vielen geclusterten Objekten, die für dasselbe Event registriert werden. Die Idee dahinter ist folgende:
Wenn jedes Event von einem einzelnen Cluster-Objekt verarbeitet wird, dann steigt die Anzahl der Kontextumschaltungen proportional zur Anzahl der Events
Wenn jedes Event von allen Cluster-Objekten verarbeitet wird, dann steigt die Anzahl der Kontextumschaltungen proportional zur Anzahl der Events mal die Anzahl der Cluster-Objekte
Erstellen Sie eine nicht geclusterte Metrik, die die Ergebnisse für alle ursprünglichen Cluster-Objekte (die jetzt einfache Ressourcen und nicht Cluster-Objekte sind) berechnet. Gestalten Sie diese Metrik so, dass sie das Ergebnis der Cluster-Objekte in Form eines Events sendet. Erstellen Sie eine weitere Metrik, die geclustert ist, die Events von der ersten Metrik empfängt und den Wert überträgt, der in diesen Events als Ergebnis empfangen wurde. Die Idee dahinter ist, dass die große Anzahl an Rohdaten-Events von einer nicht geclusterten Metrik verarbeitet wird, während die geclusterte Metrik ein einzelnes Event pro Zeitraum und Cluster-Objekt verarbeitet.
|
Copyright © 2013 CA.
Alle Rechte vorbehalten.
|
|