Насколько быстро работает метод регистрации в log4net (Debug, Info и т. Д.)?

Question

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

Мне любопытно узнать, каково типичное воздействие типа debugFormat log4net на ваши приложения. Я собираюсь пропустить такие переменные, как число операторов журнала на строки кода и т. Д., Потому что я просто ищу все, что вы видели в реальном мире.

И я знаю простой метод добавления защитного предложения в длинные операторы оценки, например:

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

Итак, давайте пока исключим это из рассмотрения.

Answer 1

Я не знаком с log4net или log.DebugFormat (...).

Но стоимость регистрации действительно в двух областях.

Первый - это вызов журнала, а второй - фактическое сохранение информации журнала.

Охранники помогают свести вызов регистрации к минимуму, когда регистрация на самом деле не нужна. Это имеет тенденцию быть очень быстрым, так как это немного больше чем вызов метода и сравнение двух скаляров.

Однако, когда вы не используете охранники, стоимость может стать ценой создания фактических аргументов регистрации.

Например, в log4j это была распространенная идиома:

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

Здесь стоимость - это фактическая оценка строкового выражения, составляющего сообщение. Это связано с тем, что независимо от уровня ведения журнала создаются это выражение и полученная строка. Представьте, если бы вместо этого у вас было что-то вроде:

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

Это может создать большую и дорогую строковую переменную, которая, если бы уровень журнала не был установлен для DEBUG, была бы просто потрачена впустую.

Охранники:

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

Устраните эту проблему, поскольку вызов isDebug обходится дешево, особенно по сравнению с фактическим созданием аргумента.

В своем коде я написал оболочку для ведения журналов и могу создавать журналы следующим образом:

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

Это хороший компромисс. Это зависит от Java varargs, и мой код проверяет уровень ведения журнала, а затем форматирует сообщение соответствующим образом. Это почти так же быстро, как охранники, но гораздо чище писать.

Теперь log.DebugFormat вполне может сделать нечто подобное, чего я не знаю.

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

Answer 2

Я знаю, что это старый поток, но как насчет использования подхода, который избегает заполнения кода операторами if, основанными на уровне журнала, таких как этот: http://www.beefycode.com/post/Extension- Методы-за отсроченный-Message-Форматирование-в-Log4Net.aspx

Используя лямбда-выражение для построения сообщения, вы можете избежать его полной оценки.

Answer 3

В часто задаваемых вопросах по log4net есть ответ на этот вопрос , хотя и не до уровня детализации, который вы ищете.

Вкратце: используйте эти пункты охраны.

Answer 4

Просто ответ Уиллу Хартунгу на перспективу .NET:)

Код DebugFormat:

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

По сути, это то же самое, поэтому я считаю, что когда вы используете DebugFormat, вам не нужно использовать выражение guard (у вас могут быть небольшие накладные расходы, но я думаю, что они достаточно малы, чтобы их игнорировать)

оставил бы комментарий, но у меня недостаточно репутации: /