Welchen Leistungseinfluss hat die Ablaufverfolgung in C# und ASP.NET?

Question

Ich fand dies in einigen Login-Code Produktion ich vor kurzem war auf der Suche ...

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

... wo Abfrage eine kurze SQL-Abfrage ist passend zu den Benutzern zu greifen. Hat das irgendwelche Auswirkungen auf die Leistung? Ich nehme an, es ist sehr klein.

Auch was ist der Zweck dieser genauen Art von Ablaufverfolgung, die den HTTP-Kontext verwendet? Wohin werden diese Daten zurückverfolgt? Danke im Voraus!

Answer 1

Ja, es hat Auswirkungen auf die Leistung, wenn die bedingte Kompilierungskonstante von TRACE während des Builds definiert wird. Etwas zu tun hat irgendeine Art von Auswirkung :)

Ob dies eine signifikante Auswirkung auf eine Anwendung hat oder nicht. Es ist sehr unwahrscheinlich, dass Trace so ausgeführt wird und in vielen Produktionsanwendungen läuft. Nur ein Missbrauch des Features sollte zu einem bemerkenswerten Leistungsunterschied führen.

Aber wie immer, traue mir nicht, vertraue dem Profiler.

Answer 2

Trace-Nachrichten können an viele verschiedene Orte gehen. Sie können TraceListeners für die Konsole, das VisualStudio-Debug-Fenster, Dateien oder das Ereignisprotokoll hinzufügen (oder entfernen), um nur einige zu nennen. Sie können sogar Ihre eigenen bauen.

Sie können Trace auch so konfigurieren, dass bei der Kompilierung für Release keine Aktionen ausgeführt werden.

Der Leistungseinfluss bei der Verwendung von Trace kann also sehr unterschiedlich sein, von null bis hin zur völligen Ausnutzung der App, je nachdem, welche Listener aktiv sind. Die meisten Zuhörer haben jedoch die Auswirkungen, die Sie erwarten würden. Es erfordert so viel Arbeit, in eine Datei, eine Datenbank oder die Konsole zu schreiben, und Trace fügt nicht so viel Overhead hinzu wie diese E/A-gebundenen Aktivitäten.

Answer 3

Der meiste Leistungsverlust in diesem Codeabschnitt befindet sich nicht in der Ablaufverfolgung, aber in der Zeichenfolge-Verkettung durch die Verwendung des Operator +. Dies führt zu einigen ineffizienten Speicheroperationen, die eine IO-Operation in Bezug auf die Leistung übertreffen können. Ich würde es ändern, um etwas wie string.Concat oder die StringBuilder-Klasse (oder string.Format für diese Angelegenheit) zu verwenden.

Answer 4

Und wenn Trace wird in eine Textdatei zu schreiben es wird mehr kosten als das Schreiben IMHO

Answer 5

ich noch die Rating-Punkte für Kommentare haben nicht zu trösten, aber ich wollte eine schnelle Aussage über Jonathan Antwort machen. Die Zahlen, die ich gesehen habe, scheinen zu zeigen, dass es keinen Sinn macht, Stringbuilder für eine Handvoll String-Verkettungen zu verwenden. Der Aufwand beim Erstellen des Stringbuilder-Objekts überwiegt den Vorteil der Verkettungsgeschwindigkeit.

Answer 6

Ich denke, Trace Source schaut auf den TraceLevel seines Switches, bevor Nachrichten an die Listener weitergeleitet werden. Wenn wir also den Standard-TraceLevel-Wert des Schalters auf "Error" setzen, würde der Verfolgungs-Overhead stark reduziert, da nur "Fehler" -Spuren an Listener gesendet würden.

nur eine Vermutung ... ich habe noch nichts gemessen. Wird aktualisiert, wenn ich es tue.

2017 Update: scheint eine veraltete, aber eine sehr praktische Möglichkeit zum Verfolgen/Protokollieren von Informationen zu einem Browser/remote zugänglichen ASPX-Seite in einer asp.net-Anwendung.

https://msdn.microsoft.com/en-IN/library/z48bew18(v=vs.71).aspx

Answer 7

„Tracing fügt zusätzlichen Aufwand auf Anfragen und sollte nicht für bereitgestellte Anwendungen aktiviert werden. Trace.Write() Aussagen können jedoch links in werden, weil sie ignoriert werden, wenn Tracing nicht aktiviert ist.“

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