Nouvelles fonctionnalités
Le script AMI de 3forge inclut désormais un support supplémentaire pour la concurrence et la pausabilité sans la complexité du développement traditionnel basé sur les threads.
Pourquoi c'est important
Les avantages en termes de performance du multi-threading sont essentiels pour les applications se connectant à des sources de données distantes et traitant de grands ensembles de données. Le nouveau support de la concurrence et de la pausabilité dans le script AMI vise à optimiser le code qui ne retourne pas immédiatement, notamment les appels à des systèmes distants ainsi que le code qui traite de grands ensembles de données. La concurrence et la pausabilité permettent à 3forge d'implémenter des comportements qui fonctionnent comme le multi-threading, mais sans la complexité et la charge de support.
Le threading expliqué
En informatique, un thread représente le traitement d'un flux d'instructions unique par un processeur (CPU). Une application mono-thread est un ensemble d'instructions contenu exécuté dans un flux unique. Si certaines applications traitent et se terminent rapidement, d'autres applications fonctionnent indéfiniment comme une interface utilisateur (IU).
Le terme "Multi-Threading" entre en jeu lorsque l'ordinateur est responsable de l'exécution simultanée de plusieurs flux d'instructions dans une application. Le threading est analogue à une seule personne rédigeant un document par opposition à plusieurs personnes. Avec une seule personne, il n'est pas nécessaire de coordonner les mises à jour ni de fusionner les changements. Avec plusieurs personnes, le document peut prendre forme plus rapidement, mais le processus de composition nécessite une coordination pour éviter que des changements ne soient écrasés.
Exemple: application de reporting de transactions mono-thread
Le Trade Reporter est un processus mono-thread qui génère un rapport des "nouvelles transactions" toutes les 30 secondes, en:
- Interrogeant des données de transaction (appel bloquant)
- Interrogeant des données de référence sur la contrepartie associée (appel bloquant)
- Générant un fichier de rapport (par ex. CSV) basé sur les deux ensembles de données
- Publiant le rapport par email ou SFTP (appel bloquant)
Le processus de reporting se déroule séquentiellement dans le cadre d'un flux d'instructions unique. Le Trade Reporter effectue un appel bloquant à un gestionnaire de données de référence hébergé sur un serveur séparé. Le modèle de threading du gestionnaire de données de référence n'est pas pertinent. Cependant, il est important de comprendre qu'il écoute les demandes de données de référence, puis construit et transmet une réponse, ce qui prend un temps précieux qui ralentit le Trade Reporter.
Limitations de performance
La version mono-thread du Trade Reporter fonctionne bien pendant un certain temps, jusqu'à ce que les volumes de transactions et de données de référence augmentent significativement. Le processus doit effectuer deux appels à des systèmes distants pour (1) obtenir des données de transaction, et (2) obtenir des données de référence client. Si l'entreprise négocie maintenant avec 3 fois plus de contreparties et produit 5 fois le volume de transactions, ces appels prendront plus de temps et mettront en péril la capacité du Trade Reporter à construire le rapport en moins de 30 secondes.
Optimisation des performances: mettre en cache et interroger les données de référence avec un thread séparé
En partie parce que les données de référence ne changent pas aussi souvent que les données de transaction, une décision est prise d'employer un thread séparé pour mettre en cache les données de référence, rendant les résultats disponibles pour une interrogation rapide depuis un cache de données local basé sur Map. Cette approche minimise le blocage pendant le processus de génération de rapport.
Puisque l'appel bloquant au serveur de données de référence a été retiré du flux d'exécution principal, le Trade Reporter accélère considérablement car les appels au cache de données de référence retournent immédiatement. Le rapport peut maintenant être produit facilement dans l'intervalle de 30 secondes.
Jusque-là, tout va bien, mais comme dans l'exemple mentionné précédemment de création de documents par plusieurs personnes, les mises à jour du cache de données de référence doivent être coordonnées ou "thread-safe" en jargon technique. En l'absence de coordination, le reporter peut finir par interroger un cache vide ou partiellement rempli en cours de reconstruction. Des mécanismes de codage tels que les sémaphores et les blocs synchronisés peuvent aider, mais le code résultant est significativement plus complexe par rapport à la variante mono-thread.
Développement asynchrone 3forge: vous l'utilisez déjà
L'exécution asynchrone via des instructions coroutine pausables fait partie intégrante du script AMI depuis des années maintenant. De nombreux développeurs ne s'en sont peut-être pas rendu compte, mais apprécient certainement que leur interface utilisateur ne se bloque pas lors de l'envoi d'un email ou de l'exécution d'une ou plusieurs grandes requêtes de base de données.
Les coroutines offrent la possibilité de suspendre et de reprendre l'exécution sans la complexité du threading. L'implémentation de 3forge adhère au modèle async/await, qui vise à permettre au code de ressembler à une conception synchrone, mais permet en fin de compte une exécution asynchrone sans ajouter de threads. Par conséquent, une instruction dans 3forge est déclarée comme tout autre bloc de code synchrone, mais au lieu d'une exécution immédiate, elle est préparée pour l'exécution et mise en file d'attente par le thread actif.
La portée d'une instruction pausable
Lorsqu'une méthode contient une instruction pausable, elle est considérée comme une "formule pausable". Toutes les instructions précédant l'instruction différée sont exécutées en ligne. Les instructions différées, y compris le code suivant, sont mises en file d'attente pour une exécution ultérieure. Sans un bloc "dispatch", la limite de l'instruction différée est déterminée comme étant la fin de la méthode. Ainsi, une méthode qui a deux instructions différées s'exécutera toujours séquentiellement sauf si des blocs concurrents sont utilisés.
Concurrence
La concurrence permet d'exécuter simultanément plusieurs blocs de code pausable. Par exemple, si une méthode est requise pour interroger des données provenant de trois sources de données, une approche concurrente permettrait d'interroger toutes les sources en même temps et d'éviter une exécution séquentielle "l'une après l'autre".
Performance accrue en mélangeant concurrence et pausabilité
Dans 3forge, plusieurs instructions pausables peuvent être exécutées en parallèle dans un bloc de code concurrent. Les nouveaux éléments de script AMI pour la concurrence et la pausabilité incluent le bloc concurrent{}, qui enveloppe un ensemble d'instructions pausables exécutées en parallèle, et le bloc dispatch{}, qui définit un bloc d'instructions pausables.
L'exécution concurrente est résistante aux défaillances
Un bloc de code dispatché peut échouer et être isolé avec une gestion des erreurs appropriée, permettant aux flux d'exécution restants de se terminer et de retourner.
Quand utiliser des instructions pausables
Bien que puissantes dans de nombreuses circonstances, il existe des scénarios où les instructions pausables ne font pas sens, notamment les scénarios où un bloc de code est exécuté de manière répétée dans une boucle serrée (par ex. un filtre de colonne). Pour éviter les goulots d'étranglement de performance du système, 3forge ne permet pas l'exécution d'instructions pausables dans les scénarios lambda, notamment les instructions SQL et les formules d'IU Web.
