Exécution d'un banc d'essai

Un autre aspect des performances des Runbook est la journalisation des données. Afin de mieux comprendre les performances, prenons deux configurations de journalisation : La journalisation par défaut et la journalisation des données publiées communes. La journalisation par défaut écrit environ 524 octets de données dans la base de données Orchestrator à chaque exécution d'une activité. La journalisation des données publiées communes écrit environ 6 082 octets de données (12 fois le niveau par défaut). Il existe une différence notable de performances entre ces niveaux de journalisation.

Prenons le cas où la même activité de Runbook est exécutée deux fois, une fois avec la journalisation des données par défaut et une fois avec la journalisation des données publiées communes activée. Le code de domaine doit prendre le même temps pour aboutir. Toutefois, le code de plate-forme prendra plus de temps à s'exécuter si la consignation des données publiées communes est activée. Fondamentalement, le code de plate-forme doit gérer la journalisation de 12 fois plus de données avec les données publiées communes activées qu'avec la journalisation par défaut.

L'activité standard Comparer des valeurs peut être utilisée pour créer des bancs d'essai d'un environnement Orchestrator.

Ce simple Runbook à une activité exécute une activité Comparer des valeurs 10 000 fois.Comparer des valeurs est une activité très simple dont le code de domaine est relativement réduit. Ce Runbook peut être appelé dans différentes circonstances pour caractériser les performances globales d'un environnement d'exécution Orchestrator donné.

Ce Runbook peut servir à tester différentes configurations d'Orchestrator. Par exemple, supposons que vous souhaitiez déterminer les performances de quatre serveurs Runbook déployés sur différents centres de données.

Remarquez la diminution considérable des performances de la plate-forme provoquée par la journalisation des données publiées communes. Le pire scénario semble être la journalisation des données publiées communes à l'emplacement 2. À première vue, cela semble être une conclusion claire et pertinente.

Toutefois, il convient de noter que ces chiffres correspondent à la surcharge du code de plate-forme, pas du code de domaine. Les exécutions de code de domaine peuvent être beaucoup plus longues. Par exemple, l'activité Créer un ordinateur virtuel à partir d'un modèle du pack d'intégration de Virtual Machine Manager peut s'exécuter pendant plusieurs minutes lors de la création de l'ordinateur virtuel. Pour poursuivre avec l'exemple précédent, envisageons les coûts de code de plate-forme sur une activité de Runbook qui prend une minute à s'exécuter (1 minute = 60 000 millisecondes), indépendamment de son emplacement.

Une image plus claire commence à émerger des données. Le scénario selon lequel la journalisation des données publiées communes est activée à l'emplacement 2 continue de présenter les pires performances. Toutefois, le code de la plate-forme et la journalisation représentent seulement 6 % du temps total d'exécution. Même si ce chiffre est intéressant, le scénario idéal est de 1,4 %. Essentiellement, le temps passé dans le code de domaine dans l'exemple compense largement le temps passé à exécuter le code de plate-forme. Pour mettre cela en perspective, même si vous avez supprimé totalement les coûts du code de plate-forme, vous constatez des améliorations dans les performances du Runbook uniquement dans une fourchette comprise entre 1,4 % et 7,4 %.

Bien entendu, dans la plupart des cas, les scénarios réels sont différents. Le comportement des activités peut varier en fonction des instructions que reçoit le code de domaine. Par exemple, une activité Cloner un ordinateur virtuel à partir d'un modèle peut prendre une minute pour cloner un ordinateur virtuel à partir d'un modèle de serveur A, mais prendre 5 minutes pour cloner un ordinateur virtuel à partir d'un modèle de serveur B. En outre, les serveurs Runbook peuvent être hébergés sur des réseaux différents dotés de caractéristiques de performances différentes, qui peuvent potentiellement avoir un impact sur les performances du code de domaine ainsi que sur les performances de journalisation des données Orchestrator.

Pour récapituler :

• Prenez des décisions avisées concernant le moment de la journalisation des données publiées.

• Étudiez attentivement l'impact de la journalisation des données publiées communes. N'oubliez pas que le nombre d'exécutions d'activités détermine le volume des données journalisées. Un Runbook comptant un petit nombre d'activités exécutées plusieurs fois peut engendrer un plus grand volume de journalisation des données qu'un Runbook plus important exécuté un nombre de fois plus réduit.

• N'activez pas la journalisation de données publiées spécifiques à une activité dans les environnements de production.

• Comprenez bien le temps que passent vos Runbook à exécuter du code de domaine par rapport au code de plate-forme.

• Estimez les coûts en termes de code de plate-forme en utilisant les techniques décrites dans ce document. Utilisez-les comme référence pour décider où apporter des améliorations aux performances des Runbook.

• Utilisez les techniques présentées dans ce document pour mieux comprendre les performances relatives de vos différents environnements d'exécution. Identifiez les opportunités d'amélioration du produit par des comparaisons normalisées de vos mesures.