Как оценить производительность логгера?

Question

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

Теперь я хочу оценить производительность двух регистраторов, то есть, какой из них быстрее, учитывая ту же информацию для регистрации. Есть ли у вас какие-либо идеи о том, как это сделать? PS Я думал, что мне понадобится поток для подсчета строк файлов, но я не уверен, как. Любая помощь с благодарностью.

Answer 1

Log4J является текущим стандартом не только в разработке с открытым исходным кодом. Он претендует на то, чтобы быть быстрым и гибким: сначала скорость, а потом гибкость. Но есть некоторые подводные камни, когда дело доходит до кризиса.

Стоимость запроса журнала состоит из вызова метода и целочисленного сравнения. Обычно это около 1-20 нс (в зависимости от вашего процессора) за звонок. Однако это не включает «скрытые» затраты на создание параметров.

Простой пример:

logger.debug("Value: " + x*y);

Независимо от того, будет ли сообщение действительно зарегистрировано или нет, создание параметра вызовет дополнительные затраты. Эти затраты на создание параметров могут быть довольно высокими и зависеть от размера используемых параметров.

Чтобы избежать затрат на строительство параметра:

if(logger.isDebugEnabled() {
  logger.debug("Value: " + x*y);
}

Это не приведет к затратам на создание параметров, если отладка отключена. С другой стороны, если в логгере включена отладка, он будет в два раза дороже оценивать, включен ли регистратор: один раз в debugEnabled и один раз в отладке. Это незначительные накладные расходы, потому что оценка регистратора занимает около 1% времени, необходимого для фактического ведения журнала.

Так что, если скорость является реальной проблемой, вы должны дважды проверить свои записи в журнале на предмет «скрытых» затрат.

Ресурсы: http://logging.apache.org/log4j/1.2/manual.html

Answer 2

Единственные вопросы, которые действительно имеют значение:

• На какие устройства вы подключаетесь?(Наиболее важно)

• Ведется ли запись в текущем или фоновом потоке?

• Является ли шаблон формата одинаковым?

• Сообщение, которое не зарегистрировано, не создано.например, он не создает сообщения, которые он не будет печатать.

• Используете ли вы Strings для создания сообщений или создания текста более низкого уровня?(имеет значение, только если остальные оптимальны)

Если вы печатаете одинаковое количество строк в каждом случае, счет менее важен, чем общее время, потраченное.

---

Вот простой тест

Logger log = Logger.getAnonymousLogger();
int runs = 100 * 1000;
long start = System.nanoTime();
for(int i=0;i< runs;i++)
    log.info("Hello World! "+i);
long time = System.nanoTime() - start;
System.out.printf("Average log time was %,d ns%n", time/runs);

На печать IDE GUI

Average log time was 109,270 ns

На печать окна DOS

Average log time was 354,015 ns

Запись только в файл

Handler handler = new FileHandler("test.log", 1024 * 1024, 10);

Logger log = Logger.getAnonymousLogger();
log.setUseParentHandlers(false);
log.addHandler(handler);

отпечатки

Average log time was 29,688 ns

Без устройств

Average log time was 1,002 ns

Это типично для всех регистраторов, устройство является наиболее важным фактором.

Answer 3

Мне пришлось решать эту проблему на работе;Я написал реализацию SLF4J и тестировал ее на Log4J.Я создал жгут, который прокачал бы фиксированное количество сообщений (n) через регистратор на фиксированном количестве потоков (t).Я проверил измеренное время выполнения различных комбинаций (n, t) в нескольких испытаниях и исследовал медианные, средние и p90 значения совокупных результатов.Я также поменял реализацию SLF4J в нашем приложении между Log4J и моей реализацией и провел приложение через уже существующие тесты производительности, чтобы увидеть влияние нашего приложения.

Мой совет:

1. Тренируйте каждый регистратор в тестовом жгуте, имитирующем ваше приложение.
2. Если возможно, используйте каждый регистратор в вашем приложении под смоделированной нагрузкой (т. Е. С использованием воспроизведения или сгенерированных данных).