Hi johan, ok, I think I'm getting a clearer picture, but as you said, it is a complex problem. just to summarize and make sure I understand what is happening. 1. the pure java code runs the same on all systems, which indicates the java code by itself is unlikely the cause 2. there's some weird CPU usage behavior under load 3. websphere runs the same on all three systems? 4. chaining JDK/VM didn't affect performance >From the additional details you've provided, my feeling is you can rule out the >following: 1. the bug is the result of java code + tomcat. the reason I feel it's not likely is because the same code behaves different on the P4 2.8 vs. P4 1.8. If it was the result of the java code interacting with tomcat, both systems should be affected. I wouldn't rule it out completely, but it's very unlikely. 2. network IO is unlikely the true cause. this is based on the assumption your application doesn't try to manipulate the outputstream beyond simply printing to it. on the otherhand, if your app does funky things with the outputstream, like custom encoding, custom compression, buffering and so on, that could very well cause the performance problem. Let me give you an example. about 1.5 yr back I was working on a webapp which had custom error pages. If an error occurred due to bad request params or external queries failed, it would redirect to a custom error page which was dynamically created. we extended the access log to record the page processing time and gzip compression. The end result was in some cases if external queries failed, it caused our code to go into a loop for a few minutes. I'm really anal about running performance benchmarks often, so I caught it early. the solution I ended up implementing was to allow requests to redirect to the custom error page once. The behavior before was due to the fact the custom error page encountered an error and was redirecting to itself recursively. my fix was to set an attribute, so that it only redirects to the error page once. 3. JDK is unlikely a cause for the obvious reasons, but it could be if you're using XML. I'll qualify this statement a bit. XML consumes copious amounts of memory and slower machines with smaller L1/L2 cache have a harder time. Since one of the two 2.4ghz machines was slow, it's unlikely the VM, unless the server is on a different OS. JDK1.4 is generally faster with memory intensive apps. Now for potential causes. High CPU usage is your smoking gun here. Typically, the CPU usage due to tomcat should be less than 10-15% unless you're serious stressing it. I'm guessing you're only sending one request at a time. Reasons why Tomcat might have high CPU usage. 1. if your servlet/jsp creates a separate thread to do some process 2. the application uses an app wide component, like a caching mechanism 3. queries to the database are not properly closed and remain open for some weird reason. 4. your app gets data from some external source using your own driver. I did this once in the past. I was using a multi-threaded driver we wrote in house to get XML data. The connections were pooled and wasn't killed immediately. I discovered it during an integration stress test and noticed the response times started to grow and the thread count started to increase. As usual, if you provide more details about the funcationality, it is easier to diagnose the problem. if it is important, you may want to get permission from your superiors to post more details, otherwise you're on your own. With the information you've provided so far, people can only guess and some of the suggestions will be totally wrong. Heck my suggestions could be totally off. good luck with debugging. peter lin
Johan Coens <[EMAIL PROTECTED]> wrote: Hello all, I tried: - isolating code in a java class and running it on both machines, about same performance - running tomcat 4.1.29, bit faster but still ~15 sec. - changing network connection to full duplex, 2*faster but stil ~6 sec (should be < 1 sec). indicates network traffic could be a bottleneck - running websphere, performance ~600 ms. - changing java version 1.3.06 to 1.4.1, no reasonable effects - eliminating all services, no effect The tested machines: (the machine which performance is fast, a dev. client) P4 2.4Gh, 512MB memory, 60Gb harddisk (the machine which performance is slow, the server) P4 2.4Gh, 1Gb memory, 10Gb harddisk (the machine which performance is slow, a dev. client) P4 1.8Gh, 512MB memory, 40Gb harddisk I see tomcat running high on processor performance, peeks in processor performance are the same as peeks in the network traffic. But, when running everything on one box, it is also slow (so network should not be an issue). Also, the developer on the fast machine noticed that when getting code from CVS from other developers, his system slowed down signifficant too, but I have no clue what too look for with this indication. I hoped to hear a some kind of, hey look into this or look into that, did you look here, but unfortunattaly there's not. It is also a complex problem with many factors that could be the cause (network?, language settings os?, system settings?, file system?, foreign processes which interfere?, ...). If anyone has got a clue i would be glad too here, meanwhile i'll go look furher looking for a solution / cause. Cheers, Johan -----Original Message----- From: Nikola Milutinovic [mailto:[EMAIL PROTECTED] Sent: 13 January 2004 20:14 To: Tomcat Users List Subject: Re: dramatic performance differences on development machines > Unfortunattaly no option, we are bound to a specific java version and tomcat > version to gain support from the supplier... Then could you just *try* a different version? If it works, then YELL at your supplier - they would deserve it, sticking to a buggy version. For that matter, sticking to just one version. Note that 4.1.24 is a RI for Sun's J2EE paltform and so is 5.0.16 Nix. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
