Re: Log4j 1.2.9, 64-bit, Websphere Performance Problems
Hi Matt, it is clearly stated in [1]: take a look where it speaks about %C and %l. Bye Piero [1]http://logging.apache.org/log4j/docs/api/org/apache/log4j/PatternLayout.html Alle 20:49, giovedì 9 novembre 2006, matt.accola ha scritto: 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. -- Q: What do you call the scratches that you get when a female sheep bites you? A: Ewe nicks. --- GPG KeyID: 84AE988E Fingerprint: F0A0 CA2A 8D8F CC12 3F5E C04C D8D5 9DC3 84AE 988E gpg --keyserver x-hkp://search.keyserver.net:11371 --recv-key 84AE988E pgpDtnmsRvyvJ.pgp Description: PGP signature
Re: Log4j 1.2.9, 64-bit, Websphere Performance Problems
matt.accola wrote: 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 currently deploying a version of our application which includes 1.2.13 to see if that helps, but the change control process takes about 1 week min to get a new app out. That's a lot of time to get feedback! If you take a look at my test cases, I did isolate the file I/O. One of the tests writes 1000 statements to the servlet console, which I assume uses STDOUT. That is blazing fast. Configuring the root logger to ERROR eliminates all the overhead so I am 99% certain it is the actual I/O operation of writing with the RollingLogFileAppender which is slow. The way we discovered the problem was by turning on logging for Hibernate to troubleshoot the issue and the application server took forever to come up becuase it was busy writing all those log statement to the disk. (CPU utilization is not high, its just slow) The file is on a local system, not remote. There is no J2EE security enabled or anything. [snip] are you using the same pattern layout as well? This may have impact, see http://logging.apache.org/log4j/docs/api/org/apache/log4j/PatternLayout.html, for example %C. -- David J. M. Karlsen - +47 90 68 22 43 http://www.davidkarlsen.com http://mp3.davidkarlsen.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Log4j 1.2.9, 64-bit, Websphere Performance Problems
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 Log4j - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Log4j 1.2.9, 64-bit, Websphere Performance Problems
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-Performance-Problems-tf2088247.html#a5795740 Sent from the Log4j - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Log4j 1.2.9, 64-bit, Websphere Performance Problems
matt.accola wrote: 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. Have you tried to do profiling of the application or the test-case while it actually is logging, to see where the time is spent? One thing I (think I) have seen personally, is that the ConsoleAppender (which goes std.out or std.error) is slow - it seems like these built-in streams simply aren't as fast as normal files. But 1/10 second sounds really slow at any rate, and must be something really weird. The appenders aren't going to some file residing on some very remote filesystem over a 64 kpbs line? You could maybe send your logconfig and more specs of the system, which might give a pointer to the problem.. E.g. what happens if you just configure the root-level to OFF - it should be fast, right? You could install a filter on the appender, so that the log.whatever invocation actually goes through, but then is ditched at the appender side - maybe it is the construction of your log-line? And btw, 1.2.13 is the cool thing to run these days! Regards, Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Log4j 1.2.9, 64-bit, Websphere Performance Problems
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 currently deploying a version of our application which includes 1.2.13 to see if that helps, but the change control process takes about 1 week min to get a new app out. That's a lot of time to get feedback! If you take a look at my test cases, I did isolate the file I/O. One of the tests writes 1000 statements to the servlet console, which I assume uses STDOUT. That is blazing fast. Configuring the root logger to ERROR eliminates all the overhead so I am 99% certain it is the actual I/O operation of writing with the RollingLogFileAppender which is slow. The way we discovered the problem was by turning on logging for Hibernate to troubleshoot the issue and the application server took forever to come up becuase it was busy writing all those log statement to the disk. (CPU utilization is not high, its just slow) The file is on a local system, not remote. There is no J2EE security enabled or anything. One concerning thing is that even the stand-alone Java application writes log statement 4 times slower. It has to be either the (1) the IBM JVM in conjunction with 64-bit Linux, (2) log4j in conjuction with the 64-bit Linux, or (3) the WAS 6 container in conjuction with 64-bit Linux. Remember, EVERYTHING including the version of WAS is the same in my environment up until the point of the OS and physical hardware. I'm pursuing #1 and #3 with IBM but can anyone else verify that 64-bit Linux with 1.2.9 performs OK? I will get more specs on the actual machine and post them. -- View this message in context: http://www.nabble.com/Log4j-1.2.9%2C-64-bit%2C-Websphere-Performance-Problems-tf2088247.html#a5801026 Sent from the Log4j - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Log4j 1.2.9, 64-bit, Websphere Performance Problems
If you take a look at my test cases, I did isolate the file I/O. One of the tests writes 1000 statements to the servlet console, which I assume uses STDOUT. That is blazing fast. Why don't you just try to write some garbage to a file for testing? Maybe go to the RollingFileAppender's source and check what it does, and try to pinch down what _actually_ is slow - if it is plain straigthforward file IO, then you're obviously slightly screwed in regards to pure java bughunting. .. and btw, customers that have an aversion to profilers should be shot, at least a little bit! The file is on a local system, not remote. There is no J2EE security enabled or anything. One concerning thing is that even the stand-alone Java application writes log statement 4 times slower. Right.. Again - make a servlet or bean or whatever (standalone java is obviously the simplest testing platform here), and just write a megabyte of garbage to a file, try both binary (bytestream) and chars (maybe its the charset conversion?!), try also in some different locations, just to rule out strange areas of the filesystem - check the speed against your own setup. You could maybe profile the standalone application, at least? Even remote; both JProfiler and YourKit (the two I know!) can do profile-to-file stuff. Happy hacking! Regards, Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Log4j 1.2.9, 64-bit, Websphere Performance Problems
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.nabble.com/Log4j-1.2.9%2C-64-bit%2C-Websphere-Performance-Problems-tf2088247.html#a5755664 Sent from the Log4j - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
