Является ли регистрация с использованием FileHandler узким местом?

Question

Я рассматриваю возможность регистрации бизнес-событий в веб-приложении J2EE с использованием ведения журнала Java и FileHandler.

Мне интересно, может ли это привести к узким местам производительности, так как многие записи журнала будут записаны в один файл.

Каковы ваши переживания и мнения?

Может ли регистрация загруженного веб-приложения в одном файле с ведением журнала Java и FileHandler стать узким местом для производительности?

Answer 1

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

Используйте ведение журнала для важных случаев, установите правильный уровень ведения журнала для текущих целей (тестирование или фактическое развертывание) и используйте такие конструкции, как

if (Logger.isDebugEnabled()) {
   Logger.debug("Value is " + costlyOperation()")
}

чтобы избежать вызова кода, который стоит дорого запустить.

Вы также можете проверить эту статью

Answer 2

Чтобы избежать таких общих понятий, как "это зависит" или "немного" и т. Д., Вы должны измерять производительность вашего приложения с учетом и без дополнительных затрат на ведение журнала. Apache JMeter может помочь вам сгенерировать нагрузку для теста.

Информация, которую вы можете собрать с помощью регистрации, обычно настолько важна для целостности приложения, что вы не можете работать вслепую. Кроме того, если вы используете Google Analytics, есть небольшие накладные расходы, но преимущества преобладают.

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

Answer 3

Я думаю, что у блога JavaRevisited есть довольно хороший пост о проблеме с производительностью: Топ 10 советов по входу в систему на Java

Answer 4

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

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

Answer 5

Вам следует:

1. Определите соответствующий показатель производительности (например, скорость реагирования, пропускную способность и т. Д.). Затем вы должны измерить эту метрику, отключив и включив ведение журнала. Разница будет в стоимости регистрации.

2. Затем вы должны поэкспериментировать с различными библиотеками журналирования и режимами, которые они предоставляют, и задокументировать наблюдаемые различия.

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

Следующее не имеет прямого отношения к вашему вопросу.

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

Надеюсь это поможет,