PC versus SUN E10000

Question

We have a performance issue with the BEA Weblogic Server on
a SUN E10000.
Environment:
Solaris VM (build Solaris_JDK_1.2.1_04, native threads, sunwjit),
performance pack enabled,
service pack 5, SUN OS 5.6.
The WL is running on its own System Board with 4 CPUs.
There are some data read from the database
in an initial step. The results are cached and fetched
from the memory in all following steps.
We are testing with minimum load.
One user requests 3 Pages within 10 seconds.
The load of the CPUs is about 5%.
One page requires between 0,2 and 0,5 seconds.
The same tests were made on a PC.
Environment:
400MHz, NT 4.0, JDK 1.1.7B, nojit.
The PC was a little bit faster than the E10000.
After switching on PC to JDK 1.2 (V) with JIT,
the PC beats the SUN by a factor of 10.
We have tuned this a little bit, turning off all debug outputs
on the SUN. But still the PC is 5 times faster than the E10000.
Today a specialist from BEA visited us
(yes, one of the expensive ones :-)
and we are not any futher. At least he told us
to contact the support of BEA.
Here are some results:
PC E10000
Transaction 1 140ms 230ms
Transaction 2 470ms 450ms
Transaction 3 140ms 260ms
Now the PC with JDK 1.2 und JIT
java version "1.2" Classic VM (build JDK-1.2-V, native threads)
PC E10000
Transaction 1 20ms 230ms
Transaction 2 70ms 450ms
Transaction 3 20ms 260ms
As I believe from reading this newsgroup
the results on the PC are good.
What results can I expect on the E10000?
There is no bottleneck in the code.
We have made some measurements with System.millis
and the program is slow at the same points as on the PC.
It seems that the JDK is slowing down the things.
Has anyone better results on a SUN?
Why should I use the E10000 if the PC is faster?
Best Regards,
Frank.

Answer 1

Thank you for your information! It is so useful.
One question:
Use 4096 for the buffer size (default was 512).What buffer size??
Thanks
Cheers - Wei
Frank Hofmann <[email protected]> wrote in message
news:[email protected]...
>
Hello,
thanks for your contributions.
Let me tell some new facts.
I agree with Bryan and Boris as well.
Assume that a big machine with very good scaling
has some noise which results in a load of one percent.
(It is not so high, but easier for the calculation)
Now assume your test loads the machine with one percent.
The PC may have a ground load of 0 and your test does
the PC also load with one percent.
So the big machine is loaded with two percent and
the PC with one percent. The PC seems twice as fast
as the SUN.
When you repeat the test with 90% load the big machine
will win the game since the PC does not scale very well.
The NT kernel may use up 10% of your computing power.
(Or any other value but significantly more than the
big machine.)
The story continues.
It has taken two month till a specialist from SUN
has found our big mistake. Somewhere in the
startWebLogic.sh was hidden under many other option:
-Djava.compiler=
Yes, we were running without JIT. :-)
As simple as this bug seems it was very difficult to find.
Now with JIT the performance of the SUN E10000 and
the PC are nearly equal per processor at 10% load.
With little load the PC is faster with high load the
SUN is faster.
It is up to you to compare price, performance and stability.
For some of us the PC may be the better solution.
I would suggest to keep the load on the PC under 50% or so.
Performance
We are working closely together with SUN and BEA
trying to increase the performance. A big problem
is the lack of usefull performance data. There are
some information from Michael Girdley around.
But when you study them you will come to the following
conclusion: There are not enough information to compare
your system with any other system.
Available information:
What processor, operation system, speed of processor,
amount of processor, Megabyte RAM, number of Weblogic-Servers,
pages per second or transactions per second.
Not available information:
How large are the pages?
Was it a small or big program which has build
the page and was it well optimized or not?
What is meant by transaction and how many
performance does one consume?
How many transactions build one page?
It would be nice to have a benchmark which covers
the most common application. So everybody can
compare parts of his application with the benchmark.
You can never be shure that your application needs
the performance you see or if you have made something wrong.
Some of our mistakes:
We have fetched the initial context and the Home Interface
for the beans for every user.
Better: Now we fetch the context and Home Interfaces once in
a static hashtable. (Winning 10% Performance)
Initially we had many debug outputs.
We have turned of nearly all of our debug output.
(Winning 50% Performance)
At some places we have forgotten to use buffered input/output.
Use 4096 for the buffer size (default was 512).
This was also true for our loadtester. For some tests this
has reduced the measured time by 50%.
It is a good idea to use StringBuffer to concat the html-page.
And set the initial of the StringBuffer if you know it.
This has improved one of our tables from 40 seconds to 200 milliseconds.
Stability
Sometimes the Weblogic hangs as you know.
It is not very easy to reproduce it.
We have tests where the server never hangs.
This is also true for our developing.
So the weblogic hangs not by itself. It has to do
with your application.
Try to make a Thread Dump.
PC: Click on the cross to close your DOS-window.
This will force a dump. Copy the contents of the window to your editor.
UNIX: Send SIGQUIT to the java process. You will get a dump too.
Yesterday I have managed to hang the Weblogic in a reproducable manner.
I will wait a bit till I have a confirmation of other experts
that I am right. (I do not like to blame me as I have done it the
last time :-) But it seems that the weblogic has a problem
when it runs out of threads (ExcuteThreadCount) and then has
to make a database connection. It seems to the user that it
needs an other thread from the thread pool. This can be a deadlock
depending on the application.
I hope this letter was not too long.
Frank