Esempio 1: molti oggetti, poche proprietà e frequenza di scrittura bassa
Scenario
Riepilogo generale dello scenario per l'esempio 1
Monitoraggio di 100.000 pompe in tutta l'area. Ogni pompa riporta 20 valori di proprietà a ThingWorx ogni cinque minuti. Durante il periodo di picco di accessi degli utenti, in un'ora 1.000 utenti chiameranno 10 mashup, ciascuno con 10 servizi. Questa configurazione di ThingWorx utilizza un database di Microsoft SQL Server.
Requisiti
• Numero di oggetti (T): 100.000
• Numero di proprietà (P): 20
• Frequenza di scrittura (FD): ogni 5 minuti o 288 scritture al giorno
• Periodo di picco di utilizzo (t): 1 ora o 3.600 secondi
• Numero di mashup (M): 10
• Numero di utenti (U): 1.000
• Numero di servizi per mashup (SM): 10
• Numero di volte in cui gli utenti caricano ogni mashup (LM): 2
Calcoli
• Inserimento dati:
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 questo calcolo non è richiesta una somma, in quanto le 20 proprietà del dispositivo hanno tutte la stessa frequenza di scrittura. |
Non dimentichiamo di calcolare anche il valore del server connessioni:
CS = T / 100,000
= 100,000 / 100,000
= 1 Connection Server
= 100,000 / 100,000
= 1 Connection Server
• Visualizzazione dati:
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
Per risolvere la somma qui, è sufficiente moltiplicare le richieste HTTP per tutti gli utenti per mashup (dati da (SM + 1) x UM) per il numero totale di mashup (M), poiché ogni mashup prevede la stessa quantità di traffico e si presuppone che contenga lo stesso numero di servizi. Pertanto:
R = R1 × M
≈ 6.11 × 10 ≈ 61.1 HTTP Requests per second
≈ 6.11 × 10 ≈ 61.1 HTTP Requests per second
Confronto tra i criteri
• T = 100.000 -> Piattaforma media (o più grande, con Microsoft SQL Server)
• CS = 1 -> È consigliato un solo server connessioni
• WPS = 6.667 -> Piattaforma piccola (o più grande)
• R = 61 -> 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 | Core CPU | Memoria (GiB) |
|---|---|---|---|---|
ThingWorx Platform: medio | F16s v2 | C5d.4xlarge | 16 | 32 |
Database Microsoft SQL Server: medio | F16s v2 | C5d.4xlarge | 16 | 32 |
ThingWorx Connection Server | F2s v2 | C5d.large | 2 | 4 |
Consultare l'Help Center di Connection Services per il dimensionamento del server connessioni che, oltre a utilizzare il valore T di questa guida, considera anche fattori quali richieste edge (inclusi i WebSocket), aggiornamenti di proprietà, trasferimenti di file e dimensioni medie dei messaggi.
Confronto tra risultati calcolati e osservati
L'esempio 1 simula un caso di utilizzo di una soluzione di prodotti connessi, con minore attenzione ai vari mashup e maggiore attenzione al numero di oggetti connessi alla piattaforma. In uno scenario reale ci sarebbero maggiori variazioni nel numero di servizi per mashup e nel numero di utenti che accedono a ciascun mashup (come illustrato nell'esempio 2).
Dal punto di vista dell'infrastruttura, le prestazioni della piattaforma sono valide, con una media del 51,6% di utilizzo della CPU e di 5,3 GB di memoria. In MS SQL la media di utilizzo è del 16,7% per la CPU e di 13,9 GB di memoria.
Dal punto di vista della piattaforma, la velocità media delle richieste HTTP è di 62 operazioni al secondo, in linea con le 61 operazioni previste, e la velocità della coda dello stream di valori resta stabile intorno a 7k WPS, molto vicino al valore precedente previsto di 6,7k WPS.
In modalità normale SQL Server cerca generalmente di utilizzare tutta la memoria possibile. Presuppone che si trovi su una macchina dedicata e archivia quanto più dati possibile in memoria. Questa situazione è illustrata nel grafico di utilizzo della memoria precedente, in cui il consumo viene livellato solo in prossimità della fine del test, con un piccolo pool lasciato per il sistema operativo.
Sebbene questa infrastruttura resti stabile per la durata dei test di dimensionamento eseguiti, prima di utilizzarla in un'impostazione di produzione, sarebbe auspicabile eseguire un test di durata maggiore, teoricamente fino a quando il database non ha raggiunto i livelli di conservazione dei dati previsti, per assicurarsi che il server di database sia dimensionato correttamente.