On Wed, 2003-06-25 at 08:15, Damien Lecan wrote:
> Hello,
> 
> I am trying to get better performances from a linux plateforme and I am 
> a little bit disappointed.
> 
> I am testing a full J2EE application, ie 3 physical layers 
> (apache/tomcat <=> jboss <=> oracle db ; 3 servers), and this is very 
> slow on linux ... compared to the same plateforme on Windows 2000 server 
> (except for the db, this a HP server for both tests).
> 
> Every servers are equiped with JVM SUN 1.4.1_01 and Linux is RedHat 7.3, 
> not customized.
> 
> I know I could try other VM, but I am wondering if the problem comes 
> from the OS or from the VM (on windows, performances are twice better), 
> or from both ?
> 
> What should I modify on my redhat ? Should I use IBM ou Blackdown VM ?
> 
> Thanks for your help, I really would like to use linux instead of 
> windows for servers ...

So, it's really hard to say without a lot more data and analysis. I
would recommend that you do some profiling to see where you are seeing
the bottleneck. It could be something as simple as a configuration
issue. It would also be helpful to have some notion of "very slow".

I have to say that if you are using apache/tomcat on Windows 2000, I am
surprised that the Windows 2000 box is outperforming Linux. My own
experiences with that particular configuration yielded pretty poor
results.

The one other thing that crosses my mind is that it is possible you are
using the server VM for the Linux test, but the client VM for the
Windows test (particularly because Windows JVM does not come with the
server VM by default). Benchmarking the server VM can be a bit of a
trick, because you essentially have to do some "VM training" in order to
get it to optimize itself. While both VM's "train" as they run, the
train time for the client VM is very short, and the client VM runs
faster while training, so it will tend to show much better numbers.

But really, aside from the issue I raised in the previous paragraph, I'd
want to do a lot of profiling and analysis on the system before making a
call on this.

--Chris


----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to