Écriture de journaux prenant en charge plusieurs processeurs

Mise à jour : novembre 2007

La capacité de MSBuild 3.5 de tirer parti de plusieurs processeurs peut décroître le temps de génération d'un projet, mais il ajoute également de la complexité aux journaux d'événements de génération. Dans un environnement à processeur unique, les événements, messages, avertissements et erreurs arrivent aux journaux de façon prévisible et séquentielle. Toutefois, dans un environnement multi-processeur, les événements de sources différentes peuvent arriver au même instant ou hors séquence. Pour subvenir à ceci, MSBuild 3.5 fournit un journal multi-processeur, un nouveau modèle de journalisation et vous permet de créer des « journaux de transfert » personnalisés.

Défis de journalisation avec plusieurs processeurs

Lorsque vous construisez un ou plusieurs projets sur un multi-processeur ou système de multi-cœur, les événements de génération MSBuild pour tous les projets sont générés au même moment. Une avalanche de messages d'événement peut arriver au journal en même temps ou hors séquence. Parce que l'enregistreur de journaux MSBuild 2.0 n'est pas conçu pour gérer une telle situation, il peut submerger le journal et provoquer une augmentation des durées de la génération, des sorties de journal incorrectes, ou même interrompre une génération. Pour résoudre ces problèmes, MSBuild 3.5 peut traiter des événements hors séquence ou les mettre en corrélation avec leurs sources.

Vous pouvez améliorer l'efficacité de journalisation en créant un journal de transfert personnalisé. Un journal de transfert personnalisé agit comme un filtre en vous permettant de choisir, avant de générer, les événements que vous souhaitez surveiller. Lorsque vous utilisez un journal de transfert personnalisé, les événements non désirés ne peuvent pas saturer vos journaux ou ralentir la génération.

Modèles de journalisation multi-processeur

Pour répondre aux problèmes de génération des environnements multi-processeur, MSBuild 3.5 prend en charge deux modèles de journalisation : le modèle central et le modèle distribué.

Modèle de journalisation central

Dans le modèle de journalisation central, une instance unique MSBuild.exe agit comme « nœud central » et les instances enfants du nœud central (« nœuds secondaires ») se joignent au nœud central pour l'aider à effectuer les tâches de génération.

Les journaux de divers types qui s'attachent au nœud central sont connus sous le nom de « journaux centraux ». Seule une instance de chaque type de journal peut être attachée au nœud central à un même instant.

Lorsqu'une génération se produit, les nœuds secondaires routent leurs événements de génération au nœud central. Le nœud central route tous ses événements, et également ceux des nœuds secondaires, à un ou plusieurs des journaux centraux joints. Les journaux créent ensuite des fichiers journaux basés sur les données entrantes.

Bien qu'uniquement, ILogger soit requis pour être implémenté par le journal central, nous vous recommandons d'implémenter également INodeLogger afin que le journal central s'initialise avec le nombre des nœuds qui participent à la génération. La surcharge suivante de la méthode Initialize est appelée lorsque le moteur initialise le journal.

public interface INodeLogger: ILogger
{
    public void Initialize(IEventSource eventSource, int nodeCount);
}

Tout ILoggerpréexistant - les journaux basés peuvent agir comme journaux centraux et peuvent se joindre à la génération. Toutefois, les journaux centraux écrits sans prise en charge explicite des scénarios de journalisation multi-processeur et des événements désordonnés peuvent arrêter une génération ou produire une sortie sans signification.

Modèle de journalisation distribué

Dans le modèle de journalisation central, un trafic de messages entrants trop important peut accabler le nœud central, par exemple, lorsque de nombreux projets génèrent en même temps. Cela peut consommer beaucoup de ressources système et diminuer les performance de génération. Pour réduire ce problème, MSBuild 3.5 prend en charge un modèle de journalisation distribué.

Le modèle de journalisation distribué étend le modèle de journalisation central en vous permettant de créer un journal de transfert.

Journaux de transfert

Un journal de transfert est un journal secondaire, léger, doté d'un filtre d'événement, attaché à un nœud secondaire. Il reçoit des événements de génération entrants de ce nœud. Il filtre les événements entrants et transfère uniquement ceux que vous destinez au nœud central. Cela réduit le trafic de messages envoyé au nœud central et améliore la performance de génération.

Il y a deux façons d'utiliser la journalisation distribuée :

• Personnalisez le journal de transfert prédéfini nommé ConfigurableForwardingLogger.

• Écrivez votre propre journal de transfert personnalisé.

Vous pouvez modifier ConfigurableForwardingLogger pour l'adapter à vos spécifications. Pour cela, appelez le journal avec la ligne de commande en utilisant MSBuild.exe, et répertoriez les événements de génération que vous souhaitez faire envoyer par le journal au nœud central.

Vous pouvez également créer un journal de transfert personnalisé. En créant un journal de transfert personnalisé, vous pouvez régler avec précision le comportement du journal. Toutefois, la création d'un journal de transfert personnalisé est plus complexe que la personnalisation de ConfigurableForwardingLogger. Pour plus d'informations, consultez Création de journaux de transfert.

Utilisation du ConfigurableForwardingLogger pour la journalisation distribuée simple

Pour joindre un ConfigurableForwardingLogger ou un journal de transfert personnalisé, utilisez le commutateur /distributedlogger (/dl raccourcis) dans une génération par ligne de commande MSBuild.exe. Le format pour spécifier les noms des types de journaux et classes est le même que celui pour le commutateur /logger, mais un journal distribué a toujours deux classes d'enregistrement au lieu d'une, le journal de transfert et le journal central. Les éléments suivants sont un exemple de rattachement de transfert personnalisé nommé XMLForwardingLogger.

C:\ WINDOWS\Microsoft.NET\Framework\v3.5>msbuild.exe myproj.proj/distributedlogger:XMLCentralLogger,MyLogger,Version=1.0.2,Culture=neutral*XMLForwardingLogger,MyLogger,Version=1.0.2,Culture=neutral

Remarque :
Un astérisque (*) doit séparer les deux noms de journaux dans le commutateur /dl.

L'utilisation de ConfigurableForwardingLogger est similaire à celle de tout autre journal (comme il est esquissé dans Vue d'ensemble de la journalisation dans MSBuild), mais vous joignez le journal ConfigurableForwardingLogger au lieu du journal MSBuild typique et vous spécifiez comme paramètre les événements que vous souhaitez que le ConfigurableForwardingLogger passe au nœud central.

Par exemple, si vous souhaitez être notifié uniquement du démarrage et de la fin de la génération, ainsi que des erreurs éventuelles, vous passeriez BUILDSTARTEDEVENT, BUILDFINISHEDEVENTet ERROREVENT comme paramètres. Plusieurs paramètres peuvent être passés en les séparant avec les points-virgules. Les éléments suivants sont un exemple d'utilisation du ConfigurableForwardingLogger pour transférer uniquement les événements BUILDSTARTEDEVENT, BUILDFINISHEDEVENTet ERROREVENT.

C:\ WINDOWS\Microsoft.NET\Framework\v3.5>msbuild.exe myproj.proj /distributedlogger:XMLCentralLogger,MyLogger,Version=1.0.2,Culture=neutral*ConfigureableForwardingLogger,C:\My.dll;BUILDSTARTEDEVENT; BUILDFINISHEDEVENT;ERROREVENT

La liste des paramètres disponibles pour ConfigurableForwardingLogger :

Voir aussi

Concepts

Création de journaux de transfert