Является ли регистрация с использованием FileHandler узким местом? - PullRequest
4 голосов
/ 17 мая 2011

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

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

Каково ваше мнение и опыт?

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

Ответы [ 5 ]

4 голосов
/ 17 мая 2011

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

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

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

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

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

3 голосов
/ 17 мая 2011

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

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

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

1 голос
/ 23 мая 2011

Вы должны:

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

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

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

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

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

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

1 голос
/ 17 мая 2011

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

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

1 голос
/ 17 мая 2011

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

...