Exemple 2 : peu d'objets, peu de propriétés et haute fréquence d'écriture
Scénario
Vue d'ensemble du scénario pour l'exemple 2
Usine de taille moyenne depuis laquelle 250 machines surveillées envoient chacune 60 mises à jour de propriétés à ThingWorx à des fréquences variables (voir les exigences).
La période de pic d'utilisation est de 30 minutes, période au cours de laquelle 100 utilisateurs sont susceptibles d'effectuer un nombre variable d'appels vers 5 applications composites uniques avec chacune un nombre variable de services. Cette configuration utilise une base de données PostgreSQL.
Exigences
• Nombre d'objets (T) : 250 objets
• Nombre de propriétés (P, trois groupes de propriétés différents sur chaque appareil) :
P1 | P2 | P3 |
|---|---|---|
10 propriétés | 45 propriétés | 5 propriétés |
• Fréquence d'écriture (F) :
F1 | F2 | F3 |
|---|---|---|
toutes les 30 secondes (2 880 par jour) | toutes les secondes (86 400 par jour) | toutes les heures (24 par jour) |
• Période de pic d'utilisation (t) : 30 minutes, soit 1 800 secondes
• Nombre d'applications composites (M) = 5 applications composites
• Nombre d'utilisateurs (UM) :
UM1 | UM2 | UM3 | UM4 | UM5 |
|---|---|---|---|---|
100 utilisateurs | 100 utilisateurs | 100 utilisateurs | 10 utilisateurs | 10 utilisateurs |
Remarque : les applications composites avec un plus petit nombre de requêtes utilisateur sont courantes pour les utilisateurs administrateurs. | ||||
• Nombre de services par application composite (SM) :
SM1 | SM2 | SM3 | SM4 | SM5 |
|---|---|---|---|---|
20 services | 4 services | 10 services | 15 services | 25 services |
• Nombre de chargements par les utilisateurs de chaque application composite (LM) :
LM1 | LM2 | LM3 | LM4 | LM5 |
|---|---|---|---|---|
30 fois | 30 fois | 30 fois | 1 fois | 1 fois |
Remarque : 30 fois signifie que les applications composites 1, 2 et 3 sont rechargées toutes les minutes sur la période de pic min. de 30 minutes, du fait par exemple d'une actualisation automatique. | ||||
Calculs
• Ingestion de données :
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
Le calcul est ici un peu plus complexe car des écritures de propriétés s'effectuent à des fréquences différentes. N'oubliez pas que vous pouvez diviser FD par 86 400 pour convertir la valeur en secondes si nécessaire.
N'oubliez pas non plus de calculer également la valeur CS :
CS = T / 100,000
= 250/ 100,000
= 0.0025 Connection Servers
= 250/ 100,000
= 0.0025 Connection Servers
• Visualisation des données :
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
Dans ce scénario, chaque application composite présente un nombre de services différent, avec pour certaines des appels par un plus petit nombre d'utilisateurs. En outre, certaines s'actualisent toutes les minutes, tandis que d'autres ne peuvent être chargées qu'une seule fois.
Dans pareil cas, assurez-vous de bien prendre en compte LM. Les appels de service supplémentaires pour une application composite qui utilise l'actualisation automatique peuvent avoir un impact significatif sur le dimensionnement du système.
Bien que ce calcul comporte davantage de composantes, il reste simple en fractionnant l'équation pour chaque application composite et en additionnant les résultats (voir ci-dessus).
Comparaison des critères
• T = 250 -> Plateforme de "très petite taille" (ou de taille supérieure, avec PostgreSQL)
• CS = 0,0025 -> Aucun serveur de connexion n'est requis
• WPS = 11 334 -> Plateforme de "petite taille" (ou de taille supérieure)
• R = 61,89 -> Plateforme de "taille intermédiaire" (ou de taille supérieure)
Dimensionnement
Etant donné qu'un système ThingWorx de "taille intermédiaire" est nécessaire pour répondre à tous les critères, le dimensionnement suivant doit être envisagé, en fonction du type d'hébergement :
Taille | Machine virtuelle Azure | AWS EC2 | Coeurs CPU | Mémoire (Gio) |
|---|---|---|---|---|
ThingWorx Platform : taille intermédiaire | F16s v2 | C5d.4xlarge | 16 | 32 |
BD PostgreSQL : taille intermédiaire | F16s v2 | C5d.4xlarge | 16 | 32 |
Comparaison des résultats calculés et observés
Dans l'exemple 2, la simulation imite une application réelle avec plusieurs applications composites qui effectuent divers appels de service à différentes fréquences d'actualisation, ainsi que des objets distants simulés qui envoient des données à la plateforme à des fréquences variées.
Du point de vue de l'infrastructure, la plateforme s'est bien comportée, avec une utilisation moyenne de 34,8 % des ressources CPU et une consommation de mémoire de 3,1 Go. PostgreSQL a consommé en moyenne 35,1 % des ressources CPU et 8,1 Go de mémoire.
Du point de vue de la plateforme, le taux de requêtes HTTP s'est élevé en moyenne à 63 opérations par seconde, en ligne avec les 62 opérations prévues, et le débit de la file d'attente des flux de valeurs est resté stable autour de 12 000 écritures par seconde, soit un résultat proche des 11 300 écritures par seconde anticipées.
Résultats observés lors du déploiement simulé de l'exemple 2
Du point de vue de l'application ou de l'utilisateur, aucune erreur ni aucun problème de performance ou de requête/réponse erronée n'ont été observés par les simulateurs d'appareils ou d'utilisateurs. Toutes les nouvelles requêtes ont été traitées en temps voulu.
Comme le montrent les graphiques ci-dessus, l'implémentation dispose de suffisamment de ressources pour absorber à la fois une charge de travail stable simulée et les pics d'activité susceptibles de se présenter au niveau des appareils et/ou des utilisateurs en environnement réel.