Informations sur les performances de l'Alumio iPaaS

Dans ce scénario, un éditeur de stockage a été utilisé pour traiter les tâches dans Alumio. Cette fois, nous avons éliminé l'influence de facteurs externes en utilisant un éditeur de stockage au lieu d'un appel d'API, d'une requête de base de données, d'une requête GraphQL, etc. Comme chaque tâche est traitée de manière séquentielle, aucune optimisation n'a été nécessaire. Il est toutefois possible d'améliorer encore les performances en exécutant un traitement en masse ou en mettant à niveau l'environnement d'hébergement.

Les composants suivants ont été utilisés : une configuration sortante, un éditeur de stockage (pour traiter 1 000 tâches de manière séquentielle par exécution), un transformateur d'entités, un filtre de données, un transformateur de motifs de déplacement et un setter de valeurs.

Dans ce scénario, un générateur de données a été utilisé pour créer des tâches dans Alumio. Nous avons éliminé l'influence de facteurs externes en utilisant un générateur de données au lieu d'un appel d'API, d'une requête de base de données, d'une requête GraphQL, etc. Grâce à cette approche, nous avons pu mesurer la surcharge ajoutée par Alumio.

Les composants suivants ont été utilisés lors du test : une configuration entrante, un range Subscriber (pour créer 1 000 entités par exécution), un transformateur d'entités, un filtre de données, un transformateur de motifs de déplacement et un setter de valeurs.