Datenvisualisierung
Systemanforderungen für die Visualisierung konzentrieren sich auf die Serverlast, die durch Benutzererfahrungen (Mashups) in der Geschäftsanwendung generiert wird.
Ähnlich wie bei der Aufnahme hängt die Visualisierungslast nicht nur von der Anzahl der Mashups ab, sondern auch von der Komplexität jedes Mashups und der Anzahl der gleichzeitigen Benutzer, die voraussichtlich auf sie zugreifen.
|
t
|
Zeitspanne für maximalen Benutzerzugriff: Zeitraum, in dem die folgenden Mashups und Dienste aufgerufen werden (in Sekunden).
|
|
M
|
Eindeutige Mashups: Anzahl der eindeutigen Mashups, auf die von Benutzern während dieser Zeit voraussichtlich zugegriffen wird.
|
|
SM
|
Dienste pro Mashup: Bestimmen Sie für jedes eindeutige Mashup die Anzahl der aufgerufenen Dienste.
|
|
UM
|
Anzahl der gleichzeitigen Benutzer: Gesamtzahl der Benutzer, die diese Mashups während dieses Zeitraums voraussichtlich gleichzeitig verwenden.
|
|
LM
|
Ladehäufigkeit von Mashups durch Benutzer: Häufigkeit des voraussichtlichen Zugriffs jedes einzelnen Benutzers auf dieses Mashup während des Zeitraums.
Im Allgemeinen ist dieser Wert immer mindestens 1. Aber achten Sie besonders auf Mashups, bei denen die automatische Aktualisierung aktiviert ist.
|
Mit diesen Werten kann die Gesamtanzahl von HTTP-Anforderungen pro Sekunde (R) als Summe der Mashup-Dienstaufrufe (plus 1 für das Mashup selbst) bestimmt werden, die von jedem Benutzer während dieses Zeitraums angefordert wurden:
Es gibt beispielsweise 3 eindeutige Mashups (M) in der Anwendung mit den folgenden Parametern:
• Die Zeit für den maximalen Benutzerzugriff beträgt eine Stunde (t = 3.600 Sekunden).
• Zwei der Mashups führen jeweils 10 Dienstaufrufe durch (sowohl S1 als auch S2 = 10).
• Das dritte Mashup führt 20 Dienstaufrufe durch (S3 = 20).
• Auf das erste Mashup wird jede Stunde von 1.000 Benutzern zugegriffen (U1 = 1.000).
• Auf die anderen beiden Mashups wird jede Stunde von 100 Benutzern zugegriffen (U2 und U3 = 100).
• Keines der Mashups weist darüber hinaus automatische oder manuelle Aktualisierungen auf. Dies beschreibt ein Szenario, in dem Endbenutzer die bereitgestellten Informationen einmal im zugeteilten Zeitrahmen (von einer Stunde) nutzen.
(L1, L2 und L3 = 1)
Die Berechnung wäre:
R = [(SM + 1) × UM × LM ] / t
R1 = [(S1 + 1) × U1 × L1] / t
= [(10 + 1) × 1000 × 1] / 3600
≈ 3.06 requests per second
= [(10 + 1) × 1000 × 1] / 3600
≈ 3.06 requests per second
R2 = [(S2 + 1) × U2 × L2] / t
= [(10 + 1) × 100 × 1] / 3600
≈ 0.31 requests per second
= [(10 + 1) × 100 × 1] / 3600
≈ 0.31 requests per second
R3 = [(S3 + 1) × U3 × L3] / t
= [(20 + 1) × 100 × 1] / 3600
≈ 0.61 requests per second
= [(20 + 1) × 100 × 1] / 3600
≈ 0.61 requests per second
R = R1 + R2 + R3
≈ 3.06 + 0.31 + 0.61
≈ 3.98 requests per second
≈ 3.06 + 0.31 + 0.61
≈ 3.98 requests per second
In diesem Szenario sollte ein besonders kleines ThingWorx System mit einer einfachen Datenbank wie H2 diese Last verarbeiten. Dies wird jedoch nicht für die Produktion empfohlen.
Die meisten Berechnungen sind komplexer, wahrscheinlich mit mehr eindeutigen Mashups, die jeweils mehr Dienstaufrufe und gleichzeitige Benutzer haben, als hier angeführt.
Zwei Beispiele, die diese Berechnungen enthalten, finden Sie hier.