Влияние регистрации на производительность Apache

Question

Я занимаюсь разработкой модуля Apache. Во время разработки мне было удобно использовать функции ведения журналов в разных местах моего кода. Например, после открытия файла я регистрирую ошибку, если операция не была успешной, чтобы я мог точно знать, где возникла проблема в моем коде.

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

Answer 1

Это действительно зависит от того, как вы написали эти инструкции.Если вы написали:

logger.debug(computeSomeCostlyDebugOutput());

Вы можете сильно повлиять на производительность, если регистратор не настроен на уровень отладки (computeSomeCostlyDebugOutput всегда будет занимать время, и его результат будет игнорироваться регистратором, если нет.соответствует уровню DEBUG).

Если вы напишите вместо этого:

if (logger.isDebugEnabled()) {
  logger.debug(computeSomeCostlyDebugOutput());
}

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

Как очень хорошо заметил Анджей Дойл, регистратор проверит свой уровень внутри, но это происходит в методе debug, после того как время было уже потрачено на computeSomeCostlyDebugOutput.Если вы тратите время на computeSomeCostlyDebugOutput, вам лучше это делать, когда вы знаете, что его результат не будет напрасным.

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

Answer 2

Одной из целей разработки Log4J (по уважительной причине) была производительность;Ceki Gulku хотел, чтобы библиотека была пригодна для использования в производственном, корпоративном программном обеспечении, а издержки самого Log4J на самом деле довольно минимальны (измерено в моем собственном проекте веб-приложения с помощью профилировщика).однако:

1. Формирование аргументов для передача в метод ведения журнала для некоторых вызовов.Как говорит dpb, этого следует избегать, оборачивая любые вычисления сложных выходных данных в проверку журналирования, чтобы вы не получали сложные выходные данные отладки, когда регистратор собирается их выбросить, поскольку он настроен только на запись ошибок.
2. Чистый ввод / вывод, необходимый для записи данных журнала.Если ваше приложение регистрирует 200 МБ отладочных журналов в секунду (это может показаться неосуществимым, но это случалось со мной раньше), то это, скорее всего, повлияет на скорость его выполнения, поскольку IIRC запись файлов происходит синхронно.В различных проектах типа веб-приложений, которые я разработал, я обычно могу заметить небольшую разницу в скорости отклика, когда я устанавливаю журналы на уровень отладки (и IMO это хорошо, так как вы должны генерироватьмного выводится при запросе журналов отладки).