Beispiel 2: wenige Dinge, wenige Eigenschaften und hohe Schreibfrequenz
Szenario
Allgemeine Szenario-Übersicht für Beispiel 2
Eine mittelgroße Produktionsstätte, in der 250 überwachte Maschinen jeweils 60 Eigenschaftsaktualisierungen an ThingWorx mit unterschiedlichen Geschwindigkeiten senden (siehe Anforderungen).
Die maximale Verwendungsdauer beträgt 30 Minuten, während der 100 Benutzer unterschiedlich viele Aufrufe an 5 eindeutige Mashups mit einer unterschiedlichen Anzahl von Diensten durchführen können. Diese Konfiguration verwendet eine PostgreSQL-Datenbank.
Anforderungen
• Anzahl der Dinge (T): 250 Dinge
• Anzahl der Eigenschaften (P, drei verschiedene Eigenschaftsgruppen auf jedem Gerät):
P1 | P2 | P3 |
|---|---|---|
10 Eigenschaften | 45 Eigenschaften | 5 Eigenschaften |
• Schreibfrequenz (F):
F1 | F2 | F3 |
|---|---|---|
alle 30 Sekunden (2.880 pro Tag) | jede Sekunde (86.400 pro Tag) | stündlich (24 pro Tag) |
• Maximale Verwendungsdauer (t) = 30 Minuten oder 1.800 Sekunden
• Anzahl der Mashups (M) = 5 Mashups
• Anzahl der Benutzer (UM):
UM1 | UM2 | UM3 | UM4 | UM5 |
|---|---|---|---|---|
100 Benutzer | 100 Benutzer | 100 Benutzer | 10 Benutzer | 10 Benutzer |
Hinweis: Mashups mit einer geringeren Anzahl von Benutzeranforderungen sind für Administratorbenutzer gängig. | ||||
• Anzahl der Dienste pro Mashup (SM):
SM1 | SM2 | SM3 | SM4 | SM5 |
|---|---|---|---|---|
20 Dienste | 4 Dienste | 10 Dienste | 15 Dienste | 25 Dienste |
• Ladehäufigkeit jedes Mashups durch Benutzer (LM):
LM1 | LM2 | LM3 | LM4 | LM5 |
|---|---|---|---|---|
30-mal | 30-mal | 30-mal | 1-mal | 1-mal |
Hinweis: 30-mal bedeutet, dass die Mashups 1, 2 und 3 jede Minute während der 30-minütigen maximalen Dauer neu geladen werden, wahrscheinlich durch eine automatische Aktualisierung. | ||||
Berechnungen
• Datenaufnahme:
WPS = T × [(P1 × F1) + (P2 × F2) + (P3 × F3)]
= 250× [(10 × 1/30) + (45 × 1) + (5 × 1/3600)]
≈ 11,334 writes per second
= 250× [(10 × 1/30) + (45 × 1) + (5 × 1/3600)]
≈ 11,334 writes per second
Dies ist ein wenig komplexer, da Eigenschaften mit unterschiedlichen Geschwindigkeiten geschrieben werden. Denken Sie daran, dass Sie FD durch 86.400 teilen können, um bei Bedarf in Sekunden zu konvertieren.
Vergessen Sie nicht, auch den CS-Wert zu berechnen:
CS = T / 100,000
= 250/ 100,000
= 0.0025 Connection Servers
= 250/ 100,000
= 0.0025 Connection Servers
• Datenvisualisierung:
R = [(SM + 1) × UM × LM ] / t
R1 = [(20 + 1) × 100 × 30 ] / 1800
≈ 35 requests per second
R2 = [(4 + 1) × 100 × 30 ] / 1800
≈ 8.33 requests per second
R3 = [(10 + 1) × 100 × 30 ] / 1800
≈ 18.33 requests per second
R4 = [(15 + 1) × 10 × 1 ] / 1800
≈ 0.09 requests per second
R5 = [(25 + 1) × 10 × 1 ] / 1800
≈ 0.14 requests per second
R = R1 + R2 + R3 + R4 + R5
≈ 61.89 requests per second
R1 = [(20 + 1) × 100 × 30 ] / 1800
≈ 35 requests per second
R2 = [(4 + 1) × 100 × 30 ] / 1800
≈ 8.33 requests per second
R3 = [(10 + 1) × 100 × 30 ] / 1800
≈ 18.33 requests per second
R4 = [(15 + 1) × 10 × 1 ] / 1800
≈ 0.09 requests per second
R5 = [(25 + 1) × 10 × 1 ] / 1800
≈ 0.14 requests per second
R = R1 + R2 + R3 + R4 + R5
≈ 61.89 requests per second
In diesem Szenario hat jedes Mashup eine unterschiedliche Anzahl von Diensten, während einige von weniger Benutzern aufgerufen werden. Außerdem werden einige jede Minute aktualisiert, während andere evtl. nur einmal geladen werden.
Stellen Sie in diesem Fall sicher, dass LMberücksichtigt wird. Die zusätzlichen Dienstaufrufe für ein Mashup mit automatischer Aktualisierung können erhebliche Auswirkungen auf die Systemgröße haben.
Während diese Berechnung mehr Bestandteile aufweist, ist das Aufschlüsseln der Gleichung für jedes Mashup und das Hinzufügen der Ergebnisse (oben dargestellt) einfach.
Kriterienvergleich
• T = 250 -> Sehr kleine Plattform (oder größer, mit PostgreSQL)
• CS = 0,0025 -> Keine Verbindungsserver erforderlich
• WPS = 11.334 -> Kleine Plattform (oder größer)
• R = 61,89 -> 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 | Speicher (GiB) |
|---|---|---|---|---|
ThingWorx Platform: mittelgroß | F16s v2 | C5d.4xlarge | 16 | 32 |
PostgreSQL-DB: mittelgroß | F16s v2 | C5d.4xlarge | 16 | 32 |
Berechnete und beobachtete Ergebnisse vergleichen
Für Beispiel 2 imitiert die Simulation eine tatsächliche Anwendung mit mehreren Mashups, die verschiedene Dienstaufrufe mit unterschiedlichen Aktualisierungsgeschwindigkeiten durchführen, zusammen mit simulierten Remote-Dingen, die Daten an die Plattform mit variierten Geschwindigkeiten senden.
Aus Sicht der Infrastruktur performte die Plattform mit durchschnittlich 34,8 % CPU-Auslastung und 3,1 GB Arbeitsspeicherverbrauch gut. PostgreSQL bot durchschnittlich 35,1 % CPU-Auslastung und 8,1 GB Arbeitsspeicher.
Aus Sicht der Plattform lag die HTTP-Anforderungsrate durchschnittlich bei 63 Operationen pro Sekunde – in Einklang mit den erwarteten 62 Operationen. Die Schreibvorgänge pro Sekunde in die Wert-Stream-Warteschlange lagen in der Praxis stabil bei ca. 12.000 WPS – nahe an den erwarteten 11.300 WPS oben.
Beobachtete Ergebnisse aus simulierter Bereitstellung in Beispiel 2
Aus Anwendungs- oder Benutzerperspektive wurden von den Gerät- oder Benutzersimulatoren keine Fehler, Leistungsprobleme oder fehlerhafte Anforderungen/Antworten beobachtet. Alle neuen Anforderungen wurden rechtzeitig verarbeitet.
Wie in den Diagrammen oben dargestellt, verfügt die Implementierung über genügend Ressourcen sowohl für eine simulierte, stationäre Arbeitslast als auch für realere Spitzen der Geräte- und/oder Benutzeraktivität.