Насколько быстро работает метод регистрации в 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-Methods-for-Deferred-Message-Formatting-in-Log4Net.aspx

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

Answer 3

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

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

Answer 4

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

Код DebugFormat:

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

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

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