It turned out to be the use of %C %l in PatternLayout. Removing that took
the per log timings back down to sub-millisecond level. Crazy! I guess I
should have heeded the warnings in the JavaDocs.
--
View this message in context:
http://www.nabble.com/Log4j-1.2.9%2C-64-bit%2C-Websphere-Perform
I have been pulled away on some other things. The next free moment I get
I'll post the results of some additional tests based on your comments.
--
View this message in context:
http://www.nabble.com/Log4j-1.2.9%2C-64-bit%2C-Websphere-Performance-Problems-tf2088247.html#a5914135
Sent from the Lo
Thanks for the reply!
The scenario is that my customer has the 64-bit machine and I have only
32-bit systems for testing. That's a problem because they will not allow me
to run our profiler on their environment :( I cannot replicate in the
32-bit environment so I can't profile here. I am curre
What can I do to get some help on this issue? Please let me know if I can
provide more information? I have opened a ticket with IBM but I think the
Log4j community will probably be more helpful.
--
View this message in context:
http://www.nabble.com/Log4j-1.2.9%2C-64-bit%2C-Websphere-Performan
Just a clarification. I report that log4j statements were taking about 200
ms but my tests show around 100 ms. This is due to the fact that larger log
statements, like the ones in the application, take longer than the small
message used in the tests.
--
View this message in context:
http://www
We are having performance problems which we traced to overhead from our
logging. Each log statemement is taking around 200 ms. The details of the
logging configuration are:
Log4j 1.2.8 with RollingLogFileAppender
http://www.nabble.com/user-files/267/test_jsps.zip test_jsps.zip
File
Descript