Souscrire

UiPath Insights

Le guide UiPath Insights

Performances et évolutivité

Vue d'ensemble (Overview)


Cette rubrique couvre les métriques de performances et d'évolutivité des modèles de déploiement Insights Standalone et Automation Suite, destinées aux administrateurs. Les performances examinent les manières dont les données sont ingérées et traitées en arrière-plan, ainsi que les temps de chargement du tableau de bord et la configuration matérielle requise.

La plus grande échelle à laquelle Insights peut fonctionner


The assumption of the total events that are supported over a two year period, with the current hardware requirements is the following:

  • Jusqu'à 100 millions d'emplois ;
  • Jusqu'à 1 milliard d'événements de tâche ;
  • Jusqu'à 100 millions d'éléments de file d'attente ;
  • Jusqu'à 500 millions d'événements d'éléments de file d'attente ;
  • Jusqu'à 1 milliard de journaux de robot.

Ensemble de données de test de performances


Un test de performances a été effectué avec la configuration suivante :

  • 100 millions de tâches, 1 milliard d'événements de tâche, 1 milliard de journaux de robot, 100 millions d'éléments de file d'attente, 500 millions d'événements d'élément de file d'attente. Pour chaque tâche, il existe 10 événements de tâche, 10 journaux de robot, 1 élément de file d'attente et 5 événements d'élément de file d'attente associés.
  • En moyenne, la taille brute des journaux du robot est de 4 Ko chacun, tandis que l'élément de la file d'attente (y compris les données personnalisées via Analytics, Output et Specific Data) est de 9 Ko.
  • Il existe 400 processus, dont un seul génère 20 % des données.
  • L'utilisation totale du disque dans Azure SQL est d'environ 5,7 To.

Taille initiale des données

#Database Table NameSchema NameNumber of RowsUsed Disk Space (GB)
1RobotLogsdbo10000044164095.45
2QueueItemsdbo106332315916.56
3JobEventsdbo1022790964499.09
4QueueItemEventsdbo520882100200.08
5Jobsdbo10569787828.33

Taille des données après le remplissage (déplacement des données du magasin brut dans dbo vers columnstore en lecture)

🚧

Important

For optimal performance, tables in the read schema use a columnstore index, meaning that the data is compressed so the size consumption is decreased compared to the dbo schema.

#Database Table NameSchema NameNumber of RowsUsed Disk Space (GB)
1RobotLogsread100000441045.71
2QueueItemsread106328486.5
3JobEventsread102227909529.62
4QueueItemEventsread5208690004.86
5Jobsread1056974428.09

Prérequis matériels

Une configuration Azure SQL (40 cœurs, 200 Go de mémoire, 7 To de disque, modèle d'achat vCore - Azure SQL Database) a été utilisée pour exécuter les tests de performances comme suit :

  • Base de données Insights, Azure SQL Hyperscale, 40 cœurs et 0 réplica ;
  • Azure SQL Hyperscale a été utilisé comme base de données Insights, prenant en charge plus de 5 To de disque ;
  • Le DOP MAX a été fixé à 16 par
    ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 16;
  • Machine virtuelle Insights, Insights 22.10, Standard D8s v4 (8 processeurs virtuels, 32 Gio de mémoire)
  • Machine virtuelle Looker, Looker 22.10, Standard D4s v3 (4 processeurs virtuels, 16 Gio de mémoire)
  • Machine virtuelle Orchestrator, 22.10, Standard D4s v3 (4 processeurs virtuels, 16 Gio de mémoire)
  • Machine virtuelle de base de données Orchestrator, Standard D8s v3 (8 processeurs virtuels, 32 Gio de mémoire)

Test de performances

Les caractéristiques de performance suivantes ont été évaluées :

  • Performances du « chemin de lecture » : vitesse à laquelle les tableaux de bord affichent les informations.
  • Performances du « chemin d’écriture » : à quelle vitesse les données peuvent être ingérées dans le système et à quelle vitesse les données peuvent être traitées avant de devenir disponibles pour la consommation. Cela se produit en arrière-plan et s'exécute périodiquement par lots. Lorsque ce traitement en arrière-plan est en cours d'exécution, il consomme des ressources du serveur, ce qui laisse moins de ressources pour le « chemin de lecture ». C'est la raison pour laquelle les tableaux de bord peuvent se charger plus lentement lorsque l'ingestion ou le traitement des données est en cours d'exécution. Ce test incluait également la configuration de variables personnalisées à partir des journaux et des files d'attente du robot pour les utiliser dans les tableaux de bord.

Insights background processes

Insights exécute les processus d'arrière-plan suivants sur le serveur SQL :

  • Par défaut, l'ingestion de la base de données Orchestrator vers la base de données Insights se produit toutes les 15 minutes.
  • Le pipeline de transformation déplace les données vers le schéma de lecture pour préparer les tâches, les éléments de la file d'attente et les journaux du robot à être utilisés par un tableau de bord toutes les 10 minutes.
  • Le pipeline de transformation extrait les variables personnalisées des journaux et des files d'attente du robot pour être utilisées par un tableau de bord lorsque la configuration des champs personnalisés est modifiée. Dans les tests de performances, le changement se produit toutes les 6 heures pour simuler le pire des cas. Dans le cadre d'une utilisation normale du produit, la configuration des champs personnalisés n'est pas modifiée souvent.
    En moyenne, les événements de tâche, les événements d'élément de file d'attente et les journaux de robot génèrent de 1 à 10 nouveaux éléments par seconde (par exemple, 5 nouveaux éléments de file d'attente par seconde).

📘

Remarque

Background jobs running may impact the loading time of a dashboard.

Template loading time

Les tests ont mesuré le temps de chargement des modèles prédéfinis. Lors de la mesure du temps de chargement du tableau de bord, deux mesures ont été enregistrées :

  • p90 (quatre-vingt-dixième centile) le temps de chargement qui représente le pire des cas lorsqu'un utilisateur reconfigure des champs personnalisés qui démarrent une tâche d'arrière-plan coûteuse qui consomme des ressources du serveur.
  • Temps de chargement moyen.

Chaque tableau de bord comporte plusieurs widgets. Dans certains des tableaux de bord, la plupart des widgets se chargent beaucoup plus rapidement que les widgets aberrants. C’est le cas pour les tableaux de bord ROI métier et Files d’attente ROI métier.

Tous les tableaux de bord sont chargés avec l'heure par défaut indiquée dans le filtre.

DashboardNumber of queried rows*p90 (seconds)Average time (seconds)
Business ROI (This Quarter)**28 million1917
Business ROI Queues (This Quarter)**28 million1210
Processes (last 30 days)20 million2520
Queues (last 30 days)10 million98
Robots (last 30 days)5 million1312

*Par défaut, chaque tableau de bord ne traite qu'une partie de l'ensemble des données (par exemple, les 30 derniers jours sur les données réparties sur 2 ans). Nous estimons le nombre de lignes que chaque tableau de bord traite avec une sélection de filtre par défaut.

** ROI métier et les files d'attente ROI métier ont un widget lent (widget mensuel enregistré). Avec le widget lent, le temps de chargement du ROI métier est de 399 secondes à p90 et de 324 secondes en moyenne. Business ROI Queues est de 193 secondes à p90 et de 145 secondes en moyenne.

Mis à jour il y a 5 mois


Performances et évolutivité


Les modifications suggérées sont limitées sur les pages de référence de l'API

Vous pouvez uniquement suggérer des modifications au contenu du corps de Markdown, mais pas aux spécifications de l'API.