Visualizzazione dati
I requisiti di sistema per la visualizzazione si concentrano sul carico del server generato dalle esperienze utente (mashup) all'interno dell'applicazione aziendale.
Analogamente all'inserimento, il carico della visualizzazione dipende non solo dal numero di mashup, ma anche dalla complessità di ciascuno di essi e dal numero di utenti che si prevede che accedano simultaneamente.
|
t
|
Periodo di picco di accessi utenti: periodo di tempo (in secondi) durante il quale vengono chiamati i mashup e i servizi riportati di seguito.
|
|
M
|
Mashup univoci: numero di mashup univoci a cui si prevede che accedano gli utenti durante tale periodo di tempo.
|
|
SM
|
Servizi per Mashup: per ogni mashup univoco, stabilire il numero di servizi chiamati.
|
|
UM
|
Numero di utenti simultanei: numero totale di utenti che si prevede che utilizzino contemporaneamente questi mashup durante questo periodo di tempo.
|
|
LM
|
Numero di caricamenti di ogni mashup: numero di volte in cui ogni singolo utente accede al mashup nel periodo di tempo specificato.
In generale, sarà sempre almeno una, tuttavia va prestata particolare attenzione ai mashup in cui è attivato l'aggiornamento automatico.
|
Con questi valori, il totale delle richieste HTTP al secondo (R) può essere determinato come somma delle chiamate al servizio di mashup (più una per il mashup stesso) richieste da ciascun utente durante il periodo di tempo specificato:
Ad esempio, si supponga che nell'applicazione siano presenti 3 mashup univoci (M) con i parametri che seguono.
• Il periodo di picco di accessi degli utenti dura un'ora (t = 3.600 secondi)
• Due dei mashup effettuano 10 chiamate di servizio ciascuno (sia S1 che S2 = 10)
• Il terzo mashup effettua 20 chiamate di servizio (S3 = 20)
• Al primo mashup accederanno 1.000 utenti ogni ora (U1 = 1000)
• Agli altri due mashup accederanno 100 utenti ogni ora (sia U2 che U3 = 100)
• Per nessuno dei mashup verranno eseguiti aggiornamenti automatici o manuali, pertanto in questo scenario gli utenti finali utilizzano tutte le informazioni fornite nell'intervallo di tempo assegnato (di un'ora)
(L1, L2 e L3 = 1)
Il calcolo sarebbe:
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
Anche in questo scenario il carico dovrebbe essere gestito da un sistema ThingWorx molto piccolo con un database semplice, ad esempio H2, ma non è una soluzione consigliata nella produzione.
La maggior parte dei calcoli sarà più complessa, probabilmente con più mashup univoci, ciascuno con più chiamate di servizi e utenti simultanei rispetto allo scenario ipotizzato qui.
Vengono proposti due esempi relativi a questi calcoli qui.