Domanda

Ho trovato questo in un certo codice di produzione login stavo guardando da poco ...

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

... dove query è una query SQL breve per afferrare gli utenti corrispondenti. Questo ha alcun tipo di impatto sulle prestazioni? Presumo è molto piccola.

Inoltre, qual è lo scopo di questo tipo esatto di traccia, utilizzando il contesto HTTP? Da dove viene questo Get Data ricondotti a? Grazie in anticipo!

È stato utile?

Soluzione

Si avrà un impatto sulle prestazioni ogni volta che la costante di compilazione condizionale TRACE è definito durante la compilazione. Facendo tutto ciò ha un certo tipo di impatto:)

Per quanto riguarda se questo ha un impatto significativo sulla domanda. E 'altamente improbabile che sarebbe come Trace è progettato per essere eseguito ed è gestito in molte applicazioni di produzione. Solo un abuso della funzione dovrebbe portare ad una differenza di prestazioni notevole.

Ma, come sempre, non si fidano di me, la fiducia il profiler.

Altri suggerimenti

Non ho i punti reputazione per i commenti ancora, ma ho voluto fare una dichiarazione consultato circa la risposta di Jonathan. I numeri che ho visto sembrano dimostrare che essa non ha senso usare StringBuilder per appena una manciata di concatenazioni di stringhe. Il sovraccarico di creare dell'oggetto stringbuilder superiore ai benefici velocità concatenazione.

La perdita più prestazioni in questo pezzo di codice non è nella traccia, ma nella concatenazione di stringhe attraverso l'uso del l'operatore +. Questo fa alcune operazioni di memoria inefficienti che possono battere un'operazione IO in termini di prestazioni. Cambierei a usare qualcosa come String.Concat o la classe StringBuilder (o string.Format per questo).

messaggi di traccia possono andare in un sacco di posti diversi. È possibile aggiungere (o rimuovere) TraceListeners per la console, VisualStudio finestra di debug, file, o il registro eventi per citarne alcuni. È anche possibile costruire il proprio.

Inoltre, è possibile configurare Traccia di non fare nulla quando compilato per il rilascio.

In questo modo, l'impatto sulle prestazioni di utilizzare Trace può variare notevolmente, tutta la strada da zero a completamente impantanarsi vostra applicazione, a seconda di cosa gli ascoltatori sono attivi. La maggior parte degli ascoltatori, però, hanno circa l'impatto che ci si aspetta. Ci vogliono circa così tanto lavoro da scrivere in un file, o un database, o la console, e traccia non aggiunge molto rispetto in testa a quelli che le attività di I / O-bound.

E se traccia sta scrivendo un file di testo costerà di più che scrivere per consolare IMHO

"Tracing aggiunge un ulteriore sovraccarico di richieste e non deve essere attivato per le applicazioni distribuite. Trace.Write () dichiarazioni, tuttavia, possono essere lasciati in quanto vengono ignorati quando si traccia non è abilitata."

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

Credo Trace Fonte guarda TraceLevel del suo interruttore prima di inoltrare i messaggi per gli ascoltatori. Quindi, se manteniamo il valore predefinito TraceLevel del interruttore su "Error", quindi l'analisi ambientale sarebbe molto ridotto solo tracce "errore" sarebbe stata inviata agli ascoltatori.

solo una supposizione ... non ho ancora misurata nulla. Aggiornerà se lo faccio.

2017 Aggiornamento : sembra essere un deprecato, ma un modo molto utile di rintracciare / registrazione di informazioni su una pagina del browser / accessibile da remoto aspx in un'applicazione asp.net.

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top