Esempio 2: pochi oggetti, poche proprietà e frequenza di scrittura elevata
Scenario
Riepilogo generale dello scenario per l'esempio 2
Una fabbrica di medie dimensioni in cui ognuno dei 250 computer monitorati invia 60 aggiornamenti di proprietà a ThingWorx a velocità variabili (vedere i requisiti).
Il periodo di picco di utilizzo è di 30 minuti, durante i quali 100 utenti possono effettuare un numero variabile di chiamate a 5 mashup univoci, ciascuno con un numero variabile di servizi. Questa configurazione utilizza un database PostgreSQL.
Requisiti
• Numero di oggetti (T): 250
• Numero di proprietà (P, tre diversi gruppi di proprietà per ogni dispositivo):
P1 | P2 | P3 |
|---|---|---|
10 proprietà | 45 proprietà | 5 proprietà |
• Frequenza di scrittura (F):
F1 | F2 | F3 |
|---|---|---|
ogni 30 secondi (2.880 al giorno) | ogni secondo (86.400 al giorno) | ogni ora (24 al giorno) |
• Periodo di picco di utilizzo (t) = 30 minuti o 1.800 secondi
• Numero di mashup (M) = 5
• Numero di utenti (UM):
UM1 | UM2 | UM3 | UM4 | UM5 |
|---|---|---|---|---|
100 utenti | 100 utenti | 100 utenti | 10 utenti | 10 utenti |
Nota: i mashup con un numero inferiore di richieste utente sono frequenti per gli utenti amministrativi | ||||
• Numero di servizi per mashup (SM):
SM1 | SM2 | SM3 | SM4 | SM5 |
|---|---|---|---|---|
20 servizi | 4 servizi | 10 servizi | 15 servizi | 25 servizi |
• Numero di volte in cui gli utenti caricano ogni mashup (LM):
LM1 | LM2 | LM3 | LM4 | LM5 |
|---|---|---|---|---|
30 volte | 30 volte | 30 volte | 1 volta | 1 volta |
Nota: 30 volte indica che i mashup 1, 2 e 3 vengono ricaricati ogni minuto durante il periodo di picco di 30 minuti, probabilmente mediante un aggiornamento automatico. | ||||
Calcoli
• Inserimento dati:
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
Questo scenario è leggermente più complesso, in quanto le proprietà scrivono a velocità diverse. Se necessario, è possibile dividere FD per 86.400 per convertirlo in secondi.
Non dimenticare di calcolare anche il valore CS:
CS = T / 100,000
= 250/ 100,000
= 0.0025 Connection Servers
= 250/ 100,000
= 0.0025 Connection Servers
• Visualizzazione dati:
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 questo scenario ogni mashup presenta diversi numeri di servizi, mentre alcuni vengono chiamati da un numero inferiore di utenti. Inoltre alcuni aggiornano ogni minuto, mentre altri possono essere caricati una sola volta.
In questa situazione è importante non trascurare LM. Le chiamate ai servizi aggiuntive per un mashup con aggiornamento automatico possono avere un impatto significativo sul dimensionamento del sistema.
Sebbene questo calcolo sia costituito da più parti, la scomposizione dell'equazione per ogni mashup e l'aggiunta dei risultati (illustrati in precedenza) sono operazioni semplici.
Confronto tra i criteri
• T = 250 -> Piattaforma molto piccola (o più grande con PostgreSQL)
• CS = 0,0025 -> Non sono richiesti server connessioni
• WPS = 11.334 -> Piattaforma piccola (o più grande)
• R = 61,89 -> Piattaforma media (o più grande)
Dimensionamento
Dal momento che per soddisfare tutti i criteri è richiesto un sistema ThingWorx di medie dimensioni, è necessario considerare il seguente dimensionamento, in base al tipo di hosting:
Dimensione | Macchina virtuale di Azure | AWS EC2 | CPU Core | Memoria (GiB) |
|---|---|---|---|---|
ThingWorx Platform: medio | F16s v2 | C5d.4xlarge | 16 | 32 |
DB PostgreSQL: medio | F16s v2 | C5d.4xlarge | 16 | 32 |
Confronto tra risultati calcolati e osservati
Per l'esempio 2, la simulazione prevede un'applicazione reale con più mashup che effettuano diverse chiamate di servizio, ciascuna con una velocità di aggiornamento diversa, insieme agli oggetti remoti simulati che inviano dati alla piattaforma a velocità variabili.
Dal punto di vista dell'infrastruttura, le prestazioni della piattaforma sono valide, con una media del 34,8% di utilizzo della CPU e di 3,1 GB di memoria. In PostgreSQL la media di utilizzo è del 35,1% per la CPU e di 8,1 GB di memoria.
Dal punto di vista della piattaforma, la velocità media delle richieste HTTP è di 63 operazioni al secondo, in linea con le 62 operazioni previste, e le scritture della coda dello stream di valori al secondo resta stabile intorno a 12K WPS, molto vicino al valore precedente previsto di 11,3k WPS.
Risultati osservati dalla distribuzione simulata dell'esempio 2
Dal punto di vista dell'applicazione o dell'utente, non sono stati osservati errori, problemi di prestazioni o richieste/risposte errate dai simulatori utente o dispositivo. Tutte le nuove richieste sono state elaborate in modo tempestivo.
Come illustrato nei grafici sopra riportati, l'implementazione presenta risorse di riserva sufficienti sia per un carico di lavoro simulato costante che per i reali picchi di attività utente e dispositivo.