Visualisation des données
Configuration système requise pour la visualisation avec focus sur la charge serveur générée par les expériences utilisateur (applications composites) au sein de l'application métier.
Tout comme pour l'ingestion, la charge de la visualisation ne dépend pas seulement du nombre d'applications composites, mais également de la complexité de chaque application composite et du nombre d'utilisateurs simultanés qui y accèderont.
|
t
|
Période de pic des accès utilisateur : durée pendant laquelle les applications composites et les services suivants seront appelés (en secondes).
|
|
M
|
Applications composites uniques : nombre prévu d'applications composites uniques auxquelles les utilisateurs accèderont sur la période en question.
|
|
SM
|
Services par application composite : pour chaque application composite unique, déterminez le nombre de services qui seront appelés.
|
|
UM
|
Nombre d'utilisateurs simultanés : nombre total prévu d'utilisateurs qui utiliseront ces applications composites simultanément sur la période considérée.
|
|
LM
|
Nombre de chargements par les utilisateurs de chaque application composite : nombre prévu de fois que chaque utilisateur accèdera à cette application composite sur la période considérée.
En général, ce sera toujours au moins une fois, mais prêtez particulièrement attention aux applications composites qui fonctionneront avec la fonction d'actualisation automatique activée.
|
Avec ces valeurs, le nombre total de requêtes HTTP par seconde (R) correspondra à la somme des appels de service de chaque application composite (plus un pour l'application composite elle-même) effectués par chaque utilisateur sur la période considérée :
Prenons l'exemple de 3 applications composites uniques (M) contenues dans l'application, avec les paramètres suivants :
• La période de pic des accès utilisateur est d'une heure (t = 3 600 secondes).
• Deux des trois applications composites effectuent 10 appels de service chacune (S1 et S2 = 10).
• La troisième application composite effectue 20 appels de service (S3 = 20).
• 1 000 utilisateurs accèderont à la première application composite chaque heure (U1 = 1000).
• 100 utilisateurs accèderont aux deux autres applications composites chaque heure (U2 et U3 = 100).
• Aucune des applications composites ne fera l'objet d'actualisations automatiques ni non plus manuelles au-delà, dans un scénario où les utilisateurs finaux consommeront les informations fournies dans le temps imparti (d'une heure)
(L1, L2 et L3 = 1).
Le calcul sera dès lors le suivant :
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
Là encore, dans ce scénario, un système ThingWorx de très petite taille avec une base de données simple, de type H2 par exemple, suffirait théoriquement pour traiter la charge, même si une telle configuration ne serait pas recommandée pour un environnement de production.
La plupart des calculs seront probablement plus complexes avec davantage d'applications composites uniques et davantage d'appels de service et d'utilisateurs simultanés que dans ce scénario.
Deux exemples illustrant ces calculs sont fournis ici.