Exemple 1 : nombreux objets, peu de propriétés et faible fréquence d'écriture
Scénario
Vue d'ensemble du scénario pour l'exemple 1
Surveillance de 100 000 pompes dans toute la zone. Chaque pompe rapporte 20 valeurs de propriété à ThingWorx toutes les cinq minutes. Lors du pic des accès utilisateur, 10 applications composites, avec 10 services chacune, seront appelées par 1 000 utilisateurs en une heure. Cette configuration de ThingWorx utilise une base de données Microsoft SQL Server.
Exigences
• Nombre d'objets (T) : 100 000 objets
• Nombre de propriétés (P) : 20 propriétés
• Fréquence d'écriture (FD) : toutes les 5 minutes, soit 288 écritures par jour
• Période de pic d'utilisation (t) : 1 heure, soit 3 600 secondes
• Nombre d'applications composites (M) : 10 applications composites
• Nombre d'utilisateurs (U) : 1 000 utilisateurs
• Nombre de services par application composite (SM) : 10 services
• Nombre de chargements par les utilisateurs de chaque application composite (LM) : 2 fois
Calculs
• Ingestion de données :
WPS = T × [(P1 × F1)]
= 100,000 × [(20 × 288/86400)]
≈ 6,667 writes per second
= 100,000 × [(20 × 288/86400)]
≈ 6,667 writes per second
 | Dans ce calcul, une somme n'est pas nécessaire étant donné que les 20 propriétés d'appareil ont la même fréquence d'écriture. |
N'oublions pas de calculer également la valeur du serveur de connexion :
CS = T / 100,000
= 100,000 / 100,000
= 1 Connection Server
= 100,000 / 100,000
= 1 Connection Server
• Visualisation des données :
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
Pour résoudre la somme ici, nous pouvons simplement multiplier le nombre de requêtes HTTP pour tous les utilisateurs par application composite (obtenu par (SM + 1) x UM) par le nombre total d'applications composites (M), car chaque application composite attend le même trafic et est supposée contenir le même nombre de services. Ainsi :
R = R1 × M
≈ 6.11 × 10 ≈ 61.1 HTTP Requests per second
≈ 6.11 × 10 ≈ 61.1 HTTP Requests per second
Comparaison des critères
• T = 100 000 -> Plateforme de "taille intermédiaire" (ou de taille supérieure, avec Microsoft SQL Server)
• CS = 1 -> Un serveur de connexion recommandé
• WPS = 6 667 -> Plateforme de "petite taille" (ou de taille supérieure)
• R = 61 -> 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 Microsoft SQL Server : taille intermédiaire | F16s v2 | C5d.4xlarge | 16 | 32 |
ThingWorx Connection Server | F2s v2 | C5d.large | 2 | 4 |
N'oubliez pas de consulter le Centre d'aide ThingWorx Connection Services pour le dimensionnement du serveur de connexion, qui utilise également la valeur T du présent guide, mais prend également en compte des facteurs tels que les requêtes Edge (WebSockets y compris), les mises à jour de propriétés, les transferts de fichiers et la taille moyenne des messages.
Comparaison des résultats calculés et observés
L'exemple 1 simule un cas d'utilisation de solution de produits connectés, avec moins de focus sur les diverses applications composites et davantage sur le nombre d'objets connectés à la plateforme. Dans un scénario réel, il y aurait de plus grandes variations à la fois dans le nombre de services par application composite et dans le nombre d'utilisateurs accédant à chaque application composite (comme dans l'exemple 2).
Du point de vue de l'infrastructure, la plateforme s'est bien comportée, avec une utilisation moyenne de 51,6 % des ressources CPU et une consommation de mémoire de 5,3 Go. MS SQL a consommé en moyenne 16,7 % des ressources CPU et 13,9 Go de mémoire.
Du point de vue de la plateforme, le taux de requêtes HTTP s'est élevé en moyenne à 62 opérations par seconde, en ligne avec les 61 opérations prévues, et le débit de la file d'attente des flux de valeurs est resté stable autour de 7 000 écritures par seconde, soit un résultat proche des 6 700 écritures par seconde anticipées.
En fonctionnement normal, SQL Server cherche généralement à utiliser autant de mémoire que possible. Il suppose qu'il se trouve sur une machine dédiée et stocke autant de données que possible en mémoire. C'est ce que montre le graphique d'utilisation de la mémoire ci-dessus, la consommation ne se stabilisant que vers la fin du test, avec une petite réserve laissée pour le système d'exploitation.
Bien que cette infrastructure se soit montrée stable sur la durée des tests de dimensionnement, un test de plus longue durée (idéalement jusqu'à ce que la base de données ait atteint les niveaux de conservation des données prévus) est recommandé avant de l'utiliser dans un cadre de production afin de s'assurer du bon dimensionnement du serveur de base de données.