No, %C slowed the app to a crawl but without %C it was fine.
Robbie -----Original Message----- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: 21 January 2004 17:06 To: Tomcat Users List Subject: [OFF-TOPIC] RE: Weird context performance issue Howdy, Are you saying you observed different behavior for %C on the same JVM on different platforms? Or are they different JVMs? If it's the former, i.e. same JVM, please post your findings to the log4j-user list as I'd like to explore them. Yoav Shapira Millennium ChemInformatics >-----Original Message----- >From: Robbie Baldock [mailto:[EMAIL PROTECTED] >Sent: Wednesday, January 21, 2004 11:56 AM >To: 'Tomcat Users List' >Subject: RE: Weird context performance issue > >Thanks for the responses to this. > >It turned out to be because log4j doesn't work particularly well on AIX (or >at least the %C PatternLayout option) and this was dragging down one of the >webapps...! > >I still don't entirely understand why my initial "fix" for this problem >worked but at least I've got to the bottom of the problem now. > > >Robbie > >-----Original Message----- >From: Peter Lin [mailto:[EMAIL PROTECTED] >Sent: 20 January 2004 17:35 >To: Tomcat Users List >Subject: Re: Weird context performance issue > > > >this may be the result of default heap size. I've seen similar behavior on >windows with Sun jdk1.4.1. what I've seen in the past was the result of >stress testing. basically I have an app with takes a set of data and >processes it for a set number of iterations. > >when I run it for 100-700K iterations the performance is flat, but when I >run it with 750K, the response times go up 50-60%. If I increase the >iterations to 800K-2million, it remains flat. Once I changed the initial >heap setting, this behavior went away. > >it could be the addition of extra stuff causes the VM to allocate a larger >heap, which results in normal performance. other than that, I can't think >of >anything else that could cause it. > >peter lin > > >Robbie Baldock <[EMAIL PROTECTED]> wrote: >Dear all - > >This is my first post to the list and I'm posting because I have a truly >bizarre context-related performance problem which I have been unable to >resolve. > >I'm running a set of Java 1.3 webapps in Tomcat 4.1.27 in an AIX (64 bit) >environment. > >Each context has a "/Test" servlet which simply displays the contents of a >properties file. For all but one of the webapps this servlet finishes >processing within a few (less than 10) milliseconds as expected. > >However, for one of the contexts this servlet takes 400-500ms to finish. >Other servlets in this context are also very much slower than similar >servlets running in other contexts. > >The really weird part is that if I put a copy of the code for another >context's "Test" servlet into the slow context's WEB-INF/classes directory >and add an entry for it to web.xml the slow context suddenly speeds up and >runs at a satisfactory speed! This is despite the fact that there is no >interdependency between these two webapps. > >I can't find any exceptions or debug info in any logs to explain why the >context is running slowly without this extra code. > >What I don't understand is why dropping some essentially redundant code >from >another webapp should make the slightest bit of difference to the >performance of a webapp. > >To further spice up the mix, this problem does not exist in a Linux >installation of the same webapps...! > >Any ideas would be most welcome. > >Thanks. > > >Robbie Baldock > > > >--------------------------------- >Do you Yahoo!? >Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
