Jak szybko jest metoda rejestrowania log4net (debugowanie, informacje itp.)?

Question

Jestem wielkim fanem log4net, ale ostatnio niektórzy (w moim dziale) zakwestionowali włączenie do naszych projektów ze względu na pozorną ciężkość każdej metody rejestrowania. Twierdzę, że istnieją lepsze techniki niż inne, ale to kolejne pytanie.

Jestem ciekawy, jaki jest typowy wpływ wywołania debugFormat typu log4net na Twoje aplikacje. Zamierzam pominąć zmienne, takie jak liczba logów w liniach kodu, itp., Ponieważ szukam tylko tego, co widziałeś w realnym świecie.

I zdaję sobie sprawę z prostej techniki dodając klauzulę ochronną do długich wypowiedzi oceniających np:

if (log.IsDebug) 
{ 
    log.DebugFormat(...); 
} 

Tak, niech wykluczyć, że z uwagi na teraz.

Answer 1

Nie jestem zaznajomiony z log4net lub log.DebugFormat (...).

Ale koszt logowania jest naprawdę w dwóch obszarach.

Pierwsza z nich to połączenie rejestrowania, a druga to faktyczne utrwalanie informacji dziennika.

Osłony pomagają ograniczyć rejestrowanie do minimum, gdy rejestrowanie nie jest konieczne. Zwykle jest bardzo szybki, ponieważ jest niewiele więcej niż wywołaniem metody i porównaniem dwóch skalarów.

Jeśli jednak nie używasz osłon, koszt może stać się ceną tworzenia rzeczywistych argumentów dotyczących rejestrowania.

Na przykład w log4j, to był wspólny idiom:

log.debug("Runtime error. Order #" + order.getOrderNo() + " is not posted."); 

Tutaj koszt jest rzeczywista ocena ekspresji łańcucha składającego wiadomość. Dzieje się tak, ponieważ niezależnie od poziomu rejestrowania tworzone jest wyrażenie i wynikowy ciąg. Wyobraź sobie, że zamiast tego trzeba było coś takiego:

log.debug("Something wrong with this list: " + longListOfData); 

To może stworzyć dużą i kosztowną zmienną string, że jeżeli poziom dziennika nie został ustalony dla debugowania, po prostu zmarnowane.

Strażnicy:

if (log.isDebug()) { 
    log.debug(...); 
} 

wyeliminowanie tego problemu, ponieważ wezwanie isDebug jest tani, zwłaszcza w porównaniu do rzeczywistego stworzenia argumentu.

W moim kodu, mam napisane otoki dla rejestrowania i mogę tworzyć logi tak:

log.debug("Runtime error. Order # {0} is not posted.", order.getOrderNo()); 

Jest to ładne kompromis. Opiera się to na Javie varargs, a mój kod sprawdza poziom rejestrowania, a następnie odpowiednio formatuje komunikat. To prawie tak szybko, jak strażnicy, ale o wiele czystsze do napisania.

Teraz dziennik.DebugFormat może zrobić coś podobnego, czego nie wiem.

Oprócz tego, oczywiście, jest faktyczny koszt logowania (do ekranu, do pliku, do gniazda itp.). Ale to tylko koszt, który musisz zaakceptować. Moją najlepszą praktyką w tym przypadku, gdy jest to praktyczne, jest kierowanie rzeczywistych komunikatów dziennika do kolejki, która jest następnie zbierana i wysyłana do właściwego kanału przy użyciu osobnego wątku. Pomaga to przynajmniej w utrzymywaniu logarytmu z dala od głównego komputera, ale ma własne koszty i złożoność.

Answer 2

The log4net FAQ has an answer to this, ale nie do poziomu detalu, którego szukasz.

Podsumowując: użyj tych klauzul strażniczych.

Answer 3

tylko dawać odpowiedź będzie Hartung za perspektywę .NET :)

kod DebugFormat jest:

if (IsDebugEnabled) 
{ 
    Logger.Log(ThisDeclaringType, m_levelDebug, new SystemStringFormat(CultureInfo.InvariantCulture, format, args), null); 
} 

Zasadniczo to samo więc to moja wierzyć, że podczas korzystania DebugFormat ciebie nie trzeba skorzystać z klauzuli ochronnej (może nadal mieć mały narzut, ale myślę, że jest wystarczająco małe, aby być ignorowane)

byłby skomentowało ale nie mam wystarczająco dużo reputacji:/

Answer 4

Wiem, że to stary wątek, ale jak o użyciu metody, która unika wypełniania kod z if na podstawie poziomu dziennika, takich jak ten: http://www.beefycode.com/post/Extension-Methods-for-Deferred-Message-Formatting-in-Log4Net.aspx

Używanie wyrażenia lambda do tworzenia wiadomości, można unikaj nawet całkowitej jego oceny.