Entre l'ingestion et la visualisation, ThingWorx Platform requiert également suffisamment de ressources système pour exécuter la logique applicative et les besoins en matière de transformation des données de l'application.

Cette section se penche sur les éléments à prendre en compte dans les domaines susceptibles d'affecter de la manière la plus significative les exigences en matière de traitement des données. Le traitement des données est très dépendant du cas d'utilisation métier considéré, ce qui rend les calculs standardisés moins utiles.

Une fois vos estimations réalisées pour l'ingestion et la visualisation, les tests de charge ou de contrainte de l'application constituent une étape importante avant de basculer en environnement production. Ces tests peuvent vous amener à sélectionner un système d'une taille autre que celle de la configuration de référence si votre application nécessite plus de ressources du fait de la complexité de la logique applicative ou du traitement des événements/alertes.

Les abonnements aux timers et aux événements de modification de propriété représentent souvent l'essentiel de la logique applicative dans une application ThingWorx. Ces abonnements utilisent de la mémoire à partir des sous-systèmes de traitement des événements, qui ne sont pas utilisés lors de l'ingestion et de la connectivité des appareils.

Une fois que le système est dimensionné pour une ingestion et une connectivité des appareils stables, les tests de charge avec la logique applicative en place est une étape importante pour s'assurer qu'il prendra correctement en charge l'utilisation en production.

Le transfert de fichiers vers et depuis les périphériques Edge est une exigence courante qui concerne de nombreux cas d'utilisation des applications ThingWorx :

Si vous prévoyez de nombreux transferts de fichiers simultanés et/ou transferts de gros fichiers, la plateforme pourra avoir besoin de mémoire supplémentaire pour gérer cette charge.

Dans le cas d'un déploiement dans une configuration haute disponibilité (comme décrit à la section Haute disponibilité ThingWorx), une configuration de base de données relationnelle haute disponibilité est souvent utilisée.

Bien que cette configuration puisse empêcher les temps d'arrêt dus à une défaillance du système, elle peut également entraîner une légère diminution des performances en écriture.

Pour éviter cette baisse, si le nombre d'écritures par seconde attendu, issu du calcul concernant l'ingestion de données, est proche du seuil de la configuration envisagée, il est conseillé d'opter pour la configuration système de taille supérieure.

De nombreux cas d'utilisation métier tirent parti de sessions de tunneling vers les périphériques Edge, qui impliquent que des connexions WebSocket soient ouvertes et maintenues tout au long des sessions.

De même, des outils tiers (tels que SCADA, ERP ou d'autres applications de back-office intégrées) peuvent également utiliser des connexions WebSocket à la plateforme.

Si ces outils accèdent à ThingWorx en effectuant des appels d'API REST, cela augmente le nombre de requêtes HTTP par seconde calculées précédemment pour la visualisation des données.

Chaque connexion WebSocket nécessite de la mémoire sur la plateforme ; veillez par conséquent à augmenter l'allocation de mémoire totale de la plateforme (ou la taille/classe de la machine virtuelle sélectionnée) si de nombreuses sessions de tunneling ou requêtes d'API REST simultanées sont anticipées.

Une certaine quantité de données historiques est souvent nécessaire à la fois pour le traitement des données (jusqu'où ma logique applicative a-t-elle besoin de remonter ?) et pour la visualisation des données (jusqu'où les utilisateurs ont-ils besoin de remonter ?).

Le volume de données historiques à stocker sur la plateforme a une incidence sur le dimensionnement à la fois de la base de données et du système de la plateforme. Les sources de données plus volumineuses (flux, tables de données et flux de valeurs) nécessitent des transactions plus longues lorsqu'elles font l'objet de requêtes dans la base de données. Ces longues transactions peuvent par ailleurs entraîner des sauvegardes des files d'attente des flux et des flux de valeurs et l'utilisation de mémoire supplémentaire.

Agréger les données, de sorte qu'aucune source de données ne contienne trop d'entrées, est par conséquent fortement recommandé. Pour de plus amples informations, consultez ce guide des bonnes pratiques (en anglais). Si une grande quantité de données historiques est nécessaire, ou si des volumes importants de données ingérées doivent être conservés sur une longue période, il est conseillé d'opter pour une solution de base de données plus robuste. Les informations ci-dessous vous seront utiles pour le choix d'une option de base de données :