Prestazioni di DefaultTraceListener

Quando si utilizza System.Diagnostics tracciamento, v'è una significativa (misurabile) impatto sulle prestazioni non rimuovere la traccia ascoltatore "default" a un produzione applicazione ASP.NET in rilascio modo, con la costante TRACE definita al momento della compilazione ma senza debugger allegato in fase di runtime?Prestazioni di DefaultTraceListener

Per chiarire, la domanda riguarda l'impatto aggiuntivo del listener di traccia "Default" su un'applicazione che utilizza altri listener di traccia, non su alternative alla traccia System.Diagnostics.

Esistono misure dell'impatto del listener di traccia predefinito quando non è collegato alcun debugger? Ci sono dei punti di riferimento già fatto l'impatto nella produzione di tralasciando l'elemento "rimozione" da un codice come questo:

<configuration> 
<system.diagnostics> 
    <trace autoflush="false" indentsize="4"> 
    <listeners> 
     <remove name="Default" /> 
     <add name="myListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="c:\myListener.log" /> 
    </listeners> 
    </trace> 
</system.diagnostics> 
</configuration>

Questa questione è diverso da .NET Tracing: What is the “Default” listener?, nel senso che l'altra domanda è stata incentrata sulla impatto del listener predefinito durante l'esecuzione in Visual Studio e l'aggiornamento di un'interfaccia utente di debug e questa domanda è incentrata sul codice di rilascio in un ambiente di produzione.

fonte

2013-02-27 Fernando Correia

Quindi l'hai misurato sulla tua particolare macchina e sistema operativo? Cosa hai trovato? Non ti sei preso la briga di provarlo? –

Poiché la pratica comune è raccomandare di rimuovere quella linea, sto cercando persone che mi aiutino a trovare le misurazioni pubblicate su cui si basa la raccomandazione. Presumo che ci sia già un punto di riferimento pubblicato e la mia invenzione aggiungerebbe poco alla discussione. –

Ci sono molte cose sbagliate in questa domanda. Non solo l'hai chiesto così male che hai ottenuto la risposta completamente sbagliata, ma non hai dato alcuna giustificazione per cui avresti considerato di non seguire una pratica raccomandata. E hai aspettato 4 ore per qualcosa che avresti potuto testare da te in 10 minuti, ottenendo un risultato * affidabile *. Nessuno ti dirà quanto tempo impiega OutputDebugString sul tuo computer. –

Ci può essere un impatto significativo sulle prestazioni se la traccia viene lasciata su utilizzando il listener di tracce predefinito.

Se si desidera una traccia di prestazione pronta per la produzione, si consiglia vivamente di utilizzare la classe EventSource da .NET 4.5 anziché il metodo di traccia. Funziona con PerfView creando una sorgente di eventi ETW e non ha praticamente alcun impatto sui tempi di esecuzione, anche quando si generano informazioni di traccia in produzione.

Lasciando l'ascoltatore di default al posto fa sì che il quadro per registrare le chiamate tramite OutputDebugString. Questo può have a significant impact sulle prestazioni, anche in una versione di rilascio senza un debugger.

fonte

2013-02-27 18:46:05

Grazie per la risposta, ma la mia domanda è stata alquanto vaga e fuorviata. Non sto chiedendo il modo più efficiente per implementare i contatori delle prestazioni. Sono interessato al potenziale impatto della mancata rimozione del listener di traccia "Default" in un'applicazione che utilizza altri listener con System.Diagnostic e non ha alcun debugger collegato in fase di runtime. Potrei creare altre domande sull'idoneità di ETW per il caso d'uso che ho in mente. –

@FernandoCorreia Ho modificato per mostrare che - Il mio post originale era ancora corretto: c'è un impatto significativo, ma ora ho aggiunto qualcosa spiegando un po 'di più sul perché. –

@FernandoCorreia Ho menzionato ETW perché questo ha un impatto quasi pari a 0, anche quando abiliti la registrazione, motivo per cui il framework stesso lo utilizza in tutto e lascia la diagnostica in atto nella produzione. –

Il DefaultTraceListener stesso è "abbastanza veloce" - come in, normalmente non è visibile con tutti tranne l'uso più sfrenato. Tuttavia, in combinazione con lo Trace.UseGlobalLock, può avere un impatto significativo su un sistema molto carico.

Oggi i nostri sistemi sono stati sperimentando carico eccessivo della CPU e il contesto di commutazione (che è un altro problema) .. e qualcosa di inaspettato successo che aggravato il problema al punto in cui lavoro in modo efficace fermato:

codice fortemente filettato iniziato blocco per verso l'alto di 12 secondi (!!) su Trace.WriteLine in quanto ha dovuto acquisire il blocco sul lavoro "banale" in DefaultTraceListener.

Mentre l'UseGlobalLock viene applicata anche se non v'è alcun listener di analisi è effettivamente una serratura con niente dentro - contro una serratura con un po po 'di qualcosa dentro che può palla di neve su un sistema già caricato con molti fili.

Le correzioni immediate sono di disabilitare UseGlobalLock (questo ha other side-effects [disclaimer: un altro post del mio]) e rimuovere DefaultTraceListener.

Ovviamente, se un altro listener di traccia è cablato, potrebbe benissimo oscurare tutto il tempo trascorso in DefaultTraceListener.

fonte

2016-12-13 07:16:09 user2864740

Prestazioni di DefaultTraceListener

risposta

Problemi correlati