Beispiel 1: viele Dinge, wenige Eigenschaften und niedrige Schreibfrequenz
Szenario
Allgemeine Szenario-Übersicht für Beispiel 1
Überwachung von 100.000 Pumpen im gesamten Bereich. Jede Pumpe meldet alle fünf Minuten 20 Eigenschaftswerte an ThingWorx. Während des maximalen Benutzerzugriffs werden 10 Mashups mit jeweils 10 Diensten von 1.000 Benutzern in einer Stunde aufgerufen. Diese ThingWorx Konfiguration verwendet eine Microsoft SQL Server-Datenbank.
Anforderungen
• Anzahl der Dinge (T): 100.000 Dinge
• Anzahl der Eigenschaften (P): 20 Eigenschaften
• Schreibfrequenz (FD): alle 5 Minuten oder 288 Schreibvorgänge pro Tag
• Maximale Verwendungsdauer (t): 1 Stunde oder 3.600 Sekunden
• Anzahl der Mashups (M): 10 Mashups
• Anzahl der Benutzer (U): 1.000 Benutzer
• Anzahl der Dienste pro Mashup (SM): 10 Dienste
• Ladehäufigkeit jedes Mashups durch Benutzer (LM): 2-mal
Berechnungen
• Datenaufnahme:
WPS = T × [(P1 × F1)]
= 100,000 × [(20 × 288/86400)]
≈ 6,667 writes per second
= 100,000 × [(20 × 288/86400)]
≈ 6,667 writes per second
 | In dieser Berechnung ist keine Summe erforderlich, da alle 20 Geräteeigenschaften dieselbe Schreibfrequenz aufweisen. |
Vergessen wir nicht, auch den Verbindungsserver-Wert zu berechnen:
CS = T / 100,000
= 100,000 / 100,000
= 1 Connection Server
= 100,000 / 100,000
= 1 Connection Server
• Datenvisualisierung:
R = [(SM + 1) × UM × LM ] / t
= [(10 + 1) × 1000 × 2 ] / 3600
≈ 6.11 requests per second
= [(10 + 1) × 1000 × 2 ] / 3600
≈ 6.11 requests per second
Um die Summe hier zu lösen, können wir einfach die HTTP-Anforderungen für alle Benutzer pro Mashup (angegeben durch (SM + 1) x UM) mit der Gesamtanzahl der Mashups (M) multiplizieren, da jedes Mashup den gleichen Datenverkehr erwartet und davon ausgegangen wird, dass sie die gleiche Anzahl von Diensten enthalten. Daraus ergibt sich Folgendes:
R = R1 × M
≈ 6.11 × 10 ≈ 61.1 HTTP Requests per second
≈ 6.11 × 10 ≈ 61.1 HTTP Requests per second
Kriterienvergleich
• T = 100.000 -> Mittelgroße Plattform (oder größer, mit Microsoft SQL Server)
• CS = 1 -> 1 Verbindungsserver empfohlen
• WPS = 6.667 -> Kleine Plattform (oder größer)
• R = 61 -> Mittelgroße Plattform (oder größer)
Dimensionierung
Da ein mittelgroßes ThingWorx System erforderlich ist, um alle Kriterien zu erfüllen, sollte die folgende Dimensionierung in Betracht gezogen werden (basierend auf dem Hosting-Typ):
Größe | Azure-VM | AWS EC2 | CPU-Kerne | Arbeitsspeicher (GiB) |
|---|---|---|---|---|
ThingWorx Platform: mittelgroß | F16s v2 | C5d.4xlarge | 16 | 32 |
Microsoft SQL Server-DB: mittelgroß | F16s v2 | C5d.4xlarge | 16 | 32 |
ThingWorx Connection Server | F2s v2 | C5d.large | 2 | 4 |
Im Connection Services Hilfe-Center erhalten Sie Informationen zur Verbindungsserver-Dimensionierung. Sie verwendet auch T aus diesem Handbuch sowie Faktoren wie Edge-Anforderungen (einschließlich WebSockets), Eigenschaftsaktualisierungen, Dateiübertragungen und durchschnittliche Meldungsgröße.
Berechnete und beobachtete Ergebnisse vergleichen
Beispiel 1 simuliert den Anwendungsfall einer Lösung für vernetzte Produkte mit weniger Fokus auf verschiedenen Mashups und mehr Fokus auf der Anzahl der Dinge, die mit der Plattform verbunden sind. In einem realen Szenario gäbe es größere Unterschiede bei der Anzahl der Dienste pro Mashup und der Anzahl der Benutzer, die auf jedes Mashup zugreifen (wie in Beispiel 2 erläutert).
Aus Sicht der Infrastruktur performte die Plattform mit durchschnittlich 51,6 % CPU-Auslastung und 5,3 GB Arbeitsspeicherverbrauch gut. MS SQL bot durchschnittlich 16,7 % CPU-Auslastung und 13,9 GB Arbeitsspeicher.
Aus Sicht der Plattform lag die HTTP-Anforderungsrate durchschnittlich bei 62 Operationen pro Sekunde – in Einklang mit den erwarteten 61 Operationen. Die Wert-Stream-Warteschlangenrate lag in der Praxis stabil bei ca. 7.000 WPS – nahe an den erwarteten 6.700 WPS oben.
Im Normalbetrieb versucht SQL Server im Allgemeinen, so viel Arbeitsspeicher wie möglich zu nutzen. SQL Server geht davon aus, dass es sich auf einem dedizierten Rechner befindet, und speichert so viele Daten wie möglich im Arbeitsspeicher. Dies wird im Diagramm zur Arbeitsspeicherverwendung oben deutlich, wobei der Verbrauch nur gegen Ende des Tests sinkt und ein kleiner Pool für das Betriebssystem übrig bleibt.
Während diese Infrastruktur für die Dauer der Dimensionierungstests stabil ist, wäre ein längerer Test vor der Verwendung für die Produktion ratsam (idealerweise bis die Datenbank die erwarteten Datenaufbewahrungsstufen erreicht hat), um sicherzustellen, dass der Datenbankserver ordnungsgemäß dimensioniert wird.