Ecriture dans un fichier log4net FileAppender avec plusieurs problèmes de performances

Question

TickZoom est une application très performante qui utilise sa propre bibliothèque de parallélisation et plusieurs threads O/S pour une utilisation en douceur des ordinateurs multicœurs.

L'application rencontre un goulot d'étranglement où les utilisateurs doivent écrire des informations dans un LogAppender à partir de threads O/S séparés.

FileAppender utilise la fonction MinimalLock afin que chaque thread puisse verrouiller et écrire dans le fichier, puis le relâcher pour que le prochain thread écrive.

Si MinimalLock est désactivé, log4net signale des erreurs sur le fichier étant déjà verrouillé par un autre processus (thread).

Une meilleure façon pour log4net de le faire serait d'avoir un seul thread qui prend soin d'écrire dans FileAppender et tous les autres threads simplement ajouter leurs messages à une file d'attente. De cette manière, MinimalLock peut être désactivé pour améliorer considérablement les performances de la journalisation.

De plus, l'application effectue beaucoup de travail intensif sur le processeur, améliorant ainsi les performances pour utiliser un thread séparé pour l'écriture dans le fichier afin que le processeur n'attende jamais la fin de l'E/S. Donc, la question est, est-ce que log4net offre déjà cette fonctionnalité? Si oui, comment faites-vous activer l'écriture par thread dans un fichier? Y a-t-il un autre appender plus avancé, peut-être? Si ce n'est pas le cas, puisque log4net est déjà encapsulé dans la plate-forme, cela permet d'implémenter un thread séparé et une file d'attente à cet effet dans le code TickZoom.

Sincèrement, Wayne

EDIT:

Merci il semble que les réponses pointent à développer notre propre solution comme peut-être une extension log4net d'une certaine façon. Et ils montrent clairement que log4net ne fait pas ce genre de chose. En outre, nous venons juste de réaliser que nous pourrions abuser du système de journalisation qui est principalement destiné aux messages lisibles par l'homme pour notifier des événements importants ou des informations de débogage. Cette partie particulière de la sortie du logiciel n'est réellement utilisée que pour les outils automatisés qui vérifient la précision du système.

Bien sûr, nous utilisons également log4net de manière "normale" pour le débogage, les avertissements, etc. Mais elles ressemblent plus à des "journaux de transactions" qu'aux journaux de notification de débogage ou d'utilisateur. Plus spécifiquement, il n'est pas nécessaire que ces journaux soient directement lisibles par l'homme. Si nécessaire, un "spectateur" peut afficher le contenu sous forme ASCII. Nous allons donc faire en sorte que ces journaux de type transaction soient écrits dans un stockage binaire à grande vitesse.

Merci, il semble que les deux réponses ci-dessous ont été très utiles pour développer notre propre solution. Log4net ne supporte pas le scénario exact que vous décrivez.

Answer 1

Il offre cependant d'autres appenders qui ne se verrouillent pas, comme l'appender de la base de données, ou l'appender UDP.Voici quelques idées:

1. Connectez vos messages à un message file d'attente, puis un lecteur (ou plusieurs lecteurs) lire les messages hors la file d'attente et les écrire dans un journal. Ceci fournit un mécanisme fiable pour envoyer/écrire des messages. Pour être honnête Je ne sais pas s'il y a déjà un MSMQ appender, mais l'écrire ne serait pas trop dur.

2. Utilisez le appender UDP pour envoyer des messages puis écrire votre propre service qui écoute ces messages et les écrit dans un fichier.

Je pense que vous pouvez détecter un thème ici ... utiliser essentiellement l'une des appenders non bloquants (ou écrire votre propre) et mettre en œuvre votre propre service qui reçoit les messages des appenders et les écrit dans un fichier .

Answer 2

Il est tout à fait souhaitable d'éviter d'ajouter des E/S aux threads de votre cible. Il est donc recommandé d'envoyer un message au thread du collecteur de journaux. J'utilise aussi parfois System :: Diagnostics :: Debug :: WriteLine du thread cible pour vider sa sortie, mais il y a forcément un peu de verrouillage dedans de toute façon. Bien sûr, l'ajout d'une journalisation supplémentaire va conduire à des effets "Heisenberg", donc vous devez savoir en quelque sorte quand ces effets sont négligeables et quand ils ne le sont pas, afin d'avoir une journalisation utile de vos threads haute performance.

Si vous voulez obtenir un peu plus de colombophilie, vous pouvez demander à chaque thread d'enregistrer sa propre liste de messages, puis de le vider quelque part après tant d'itérations. Ainsi, les données ne seraient utiles que dans la période de temps avant que n'importe quel thread fasse ses E/S de journalisation, mais peut-être que vous pourriez capturer assez d'informations pour votre débogage. En outre, vous obtenez la tâche amusante de rassembler les journaux de thread individuels dans un seul journal pour l'analyse.

Answer 3

Découvrez l'enregistreur Object Guy pour un enregistreur de sécurité multi-thread hautes performances avec possibilité de journalisation asynchrone ainsi que de nombreuses autres fonctionnalités - plutôt sympa je pense - http://www.theobjectguy.com/DotNetLog/. Voir la vidéo multithread sur cette page.