Ce guide présente les bonnes pratiques pour concevoir des applications Tulip hautement performantes, capables d’évoluer efficacement dans des environnements de production. Le respect de ces recommandations vous aidera à garantir que vos applications restent réactives et stables, même à mesure que votre activité se développe.
Les recommandations de cet article s’appliquent dès lors que vos solutions incluent l’utilisation de fonctions de connexion à l’API Tulip. Il s’agit notamment :
- les exécutions de fonctions de connexion ou les « API Calls » déclenchées par des événements au niveau de l’application (minuterie, bouton, entrée dans une étape, par exemple)
- les appels API depuis Node-RED
- Les scripts comportant des appels API provenant de sources extérieures aux solutions Tulip
- Les écritures dans les tables Tulip à l’aide de l’API Table depuis d’autres systèmes
Qu’est-ce qu’un déclencheur à haute fréquence ?
Un déclencheur à haute fréquence s'exécute plus souvent que toutes les 5 secondes (à une fréquence supérieure à 0,2 Hz). Les événements liés aux attributs de la machine, les événements liés aux appareils et les déclencheurs de minuterie sont les sources les plus courantes d'exécution à haute fréquence.
Tulip recommande que les déclencheurs ne s’exécutent pas plus rapidement que toutes les 5 secondes (0,2 Hz) afin de préserver les performances et la réactivité de l’application.
Impact sur la file d’attente des déclencheurs
Les déclencheurs de l'application s'exécutent de haut en bas dans une file d'attente séquentielle à thread unique, appelée « file d'attente des déclencheurs ».
Deux facteurs déterminent si la file d’attente fonctionne efficacement :
- Taux d’entrée dans la file d’attente: fréquence à laquelle les événements déclencheurs sont ajoutés à la file d’attente
- Taux de sortie de la file d’attente: la rapidité avec laquelle la logique de déclenchement termine son exécution
Lorsque les déclencheurs entrent dans la file d’attente plus rapidement qu’ils n’en sortent, celle-ci s’accumule. Une accumulation prolongée dans la file d’attente des déclencheurs entraîne une latence de l’application et, dans certains cas, la perte d’événements de déclenchement.
Comparez la fréquence des déclencheurs au trafic sur une autoroute. Si trop de voitures s’engagent sur l’autoroute en peu de temps, la circulation ralentit. Pour éviter les bouchons, les voitures doivent s’engager à un rythme que l’autoroute peut supporter.
Fréquence combinée
Le taux combiné de tous les événements de déclenchement d’une application détermine le taux global d’entrée dans la file d’attente. Chaque événement de déclenchement que vous configurez s’ajoute à ce taux combiné.
Consultez le tableau ci-dessous pour des exemples de fréquence combinée :
| Configuration | Fréquence combinée |
|---|---|
| 1 attribut de machine mis à jour toutes les 1 seconde | 1 Hz |
| 5 attributs de machine mis à jour toutes les 1 seconde | 5 Hz |
| 1 attribut de machine (1 s) + 1 temporisateur (2 s) | 1,5 Hz |
Échelle de vitesse de la logique de déclenchement
Le type de logique de déclenchement détermine la rapidité avec laquelle les déclencheurs quittent la file d’attente. Les logiques nécessitant une communication avec le cloud, des transitions ou des réponses de systèmes externes prennent nettement plus de temps à s’exécuter que les opérations locales.
Le tableau ci-dessous décrit la vitesse des différents types de logique.
For high-frequency triggers, aim to use only logic rated Very fast or Fast.
| Vitesse | Type de logique | Exemples |
|---|---|---|
| Très rapide | Logique d'application locale | Lecture ou mise à jour de données locales (par exemple, des variables) |
| Rapide | Données cloud mises en cache | Lecture d'enregistrements de table déjà chargés |
| Moyenne | Tulip Cloud | Chargement, mise à jour ou création d’enregistrements de table ; lecture ou mise à jour de l’état d’une machine |
| Lente | Tulip Cloud | Agrégations et requêtes sur les tables |
| Très lent | Systèmes externes | Fonctions du connecteur |
There is currently no easily accessible app performance log available for evaluating trigger performance. App performance can only be inferred through step times in completion records, which is useful in cases where steps involve extensive looping.
Facteurs techniques ayant un impact sur les performances des déclencheurs
- Matériel local: la logique des déclencheurs s'exécute sur le matériel local ; les spécifications de l'appareil ont donc un impact déterminant sur la rapidité avec laquelle les déclencheurs s'exécutent et quittent la file d'attente. Pour connaître les spécifications des appareils, consultez la section « Appareils recommandés pour Tulip Player ».
- Dépendances externes – Les dépendances externes comprennent la connectivité au cloud, la latence du réseau local et le temps de réponse des systèmes externes tels que les progiciels de gestion intégrée (ERP).
- Appareils connectés via des périphériques Tulip Edge: les applications Tulip dépendent de la connectivité au cloud, ce qui peut entraîner une latence. Par exemple, un contrôleur de couple connecté à un périphérique Edge communique toujours avec Tulip Player via les services cloud Tulip. Pour comprendre les connexions des appareils, consultez ces diagrammes de séquence illustrant les connexions via les pilotes Tulip.
- Problèmes de latence liés aux fonctions de connecteur - Une réponse lente d’un système (par exemple, un ERP) via une fonction de connecteur peut entraîner des retards dans l’application, en particulier si celle-ci parcourt de nombreux enregistrements, chacun pouvant nécessiter un appel API de deux secondes. Pour comprendre les connexions au système, consultez ces diagrammes de séquence relatifs à la connexion aux systèmes d’entreprise.
- Latence entre l’atelier et l’infrastructure cloud Tulip - Afin de minimiser la latence, votre instance Tulip est située dans la même zone géographique que votre atelier.
Conseils
Évitez les déclencheurs à haute fréquence
Dans la mesure du possible, évitez les déclencheurs à haute fréquence et privilégiez d’autres fonctionnalités, telles que les « Automations ».
Vous pouvez également envisager de repenser l’architecture de votre application pour qu’elle fonctionne à un rythme moins soutenu. Par exemple :* Des rapports de données moins fréquents grâce à des requêtes et des agrégations* Pour les cas d’utilisation asynchrones, les boucles peuvent être exécutées via des automatisations* Pour les cas d’utilisation synchrones, les boucles qui doivent être exécutées de manière séquentielle doivent l’être via des fonctions
Si vous devez utiliser un déclencheur à haute fréquence, vous devez le configurer pour qu’il n’exécute que des tâches locales (par exemple, la mise à jour d’une variable d’application). Utilisez ensuite un déclencheur à basse fréquence pour les exécutions plus lentes (par exemple, la mise à jour d’un enregistrement de table).
Si vous utilisez un déclencheur Timer à haute fréquence pour réagir rapidement à un contexte extérieur à une application Tulip, vous pouvez éventuellement utiliser une machine Tulip de type « Event Stream » avec des déclencheurs de machine et d’appareil.
Utilisation des API de table Tulip
L'utilisation des API de table pour lire ou écrire plusieurs fois par seconde peut affecter les performances de votre instance et entraîner des retards dans la lecture ou le stockage des données. Les recommandations ci-dessous s'appliquent à tous les scripts et actions de déclencheur qui exécutent les API Tulip sur une instance Tulip :
Recommandation
- Planifiez l’exécution de votre logique de manière à respecter les limites de débit des tables Tulip
- Évitez les écritures fréquentes sur le même enregistrement d’une table (plus d’une par seconde)
Lorsque les seuils sont dépassés, Tulip peut appliquer une limitation de débit et renvoyer le code d'erreur 429. Les scripts doivent être conçus pour résister aux codes d'erreur 429 et réessayer après un certain délai.
Déclencheurs liés à des machines, des appareils et des minuteries
Les déclencheurs de minuterie à intervalle court (toutes les 1 à 2 secondes) peuvent surcharger vos applications, en particulier lorsque ces déclencheurs impliquent plusieurs appels d’API (par exemple, des écritures dans une table ou l’exécution de fonctions de connecteur).
Tulip no longer supports a timer trigger with <30sec frequency. For timer triggers used in an event-based architecture (i.e. a table record field changed or the current time is 7:00am), we recommend using Machines or [Automations]. Contact your Tulip representative if you have questions about this transition.
Les déclencheurs de machine détectent les modifications d’attributs provenant des équipements connectés et exécutent une logique en réponse. Lorsque les « machine attributes » transmettent des données à haute fréquence ou lorsque plusieurs attributs sont surveillés simultanément, l’exécution des déclencheurs peut dépasser la cadence à laquelle l’application traite ces déclencheurs. Cela peut entraîner une dégradation des performances.
Recommandation
- Limitez les abonnements aux « machine attribute s » à ceux qui sont strictement nécessaires pour l’étape ou le workflow en cours
- Séparez la logique à haute fréquence des opérations cloud et utilisez un déclencheur à fréquence plus faible pour gérer les actions dépendantes du cloud
Exemple de scénario: une « machine attribute » est mise à jour 4 fois par seconde, et vous devez suivre le nombre de mises à jour dans un enregistrement de table. Déclencheur 1 (événement machine) : mettre à jour une variable d’application avec les données machine entrantes. Déclencheur 2 (minuterie, toutes les 10 secondes) : écrire les données cumulées dans un enregistrement de table
| Approche | Configuration | Performances |
|---|---|---|
| Optimales | Le déclencheur machine incrémente la variable d’application ; le déclencheur de minuterie écrit dans la table toutes les 10 secondes | Bonne (fonctionnement en mode « cloud » à 0,1 Hz) |
| Lente | Le déclencheur de la machine écrit directement dans la table à chaque mise à jour | Mauvais (fonctionnement dans le cloud à 4 Hz) |
- Envisagez d’utiliser des automatisations pour le traitement asynchrone afin de soulager la file d’attente des déclencheurs. Par exemple, si les données de la machine doivent être traitées mais ne nécessitent pas de retour immédiat de l’opérateur dans la session de l’application
- N'utilisez que des opérations rapides dans les déclencheurs, telles que la lecture/mise à jour de variables d'application ou la lecture d'enregistrements de table
- Évaluez l’architecture de votre application et envisagez de la repenser pour qu’elle fonctionne à un rythme plus lent si votre cas d’utilisation nécessite la surveillance de nombreux attributs à des fréquences élevées. Voici d’autres approches possibles :
- Agréguer les données au niveau de la machine ou du périphérique en périphérie avant de les envoyer à Tulip
- Utiliser les automatisations pour la collecte et le traitement des données
- Réduire la fréquence de rapport au niveau de la source de données
- Envisagez d’utiliser les pilotes Tulip Player plutôt que les pilotes hébergés sur les périphériques en périphérie
- Pilote Player de l’outil Torque
{{snippet.Avez-vous trouvé ce que vous cherchiez ?}}
