Bonnes pratiques pour le développement de solutions > Bonnes pratiques pour les applications haute disponibilité
Bonnes pratiques pour les applications haute disponibilité
Le fait de rédiger le code JavaScript correctement et de limiter les allers-retours dans ThingWorx Platform permettra toujours d'améliorer les performances. Pour prendre en charge le mode cluster haute disponibilité dans ThingWorx 9, le stockage et l'utilisation du modèle ont changé et un mécanisme d'état partagé permettant de préserver la synchronisation des données sur les serveurs a été implémenté. Ces modifications ont un impact sur les performances de certaines API, car elles effectuent plus de tâches qu'avant pour récupérer les mêmes informations. S'il n'est pas optimisé pour améliorer ses performances, l'exécution du code peut prendre du temps dans ThingWorx 9 et encore plus dans un environnement de cluster.
Les informations sur le modèle ne sont plus stockées sur l'objet. Le système parcourt chaque fois l'arbre du modèle pour obtenir ces informations. Toutes les API qui récupèrent des informations sur les objets sont affectées.
Les états de service JavaScript sont désormais conservés dans une couche de cache.
En mode serveur unique, il s'agit d'un cache en mémoire assez rapide, mais qui prend plus de temps que le simple stockage dans l'objet. En mode cluster, le cache est distribué et chaque appel effectue un aller-retour vers un hôte distant. Cela peut ajouter une latence aux appels et n'est pas facilement contrôlé.
La couche de cache peut être locale ou distante. Le nouveau système crée un proxy unidirectionnel de l'objet JavaScript vers l'objet original. Ainsi, chaque modification apportée à l'objet JavaScript déclenche une mise à jour complète de la propriété dans l'objet original. Toutefois, les modifications apportées à l'objet original ne sont pas répercutées dans l'objet JavaScript.
Tout doit être traité comme un objet distant. Avec les objets distants, pour supprimer la latence, il est important de limiter au maximum les appels dans l'espace distant. La même approche doit être adoptée lors de l'appel d'API sur le serveur. Il est préférable de limiter au maximum les appels.
Est-ce que cela a été utile ?