Überblick

---

In diesem Thema werden Leistungs- und Skalierbarkeitsmetriken für Insights Standalone- und Automation Suite-Bereitstellungsmodelle behandelt, die für Administratoren bestimmt sind. Die Leistung untersucht, wie Daten erfasst und im Hintergrund verarbeitet werden, sowie die Ladezeiten des Dashboards und die Hardwareanforderungen.

Der größte Maßstab, in dem Insights eingesetzt werden kann

---

The assumption of the total events that are supported over a two year period, with the current hardware requirements is the following:

• Bis zu 100 Millionen Arbeitsplätze;
• Bis zu 1 Milliarde Auftragsereignisse;
• Bis zu 100 Millionen Warteschlangenelemente;
• Bis zu 500 Millionen Warteschlangenelementereignisse;
• Bis zu 1 Milliarde Roboterprotokolle.

Leistungstestdatensatz

---

Ein Leistungstest wurde mit der folgenden Konfiguration durchgeführt:

• 100 Millionen Aufträge, 1 Milliarde Auftragsereignisse, 1 Milliarde Roboterprotokolle, 100 Millionen Warteschlangenelemente, 500 Millionen Warteschlangenelementereignisse. Für jeden Auftrag gibt es 10 zugehörige Auftragsereignisse, 10 Roboterprotokolle, 1 Warteschlangenelement und 5 Warteschlangenelementereignisse.
• Im Durchschnitt beträgt die Größe der Rohroboterprotokolle jeweils 4 KB, während das Warteschlangenelement (einschließlich benutzerdefinierter Daten über Analysen, Ausgabe und spezifische Daten) 9 KB beträgt.
• Es gibt 400 Prozesse, von denen ein einzelner Prozess 20 % der Daten generiert.
• Die gesamte Datenträgernutzung in Azure SQL beträgt etwa 5,7 TB.

Anfangsgröße der Daten

Größe der Daten nach dem Abgleich (Verschieben von Daten aus dem Rohspeicher in dbo in den Spaltenspeicher gelesen)

🚧

Wichtig

For optimal performance, tables in the read schema use a columnstore index, meaning that the data is compressed so the size consumption is decreased compared to the dbo schema.

Hardwareanforderungen

Eine Azure SQL-Konfiguration (40 Kerne, 200 GB Arbeitsspeicher, 7 TB Datenträger-vCore-Kaufmodell – Azure SQL-Datenbank) wurde verwendet, um die Leistungstests wie folgt auszuführen:

• Insights DB, Azure SQL Hyperscale, 40 Kerne und 0 Replikate;
• Als Insights-Datenbank wurde Azure SQL Hyperscale verwendet, das mehr als 5 TB Datenträger unterstützt.
• Der MAX DOP wurde von auf 16 festgelegt
  ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 16;
• Insights-VM, Insights 22.10, Standard D8s v4 (8 vcpus, 32 GiB Speicher)
• Looker-VM, Looker 22.10, Standard D4s v3 (4 vcpus, 16 GiB Speicher)
• Orchestrator-VM, 22.10, Standard D4s v3 (4 vcpus, 16 GiB Speicher)
• Orchestrator DB-VM, Standard D8s v3 (8 vcpus, 32 GiB Speicher)

Leistungstest

Die folgenden Leistungsmerkmale wurden bewertet:

• Leistung „Lesepfad“ : wie schnell die Dashboards Informationen rendern.
• Leistung „Schreibpfad“ : wie schnell die Daten in das System aufgenommen werden können und wie schnell die Daten verarbeitet werden können, bevor sie für den Verbrauch verfügbar werden. Dies geschieht im Hintergrund und wird regelmäßig in Batches ausgeführt. Wenn diese Hintergrundverarbeitung ausgeführt wird, verbraucht sie Serverressourcen, sodass weniger Ressourcen für den „Lesepfad“ übrig bleiben. Aus diesem Grund können Dashboards langsamer geladen werden, wenn die Erfassung oder Datenverarbeitung ausgeführt wird. Dieser Test umfasste auch die Konfiguration benutzerdefinierter Variablen aus Roboterprotokollen und Warteschlangen für die Verwendung in Dashboards.

Insights background processes

Insights führt die folgenden Hintergrundprozesse auf dem SQL-Server aus:

• Standardmäßig erfolgt die Erfassung aus der Orchestrator-Datenbank in die Insights-Datenbank alle 15 Minuten.
• Die Transformationspipeline verschiebt Daten in das Leseschema, um Aufträge, Warteschlangenelemente und Roboterprotokolle vorzubereiten, die alle 10 Minuten von einem Dashboard verwendet werden sollen.
• Die Transformationspipeline extrahiert benutzerdefinierte Variablen aus Roboterprotokollen und Warteschlangen, die von einem Dashboard verwendet werden, wenn die Konfiguration der benutzerdefinierten Felder geändert wird. In den Leistungstests erfolgt die Änderung alle 6 Stunden, um das Worst-Case-Szenario zu simulieren. Bei normaler Produktnutzung wird die Konfiguration der benutzerdefinierten Felder nicht oft geändert.
  Im Durchschnitt generieren Auftragsereignisse, Warteschlangenelementereignisse und Roboterprotokolle pro Sekunde 1 bis 10 neue Elemente (z. B. 5 neue Warteschlangenelemente pro Sekunde).

📘

Hinweis

Background jobs running may impact the loading time of a dashboard.

Template loading time

Bei den Tests wurde die Ladezeit der vorgefertigten Vorlagen gemessen. Beim Messen der Dashboard-Ladezeit wurden zwei Metriken aufgezeichnet:

• p90 (neunzigstes Perzentil) Ladezeit, die den schlimmsten Fall darstellt, wenn ein Benutzer benutzerdefinierte Felder neu konfiguriert, die einen teuren Hintergrundauftrag starten, der Serverressourcen verbraucht.
• Durchschnittliche Ladezeit.

Jedes Dashboard verfügt über mehrere Widgets. In einigen Dashboards werden die meisten Widgets deutlich schneller geladen als Ausreißer-Widgets. Dies ist bei den Dashboards Business ROI und Business ROI Queues der Fall.

Alle Dashboards werden mit der im Filter angegebenen Standardzeit geladen.

*Standardmäßig verarbeitet jedes Dashboard nur einen Teil des gesamten Datensatzes (z. B. die letzten 30 Tage der Daten, die über 2 Jahre verteilt sind). Wir schätzen die Anzahl der Zeilen, die jedes Dashboard mit der Standardfilterauswahl verarbeitet.

**Business-ROI und Business-ROI-Warteschlangen haben ein langsames Widget (das Widget „Monatlich gespeichert“). Mit dem langsamen Widget beträgt die Ladezeit für den Geschäfts-ROI 399 Sekunden bei p90 und 324 Sekunden im Durchschnitt. Business ROI Queues beträgt 193 Sekunden bei p90 und 145 Sekunden im Durchschnitt.