[ 
https://issues.apache.org/jira/browse/LOG4J2-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812779#comment-13812779
 ] 

Giri Kosuru commented on LOG4J2-437:
------------------------------------

Hi Remco,

    Sorry for getting back late. Got little busy with our release schedules and 
tests. Followed your recommendations and saw good gains in performance numbers 
(Up to 20 % gain in performance, particularly TPS). Here is what I did as per 
your suggestion.

1) Started using Asynchronous Loggers.The following are the system properties 
used. RingBufferSize of 20480 gave me good performance improvement. Default 
size didn't give me good performance numbers. Due to time limits I didn't do 
much playing around with these numbers.

 
-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
 -DAsyncLogger.RingBufferSize=20480 -Dlog4j2.status.entries=1 

2) My log4j2.xml file is as follows.

<?xml version="1.0" encoding="UTF-8"?>
<configuration status="trace">
        <appenders>
                <RollingRandomAccessFile name="XXXX_LOG" 
fileName="/path/to/log/xxxx.log" filePattern="/path/to/log/xxx.log.%i" 
append="true" immediateFlush="true">
                        <PatternLayout>
                                <pattern>%d{ISO8601} %-5p [%t]: [%c{1}] %m%n - 
%X{ElapsedTime}-%X{ByteSize}- 
%X{uniqueID}-%X{HttpMethod}-%X{Host}-%X{URL}-%X{ClientIP}-%X{NodeID}-%X{NodeUserID}-%X{HttpCode}-%X{xxxxAttribute}</pattern>
                        </PatternLayout>
                        <Policies>
                                <SizeBasedTriggeringPolicy size="250 MB"/>
                        </Policies>
                        <DefaultRolloverStrategy max="10"/>
                </RollingRandomAccessFile>
        </appenders>
        <loggers>
                <root level="debug">
                        <appender-ref ref="XXXX_LOG"/>
                </root>
        </loggers>
</configuration>

I think those two changes gave me what we need. 

Now coming to the over all experience with LOG4J2, I feel it should have been 
better. Particularly in an application where we have all these open source 
components involved  (Spring, CXF, Hibernate). I think these components are 
CORE for any open source, J2EE application. As Ralph pointed out, I am not sure 
if any of the components are still using Log4j 1 jars, which are loaded by 
JBoss parent class loader. I, probably not immediately ready, to experiment 
forcing JBoss to use Log4J2, due to project timelines.

Is there a way for me to figure out which Log4j (1.2 or 2.0) JARs are used by 
Spring and CXF with-in my application ?

I still have few more tests to conduct on our TEST environment. We probably do 
it tomorrow. I can give you confirmed feed back about the performance gains, 
after those tests.

Also, we deploy 2 WAR files to the server and I saw some of the logs are 
written to other WAR's log files. But I will confirm this behavior once I do 
more tests. 

Though my experience of migrating to LOG4J2 is little bitter (I ended up 
rolling back my changes from code repository twice before, due to multiple 
reasons), the performance numbers, made me feel, it is worth going through the 
pains.

Again thanks for all your support and help. 

> Log4J2 Performs poorly with 500 concurrent users with Jboss 5.1.GA and JDK 6
> ----------------------------------------------------------------------------
>
>                 Key: LOG4J2-437
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-437
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Appenders
>    Affects Versions: 2.0-beta9
>         Environment: JDK                : 1.6.0_18
> APP Server    :  Jboss 5.1.0_GA
> Task               : Migrate from Log4J_1.2 to Log4J2
> OS                 : Linux 5 (Virtual Machine)
>            Reporter: Giri Kosuru
>            Priority: Critical
>              Labels: Performance
>
> Environment Details
> ================
> JDK                : 1.6.0_18
> APP Server    :  Jboss 5.1.0_GA
> Task               : Migrate from Log4J_1.2 to Log4J2
> OS                 : Linux 5 (Virtual Machine)
> We are trying to upgrade from Log4J 1.2 to Log4J2 due to performance reasons. 
> In log4j1.2, we saw thread BLOCKING and decided to go to LOG4J2. Before 
> migration, we tested to evaluate and we found performance improvement with 
> LOG4J2. 
> After full migration, when application moved to performance testing 
> environment, we started seeing trouble with Log4j2. We saw at least 40 TPS 
> down, with increased response times; in performance. When diagnosed, found 
> that there is increased SWAPPING  on linux and with increased IO waits (Some 
> times 15 %). 
> For the same given environment and load test; application with LOG4J_1.2 code 
> , does not have  any SWAPPING and IO waits. In addition we have BAD 
> performance with LOG4J2.
> Can anyone give us pointers on what we are doing wrong ? Or there are some 
> performance issues with LOG4J2 ?? We are stuck in between releases and if 
> there is no help coming, we may just abandon LOG4J2. So Please I request you 
> to look seriously and give us some pointers.
> Following is the configuration for log4j2.
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <configuration status="trace" verbose="true">
>         <appenders>
>                 <RollingRandomAccessFile name=“APP_1066_LOG" 
> fileName=“/path/to/log/file-1066.log" 
> filePattern=“/path/to/log/file-1066.log.%i" append="true" 
> immediateFlush="false">
>                         <PatternLayout>
>                                 <pattern>%d{ISO8601} %-5p [%t]: [%c{1}] %m%n 
> - %X{ElapsedTime}-%X{ByteSize}- 
> %X{uniqueID}-%X{HttpMethod}-%X{Host}-%X{URL}-%X{ClientIP}-%X{NodeID}-%X{NodeUserID}-%X{HttpCode}-%X{ApplicationCode}</pattern>
>                         </PatternLayout>
>                         <Policies>
>                                 <SizeBasedTriggeringPolicy size="250 MB"/>
>                         </Policies>
>                         <DefaultRolloverStrategy max="10"/>
>                 </RollingRandomAccessFile>
>                 <RollingRandomAccessFile name="hibernateAppender" 
> fileName=“/path/to/log/anotherfile-1066.log" 
> filePattern=“/path/to/log/anotherfile-1066.log.%i" append="true" 
> immediateFlush="false">
>                         <PatternLayout>
>                                 <pattern>%d{ISO8601} %-5p [%t]: [%c{1}] %m%n 
> - %X{ElapsedTime}-%X{ByteSize}- 
> %X{uniqueID}-%X{HttpMethod}-%X{Host}-%X{URL}-%X{ClientIP}-%X{NodeID}-%X{NodeUserID}-%X{HttpCode}-%X{ApplicationCode}</pattern>
>                         </PatternLayout>
>                         <Policies>
>                                 <SizeBasedTriggeringPolicy size="250 MB"/>
>                         </Policies>
>                         <DefaultRolloverStrategy max="10"/>
>                 </RollingRandomAccessFile>
>                 <Async name="ASYNC">
>                         <appender-ref ref="hibernateAppender"/>
>                         <appender-ref ref=“APP_1066_LOG"/>
>                 </Async>
>         </appenders>
>         <loggers>
>                 <root level="INFO">
>                         <appender-ref ref="ASYNC"/>
>                 </root>
>         <!-- ============================== -->
>         <!-- Various loggers -->
>         <!-- ============================== -->
>         <logger name="org.hibernate" additivity="false" level="INFO">
>                 <appender-ref ref="hibernateAppender" />
>         </logger>
>         <logger name="org.springframework.orm.hibernate3" additivity="false" 
> level="INFO">
>                 <appender-ref ref="hibernateAppender" />
>         </logger>
>         <logger name="org.hibernate.SQL" level="INFO">
>                 <appender-ref ref="hibernateAppender" />
>         </logger>
>         </loggers>
> </configuration>
> {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to