При переходе с JUL на log4j2 производительность не такая, как ожидалось. Что пошло не так? - PullRequest
Новая
       6

При переходе с JUL на log4j2 производительность не такая, как ожидалось. Что пошло не так?

0 голосов
/ 07 мая 2020

Я новый пользователь log4j2. На основе введения Log4j2 * тестов производительности , и может потребоваться создание большого количества файлов csv для обработки данных. Я планирую перенести проект с JUL на log4j2. Это многопоточный проект, в котором используется множество логгеров. Но результаты тестов не вызывают нареканий. Где я ошибся? результаты сравнения

Конфигурация зависимости выглядит следующим образом: 

<!-- Log4j2 api -->
    <dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
    <version>2.11.1</version>
    </dependency>
    <!-- Log4j2 impl.-->
    <dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.11.1</version>
    </dependency>
    <!-- for Log4j2 asynchronous logging-->
    <dependency>
        <groupId>com.lmax</groupId>
        <artifactId>disruptor</artifactId>
        <version>3.4.2</version>
    </dependency> 
    <!-- for Log4j2 csvlayout-->
    <dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-csv</artifactId>
    <version>1.5</version>
    </dependency>

Файл «log4j2. xml» имеет несколько похожих приложений и регистраторов, например: частичная конфигурация для log4j2. xml

Java соответствующий код выглядит следующим образом: 

    System.setProperty("log4j2.isThreadContextMapInheritable", "true");
    String renameCsvFile = new String( inputDir.getName() + StaticUtils.SEPARATOR +"log"+ StaticUtils.SEPARATOR + "rename");
    ThreadContext.put("module3", renameCsvFile);
    rename_logger = LogManager.getLogger("myrenamelog");

    rename_logger.info("rename logging", "Timestamp","Level",  "OrignalPath","RenamedPath","Status", "Message", "Layer#", "Thread#");

    rename_logger.info("rename logging...", Instant.now(),"info",file.getAbsolutePath(),newName.getAbsolutePath(),"success"," ","Layer#",Thread.currentThread().getName());

1 Ответ

0 голосов
/ 08 мая 2020

Я бы посоветовал вам перейти на последнюю версию. В частности, LOG4J2-2644 , который был рассмотрен в Log4j 2.12.1, должен повлиять на некоторое время вашей производительности. Однако, как и в LOG4J2-2792 , некоторым приложениям, которые сильно зависят от фильтров, может потребоваться отключить быстрое получение местоположения.

Если после тестирования с более новой версией у вас все еще есть проблемы, пожалуйста, создайте проблему Jira с Log4j. В идеале вы должны предоставить либо образец набора тестов, чтобы продемонстрировать проблему, и / или моментальный снимок, созданный с помощью инструмента профилирования, такого как YourKit, который может помочь определить проблемные области.

...