Journalisation dans un environnement multiprocesseur
Mise à jour : novembre 2007
La capacité multi-processeur de MSBuild 3.5 peut réduire considérablement la durée de génération d'un projet, mais accentue aussi la complexité de journalisation. 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 plusieurs sources peuvent arriver simultanément ou en désordre. MSBuild 3.5 fournit un nouveau journal multi-processeur et permet la création de « journaux de transfert » personnalisés.
Enregistrement de générations avec plusieurs processeurs
Lorsque vous générez un ou plusieurs projets dans un multi-processeur, les événements de génération MSBuild pour tous les projets sont générés simultanément. Une avalanche de données d'événement peut arriver au journal en même temps ou hors séquence. Elle risque d'encombrer le journal et d'augmenter la durée de génération, de produire des journaux incorrects, voir même d'interrompre la 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 la journalisation en créant un journal de transfert personnalisé. Un journal de transfert personnalisé agit comme un filtre vous permettant de choisir, avant la génération, les événements à contrôler. Avec un journal de transfert personnalisé, les événements inutiles ne viennent pas saturer vos journaux ni ralentir la génération.
Modèle de journalisation central
Pour la génération multi-processeur, MSBuild utilise un « modèle de journalisation central ». Dans ce modèle, une instance de MSBuild.exe sert de processus de génération principal, ou « nœud central ». Les instances secondaires de MSBuild.exe, ou « nœuds secondaires », sont jointes au nœud central. Tous les journaux au nœud central sont appelés comme « journaux centraux » et les journaux joints aux nœuds secondaires sont nommés « journaux secondaires ».
Lorsqu'une génération se produit, les journaux secondaires dirigent leur trafic d'événement vers les journaux centraux. Comme les événements proviennent de plusieurs nœuds secondaires, les données arrivent simultanément au nœud central mais sont entrelacés. Pour résoudre les références événement-à-projet et événement-à-cible, les arguments d'événement incluent des informations de contexte d'événement de génération supplémentaires.
Si le journal central ne soit d'implémenter que ILogger, il est toutefois recommandé d'implémenter également INodeLogger pour initialiser le journal central 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);
}
Modèle de journalisation distribué
Avec le modèle de journalisation central, un trafic entrant trop volumineux comme c'est le cas lors de la génération simultanée de plusieurs projets, peut encombrer le nœud central et saturer le système en réduisant les performances de génération.
Pour réduire ce problème, MSBuild active également un « modèle de journalisation distribué » qui étend le modèle de journalisation central en vous laissant créer des journaux de transfert. Un journal de transfert est joint à un nœud secondaire et reçoit des événements de génération entrants de ce nœud. Le journal de transfert est comparable à un journal normal mais peut filtrer les événements et envoyer les événements appropriés au nœud central. Il réduit ainsi le trafic de messages destiné au nœud central et par conséquent accélère les performances.
Vous pouvez créer un journal de transfert en implémentant l'interface IForwardingLogger, qui dérive de ILogger. L'interface se définit de la manière suivante :
public interface IForwardingLogger: INodeLogger
{
public IEventRedirector EventRedirector { get; set; }
public int NodeId { get; set; }
}
Pour transférer les événements vers un journal de transfert, appelez la méthode ForwardEvent de l'interface IEventRedirector. Passez le BuildEventArgsapproprié, ou un dérivatif, comme paramètre.
Pour plus d'informations, consultez Création de journaux de transfert.
Journal distribué joint
Pour joindre un journal distribué sur une génération de ligne de commande, utilisez le commutateur /distributedlogger (ou, /dl en abrégé). Le format à utiliser pour spécifier les noms des types de journaux et les classes est le même que celui du commutateur /logger, mais un journal distribué se compose de deux classes de journalisation, le journal de transfert et le journal central. L'exemple suivant illustre comment joindre un journal distribué :
C:\ WINDOWS\Microsoft.NET\Framework\v3.5.20301>msbuild.exe *.proj
/distributedlogger:XMLCentralLogger,MyLogger,Version=1.0.2,
Culture=neutral*XMLForwardingLogger,MyLogger,Version=1.0.2,
Culture=neutral
Un astérisque (*) sépare les deux noms de journal dans le commutateur /dl.