J'ai une application de service qui traite des demandes de clients sur TCP et qui rédige des événements dans Windows EventLog. Étant donné que cette demande devrait conserver de nombreux clients et beaucoup de demandes de chaque client en peu de temps (disons entre 1 et 50 demandes par seconde), je suis curieux de savoir comment intensive (CPU sage et temps sage) et À quelle vitesse peut écrire dans Windows EventLog être?
Plus précisément, à quel point les opérations de la connexion et de la rédaction de la lecture et de l'écriture à EventLog?
4 Réponses :
J'ai effectué un test avec mes 2 classes de journal d'événements, une écriture à fichier (chaque dans mes fichiers d'opinion sont meilleurs: ils sont facilement analysés dans des outils tels que GREP. La vitesse est moins importante pour moi. log_event () écrit et flushes déjà ouvert fichier) et sur basé sur EventLog ( redevent () Appelez sur les événements déjà enregistrés). Dans mon compte, le journal du dossier était environ 10 fois plus rapide que EventLog. Dans l'environnement multithread, j'ajouterais une section critique pour protéger l'écriture au fichier.
C'est le genre de réponse que je cherchais. J'accepte également que l'utilisation de fichiers journaux est une méthode meilleure, plus rapide et plus simple, mais j'ai reçu une tâche de maintenir une application de service existante qui rédige tous les événements dans Windows EventLog. J'ai supposé que c'est une installation de journalisation "lourdes", c'est pourquoi j'ai demandé à ma question.
Ne faites pas ça. Le journal des événements n'est pas conçu pour une telle activité:
Le journal des événements n'est pas une installation de journalisation générale. Il devrait être utilisé pour signaler des erreurs, des situations nécessitant une attention particulière, et même des rapports informatifs, mais tout chaque peu d'informations il faut écrire quelque part. Si vous avez des besoins en journal Heavt, utilisez vos propres installations de journal et des problèmes de rapport - le cas échéant - dans le journal des événements avec un "pointeur" où trouver des données détaillées si nécessaire.
Remarque: Si vraiment le journal des événements est nécessaire, au moins l'application doit utiliser sa propre destination de journal, pas l'une des standard (application ou système d'application ou même pire). De cette façon, cela n'aura pas d'impact sur les autres opérations d'applications et ne "cacher" pas d'autres événements d'application "inonder" le journal avec ses événements, rendant plus difficile à repérer les autres sans les chercher.
+1 Bon conseil, mon application a une fois rempli le journal des événements sur le site d'un client et il n'a provoqué aucun problème!
Je suis d'accord avec votre recommandation. Dans mon cas, je dois conserver une demande de service existante qui écrit sur EventLog. Je voulais donc savoir si et à quel point cela peut influer sur la performance globale des applications.
Vous risquez d'affecter le fonctionnement général de Windows et toutes les applications exécutées sur la machine. Jusqu'à toi et à vos clients, de toute façon.
Voir aussi ma note sur l'utilisation d'un journal des événements dédié à l'application pour éviter de "inonder" les standards.
Tracing d'événement pour Windows serait probablement être un meilleur référentiel pour ce niveau de trafic.
Quels événements écrivez-vous au journal des événements? Un pointeur à la réponse à votre question pourrait être que l'IIS et les serveurs similaires écrivent aux journaux de texte et non au journal des événements.
Seuls les simples messages texte pour le moment. L'utilisation d'un fichier texte simple (fichier journal) est également une option, mais je veux toujours en savoir plus sur EventLog.