Log4net намного медленнее, чем System.Diagnostics.Trace?

Question

Я исследую различия между использованием log4net и System.Diagnostics.Trace для ведения журнала, и мне интересно узнать о различиях в производительности, которые я заметил.

Я создал тестовое приложение, чтобы сравнить производительность обоих методов ведения журналов в нескольких сценариях, и обнаружил, что log4net работает значительно медленнее, чем Trace сорт.Например, в сценарии, где я регистрирую 1000 сообщений без форматирования строк, среднее время выполнения log4net для 1000 попыток составляет 9,00 мс. Trace выполняется со средним значением 1,13 мс.Многие из моих тестовых примеров имеют относительно большую разницу во времени выполнения log4net;периодический характер слишком длительных выполнения, по-видимому, предполагает вмешательство GC.Поиск в CLR Profiler подтверждает, что существует большое количество коллекций для тонны log4net.Core.LoggingEvent генерируемые объекты (честно говоря, это выглядит как Trace генерирует тонну Char[] объекты, но он не отображает такую ​​большую дисперсию, как log4net.)

Я имею в виду одну вещь: хотя log4net кажется примерно в 9 раз медленнее, чем Trace, разница составляет 8 мс за 1000 итераций;это не совсем существенное снижение производительности.Тем не менее, некоторые из моих ожидаемых вариантов использования могут заключаться в вызове методов, которые регистрируют события сотни тысяч раз, и эти цифры получены с моей быстрой машины.На более медленной машине, более типичной для конфигураций наших пользователей, разница составляет от 170 до 11 мс, что немного более тревожно.

Является ли такая производительность типичной для log4net или есть какие-то ошибки, которые могут значительно повысить производительность log4net?

(ПРИМЕЧАНИЕ:Я знаю, что форматирование строк может изменить время выполнения;Я пытаюсь сравнить яблоки с яблоками, и у меня есть тестовые примеры без форматирования и тестовые примеры с форматированием;log4net остается пропорционально медленным независимо от того, используется форматирование строк или нет.)

История до сих пор:

• У Роберта Гулда есть лучший ответ на этот вопрос;В основном мне было любопытно, было ли типично видеть, что log4net работает намного медленнее, чем Trace сорт.
• Ответ Алекса Шнайдера представляет собой интересную информацию, но на самом деле не входит в рамки вопроса.Цель введения такого ведения журнала наполовину состоит в том, чтобы помочь в отладке как логических проблем, так и проблем с производительностью в работающих системах;наши клиенты используют наши продукты во многих экзотических сценариях, которые часто трудно воспроизвести без дорогостоящих и масштабных аппаратных конфигураций.Меня больше всего беспокоит то, что большая разница во времени между «не ведением журнала» и «ведением журнала» может повлиять на систему таким образом, что ошибок не произойдет.В конце концов, масштаб снижения производительности велик, но величина невелика, поэтому я надеюсь, что это не станет проблемой.

Answer 1

да, log4xxx медленнее, чем трассировка, поскольку трассировка обычно является инструментом, близким к ядру, а log4xxx — гораздо более мощным инструментом.Лично я предпочитаю log4xxx из-за его гибкости, но если вам нужно что-то, что не оказывает такого большого влияния, и вам действительно не нужны журналы для производства, скажем, при отладке должно быть достаточно только трассировки.

Примечание:Я использую log4xxx, потому что то же самое относится ко всем языкам с библиотекой log4, а не только к .Net.

Answer 2

вас может заинтересовать Библиотека Common.Logging.Это тонкая абстрактная оболочка над существующими реализациями ведения журналов, которая позволяет вам подключать любую платформу ведения журналов, которая вам нравится, во время выполнения.Кроме того, это намного быстрее, чем System.Diagnostics.Trace, как описано в моем запись в блоге о производительности.

HTH, Эрих

Answer 3

По моему опыту, производительность log4net в большинстве случаев не является проблемой.Реальный вопрос в том, зачем вам вообще нужно «записывать события сотни тысяч раз» в производственной системе.
Насколько я понимаю, в производстве вы должны регистрировать только минимум (информация и может быть уровнем предупреждения), и только в случае необходимости (отладка проблемы на месте) следует активировать отладку на уровне отладки.

Answer 4

Если вы хотите получить лучшее из обоих миров, log4net позволит вам также войти в трассировщик aspnet.Я включаю эту опцию, когда хочу получить статистику производительности, привязанную к конкретным событиям в моем журнале.

Answer 5

Только что запустил тест, сравнивающий последовательную запись в простой файл по сравнению с использованием Log4Net для той же задачи. Log4Net примерно в 400 раз медленнее по сравнению с StreamWriter. Итак Я считаю, что Log4Net непригоден для использования, если вы пишете в огромные файлы журналов..Но я нахожу это очень полезно для небольшого количества записей журнала и отладка.

Возможно, в некоторых случаях есть решение изолировать ведение журнала в отдельном потоке.