2013-02-27 9 views
6

Przy użyciu System.Diagnostics prześledzenie, czy istnieje znacząca (mierzalny) Wpływ na wydajność nie usuwając „domyślny” ślad słuchacza aplikacji ASP.NET produkcyjnej uwalnianiu trybie ze stałą TRACE zdefiniowane w czasie kompilacji, ale bez załączonego debuggera w czasie wykonywania?Wydajność DefaultTraceListener

Aby wyjaśnić, pytanie dotyczy dodatkowego wpływu "domyślnego" odbiornika śledzenia na aplikację korzystającą z innych detektorów śledzenia, a nie na temat alternatyw dla śledzenia System.Diagnostics.

Czy są jakieś miary wpływu domyślnego detektora śledzenia, gdy nie ma dołączonego debuggera? Czy są jakieś benchmarki już zrobione wpływu na produkcję pomijając element „usunąć” z kodem takich jak to:

<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> 

To pytanie jest różna od .NET Tracing: What is the “Default” listener? w tym sensie, że to drugie pytanie koncentrowała się na wpływ domyślnego detektora podczas działania w Visual Studio i aktualizowanie interfejsu debugowania, a to pytanie koncentruje się na kodzie wydania w środowisku produkcyjnym.

+0

Więc zmierzyłeś to na swojej konkretnej maszynie i systemie operacyjnym? Czego się dowiedziałeś? Nie próbowałaś tego spróbować? –

+0

Ponieważ powszechną praktyką jest zalecanie usunięcia tej linii, szukam osób, które pomogą mi znaleźć opublikowane pomiary, na których oparte jest zalecenie. Zakładam, że istnieje już opublikowany test porównawczy i moje własne myślenie niewiele wniósłoby do dyskusji. –

+0

Z tym pytaniem jest wiele problemów. Nie tylko poprosiłeś o to tak źle, że otrzymałeś kompletnie złą odpowiedź, nie podałeś też żadnego uzasadnienia, dlaczego nie chcesz przestrzegać zalecanej praktyki. A ty czekałeś 4 godziny na coś, co mógłbyś przetestować w ciągu 10 minut, uzyskując * niezawodny * wynik. Nikt nie powie ci, jak długo OutputDebugString przejmuje twój komputer. –

Odpowiedz

13

Może wystąpić znaczący wpływ na wydajność, jeśli śledzenie jest włączone przy użyciu domyślnego detektora śledzenia.

Jeśli chcesz śledzić wydajność gotową do produkcji, zdecydowanie zalecamy użycie klasy EventSource z .NET 4.5 zamiast metody śledzenia. Działa to z PerfView, tworząc źródło zdarzeń ETW i nie ma prawie żadnego wpływu na środowiska wykonawcze, nawet jeśli wyprowadzane są informacje śledzenia w procesie produkcyjnym.


Pozostawienie domyślnego detektora w miejscu powoduje, że framework rejestruje połączenia za pośrednictwem OutputDebugString. Może to być have a significant impact na wydajność, nawet w wersji wydania bez debuggera.

+1

Dziękuję za odpowiedź, ale moje pytanie było trochę niejasne i wprowadzało w błąd. Nie pytam o najskuteczniejszy sposób implementowania liczników wydajności. Interesuje mnie potencjalny wpływ nieusuwania "Domyślnego" detektora śledzenia w aplikacji, która używa innych słuchaczy z System.Diagnostic i nie ma załączonego debuggera w środowisku wykonawczym. Mogę stworzyć inne pytania dotyczące przydatności ETW w przypadku użycia, które mam na myśli. –

+0

@FernandoCorreia Edytowałem, aby pokazać, że - Mój pierwotny post nadal był poprawny: jest znaczący wpływ, ale teraz dodałem coś wyjaśniającego nieco więcej, dlaczego. –

+1

@FernandoCorreia Wspomniałem o ETW, ponieważ ma on prawie zerowy wpływ, nawet jeśli włączono rejestrowanie, dlatego struktura sama używa go w całości i pozostawia diagnostykę w miejscu produkcji. –

0

Sam parametr DefaultTraceListener jest "dość szybki" - podobnie jak w normalnych warunkach, nie jest zwykle zauważalny w przypadku wszystkich, ale najbardziej niewybaczalnych zastosowań. Jednak w połączeniu z Trace.UseGlobalLock może to mieć znaczący wpływ na mocno obciążony system.

Dzisiaj nasze systemy były przeżywa nadmierne obciążenie procesora i kontekst przełączania (który jest inny problem) .. i stało się coś nieoczekiwanego, który potęgowany problemu do momentu, w którym praca skutecznie powstrzymywał:

kod Mocno gwintowany rozpoczęła blokowanie w górę z 12 sekund (!!) na linii Trace.WriteLine, ponieważ musiał nabyć blokadę "trywialnej" pracy w DefaultTraceListener.

Podczas gdy blokada UseGlobalLock jest stosowana, nawet jeśli nie ma detektora śledzenia, jest to skutecznie blokada bez niczego w środku - w porównaniu z zamkiem z odrobiną czegoś wewnątrz, które może kulić się na już załadowanym systemie z wieloma wątkami.

Do natychmiastowych poprawek należy wyłączenie UseGlobalLock (ma to other side-effects [disclaimer: inny post]] i usunięcie DefaultTraceListener.

Oczywiście, jeśli inny odbiornik śledzenia zostanie podłączony, może on dobrze śledzić cały czas spędzany w obiekcie DefaultTraceListener.