Strategia logowania a wydajność

Question

Zajmuję się tworzeniem aplikacji internetowych, które muszą obsługiwać wiele równoczesnych żądań, i chciałbym, aby było wystarczająco szybkie. Mam teraz zaimplementować strategię logowania, użyję log4net, ale ... co i jak mam się zalogować? Mam na myśli:

1. Wpływ wyrębu na wydajność? czy jest to możliwe/zalecane logowanie przy użyciu połączeń asynchronicznych?
2. Czy lepiej użyć pliku tekstowego lub bazy danych? Czy można to zrobić warunkowo? na przykład domyślny dziennik do bazy danych, a jeśli się nie powiedzie, przejdź do pliku tekstowego.
3. Co z wielowątkowością? czy powinienem dbać o synchronizację podczas korzystania z log4net? czy jest bezpieczny w razie wykasowania z pudełka?

W wymaganiach pojawi się, że aplikacja powinna buforować kilka rzeczy na żądanie i obawiam się wpływu na wydajność.

Pozdrawiam.

Answer 1

1. Powoduje spowolnienie - robienie czegoś zabiera więcej czasu niż robienie niczego. Zwykle niewielką ilością. Nie przejmuj się tym.
2. Zaloguj się do pliku tekstowego imo. Są łatwe do przeniesienia/grep/compress/mail itd. I nie musisz się martwić logowaniem do bazy danych, że baza danych jest wyłączona. Istnieje jednak aplikacja do logowania do bazy danych dla log4net, jeśli tego potrzebujesz.
3. Yes, log4net jest bezpieczny w użyciu.

Posiadanie logów/śledzenia jest niezwykle cenne - w każdym razie powinieneś się zalogować błędów, albo nigdy się o nich nie dowiesz. Większość rejestrów pozwala na włączanie i wyłączanie poziomu szczegółowości wymaganego logowania.

Nie przejmuj się wydajnością, dopóki nie stanie się problemem. To nie jest tak, że budujesz rakiety księżycowe i chcesz zobaczyć, jak dużą wagę może wytrzymać, testując to - to tylko kod, usuń zapisy logowania, które zalewają twoje dzienniki i przekompiluj, jeśli kiedykolwiek stanie się problemem.

Answer 2

Powiedziałbym, że martwisz się o wydajność do samego początku, użyj log4net w sposób, który bardzo łatwo wyłączyć później lub dostosować (np. Użycie pliku conf, który definiuje poziom logu BRAK, BŁĄD, WARN , DEBUG, INFO, WSZYSTKO, VERBOSE itp.),

Jednak dwie pozostałe kwestie są ważne, dla pytania 2 wybrałbym zwykły plik, ponieważ można go łatwo odczytać i uzyskać dostęp do niego w przeciwieństwie do bazy danych. Również wydajność zapisu na końcu pliku jest lepsza niż db.

I tak jak nos stwierdził, że log4net jest bezpieczny dla wątków.

Jedna ogólna porada: Jeśli Twój projekt jest duży i chcesz mieć nadzieję na posiadanie konfigurowalnych poziomów logowania, jak opisałem powyżej, to naprawdę musisz uzgodnić standard kodowania w swoim zespole loguj na różnych poziomach.

Answer 3

Całkowicie zgadzam się z tym, co powiedzieli hhafez i nos. Kierujesz się właściwą ścieżką z pakietem logowania, zamiast próbować tworzyć własne. To jest o wiele czystsze i łatwiejsze do uzyskania. Logowanie do pliku tekstowego jest znacznie łatwiejsze w zarządzaniu długoterminowym (przy typowych zestawach umiejętności projektowych) niż rejestrowanie DB, ale jeśli planujesz jakąkolwiek złożoną analizę raportowanych danych, czasami łatwiej jest już mieć ją w DB.

Jeśli debugowanie jest jednym z wyznaczonych celów wdrożenia rozwiązania do rejestrowania, konieczne jest zestandaryzowanie wszystkich poziomów logowania z góry i uczynienie tego częścią procesu weryfikacji kodu. Wystarczająco dużo różnic w zakresie ziarnistości, aby stopniowo zwiększać głębokość raportowania, przechodząc do następnego poziomu. To bardzo frustrujące, gdy próbujesz rozwiązać problem z PROD, nie masz wystarczającej ilości informacji w dzienniku, aby zobaczyć problem, a następnie przejdź do następnego poziomu rejestrowania i całkowicie zapełnij dzienniki tak dużą ilością bańki, że nie możesz zobaczyć lasu dla drzew (i dzienniki są rzucane co 5 minut ze względu na objętość). Widziałem, jak to się stało.

W większości przypadków rejestrowania plików tekstowych wydajność nie powinna stanowić problemu. Trochę trudniej z logowaniem DB. Wykonanie wkładki jest tylko nieco bardziej intensywne niż dołączanie do pliku tekstowego, ale jest to wielkość jednostkowa, która sprawia, że ​​jest ona o wiele brzydsza w skali.

Ponadto, jeśli zamierzasz przeprowadzić dowolną analizę dziennika offline, powinieneś wybrać format pliku dziennika, który będzie łatwo rozszerzalny i nie będzie wymagał ogromnych zmian w kodzie analizy, jeśli musisz dodać coś do dziennika. Trzymaj się z dala od zagnieżdżonych, wieloczęściowych struktur wiadomości. Analizowanie tych zmian może być uciążliwe.

Życzymy powodzenia!