Quel est l'impact sur les performances de traçage en C # et ASP.NET?

Question

J'ai trouvé dans un code de connexion de production Je regardais récemment ...

HttpContext.Current.Trace.Write(query + ": " + username + ", " + password));

... où la requête est une courte requête SQL pour récupérer les utilisateurs correspondants. Est-ce que cela a une sorte d'impact sur les performances? Je suppose que sa très faible.

En outre, quel est le but de ce type de tracé exact, en utilisant le contexte HTTP? D'où ces données se remonte à? Merci d'avance!

Answer 1

Oui, il aura un impact sur les performances chaque fois que la TRACE conditionnelle constante de compilation est définie lors de la construction. Faire quoi que ce soit a un certain type d'impact:)

Quant à savoir si ou non cela a un impact significatif sur une application. Il est très peu probable qu'il en trace est conçu pour être exécuté et est exécuté dans de nombreuses applications de production. Seul un abus de la fonction devrait conduire à une différence de performances de manière significative.

Mais comme toujours, ne me fais pas confiance, faites confiance au profileur.

Answer 2

Je n'ai pas les points de réputation pour les commentaires, mais je voulais faire une déclaration au sujet de la réponse rapide de Jonathan. Les chiffres que j'ai vus semblent montrer qu'il n'a pas de sens d'utiliser stringbuilder pour une poignée de concaténations de chaînes. Les frais généraux de création de l'objet stringbuilder l'emporte sur le gain de vitesse de concaténation.

Answer 3

La plupart des pertes de performance dans ce morceau de code n'est pas dans la trace, mais dans la concaténation de chaîne à l'aide de l'opérateur +. Cela fait quelques opérations de mémoire inefficaces qui peuvent battre une opération IO en termes de performance. Je changerai d'utiliser quelque chose comme String.Concat ou la classe StringBuilder (ou string.Format pour cette matière).

Answer 4

Messages de trace peuvent aller à beaucoup d'endroits différents. Vous pouvez ajouter (ou supprimer) TraceListeners pour la console, VisualStudio fenêtre de débogage, des fichiers ou le journal des événements pour ne citer que quelques-uns. Vous pouvez même créer votre propre.

Vous pouvez également configurer Trace pour ne pas faire quoi que ce soit lors de la compilation pour la libération.

Ainsi, l'impact sur les performances de l'utilisation de Trace peut varier énormément, tout le chemin de zéro à embourber complètement votre application, en fonction de ce que les auditeurs sont actifs. La plupart des auditeurs, cependant, ont de l'impact que vous attendez. Il faut environ tellement de travail à écrire dans un fichier ou base de données, ou la console, et Trace n'ajoute pas de frais généraux par rapport à ces activités d'E / O-liés.

Answer 5

Et si la trace est en train d'écrire dans un fichier texte, il coûtera plus cher que l'écriture à la console à mon humble avis

Answer 6

« Tracing ajoute une charge supplémentaire aux demandes et ne doit pas être activé pour les applications déployées. Trace.Write () déclarations, cependant, peuvent être laissés en car ils sont ignorés lors du traçage n'est pas activé. »

http://msdn.microsoft.com/en-us/library/ ms972204.aspx

Answer 7

Je suppose que Trace Source regarde TraceLevel de son commutateur avant de transmettre des messages aux auditeurs. Donc, si nous gardons la valeur TraceLevel par défaut de passer à « erreur », puis tracer les frais généraux serait grandement réduite que des traces « d'erreur » serait envoyé aux auditeurs.

juste une supposition ... Je ne l'ai pas mesuré encore rien. Mettra à jour si je le fais.

Mise à jour 2017 : semble être un dépréciée, mais tout à fait un moyen pratique d'information sur le dépistage / la connexion à un navigateur / à distance page .aspx accessible dans une application asp.net.

https://msdn.microsoft. com / fr-IN / bibliothèque / z48bew18 (v = vs.71) .aspx