Насколько быстро работает метод регистрации в log4net (Debug, Info и т. Д.)?
-
05-07-2019 - |
Вопрос
Я большой поклонник log4net , но недавно некоторые (в моем отделе) подвергли сомнению его включение в наши проекты из-за кажущейся тяжести каждого метода ведения журнала. Я бы сказал, что есть лучшие методы, чем другие, но это другой вопрос.
Мне любопытно узнать, каково типичное воздействие типа debugFormat log4net на ваши приложения. Я собираюсь пропустить такие переменные, как число операторов журнала на строки кода и т. Д., Потому что я просто ищу все, что вы видели в реальном мире.
И я знаю простой метод добавления защитного предложения в длинные операторы оценки, например:
if (log.IsDebug)
{
log.DebugFormat(...);
}
Итак, давайте пока исключим это из рассмотрения.
Решение
Я не знаком с 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 вполне может сделать нечто подобное, чего я не знаю.
Помимо этого, конечно, фактическая стоимость регистрации (на экран, в файл, в сокет и т. д.). Но это просто стоимость, которую вы должны принять. Моя лучшая практика для этого, когда это целесообразно, состоит в том, чтобы направлять фактические сообщения журнала в очередь, которая затем собирается и выводится на соответствующий канал, используя отдельный поток. Это, по крайней мере, помогает не входить в систему в соответствии с основными вычислениями, но имеет свои затраты и сложность.
Другие советы
Я знаю, что это старый поток, но как насчет использования подхода, который избегает заполнения кода операторами if, основанными на уровне журнала, таких как этот: http://www.beefycode.com/post/Extension- Методы-за отсроченный-Message-Форматирование-в-Log4Net.aspx
Используя лямбда-выражение для построения сообщения, вы можете избежать его полной оценки.
В часто задаваемых вопросах по log4net есть ответ на этот вопрос , хотя и не до уровня детализации, который вы ищете.
Вкратце: используйте эти пункты охраны.
Просто ответ Уиллу Хартунгу на перспективу .NET:)
Код DebugFormat:
if (IsDebugEnabled)
{
Logger.Log(ThisDeclaringType, m_levelDebug, new SystemStringFormat(CultureInfo.InvariantCulture, format, args), null);
}
По сути, это то же самое, поэтому я считаю, что когда вы используете DebugFormat, вам не нужно использовать выражение guard (у вас могут быть небольшие накладные расходы, но я думаю, что они достаточно малы, чтобы их игнорировать)
оставил бы комментарий, но у меня недостаточно репутации: /