Hi Eric
Before I do so, I will have to setup a test
environment, where I will have reproducible results. It turned out that
our last test did not meet this requirement. It may be possible, that
other side effects influenced our test. This can easy happen, if you try
to come as close as possible to your planned live environment.
Yes, I forgot to also tell you that you need to typically run at least
10,000 iterations of each test case to warm up the JVM and the
dynamically compiled code. What I typically do is run a full test first,
ignore it, and run it again.
Thanks for that link! Up to now the instance is not tuned at all.
Oops.. the OS level tuning is very important for a high throughput
benchmark run, as otherwise you would easily exceed the file handles
(defaults to 1024 on most systems and this includes each socket etc as
well..) and the ephemeral port range.. when you monitor the system
during the test run, you can easily see these happening if you haven't
tuned your system. Also make sure your systems are connected with
Gigabit ethernet, and that the links actually are started at that speed.
Hardware-Info for test ESB instance:
2 CPU with 2 cores each (Intel(R) Xeon(R) CPU X5365 @3.00GHz)
cat /proc/meminfo
MemTotal: 16463852 kB
Cool :-) ! However, whats the amount of heap you allocate to the ESB
process with -Xms and -Xmx? Do you run any other processes on this system?
Linux version 2.6.23.1-amd64-75
Hmm.. are you running a AMD 64 bit version on an Intel Xeon?
java -version
java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode)
Seems like your OS is 64 bit, but your JDK is 32 bit.. also I would go
for 1.5.0_14 unless you have any known specific reasons with it. I would
also try the 32bit OS and JVM first as they are more comfortable to work
with and are known better.. Also, if you are really interested about
performance, and want to squeeze the maximum out of the NIO transport,
you could use the epoll <http://blogs.sun.com/alanb/entry/epoll> support
available with JDK 1.5.0 update 10
<http://java.sun.com/j2se/1.5.0/ReleaseNotes.html#150_10> and later.
Since you are using a Linux kernel > 2.6, this would be possible
Thanks for your offer! But at this point this is almost impossible.
That's why I will work to setup a new test environment, which on the one
hand will be not that far from the production use cases but far enough
to not get influenced by to many side effects.
It would be best to simulate one of your most common cases and use it to
measure, tune and validate. Unless you can consistently reproduce and
measure your performance, its not going to be easy to understand what
changes are good and what are bad.
For example, I have tried the many JVM memory parameters, and tuning the
GC algorithm, and other stuff quite a lot - but one lesson I have
learn't is that the newer Hotspot JVMs
<http://java.sun.com/javase/technologies/hotspot/index.jsp> are really
good - to the point that you don't really need to 'tune' them a lot
more! They check the available memory and detect if the system is a
'server class' machine, and auto tunes the generations and the
algorithms - sometimes even better than you could do!
Yes, we will always use HTTP 1.1. Messages will be sent out via Apache
HTTPClient. Shall we set some specific options there? In our code I
could only see disable.expect-continue and disable-keep-alive. I will
have to clarify why we use them. One comment seems to indicate a problem
with XFire in conjunction with Weblogic bridge and HTTP 100.
Opps.. always use keep-alives, this is default with HTTP 1.1 and that
gives a tremendous improvement in performance, as else each socket would
need to close, re-cycle and be re-used for each new message.. The ESB
uses keep-alives by default - unless your client says to 'Connection:
close' in the HTTP headers of the requests. If by any chance you are not
using keep-alives already, doing so will bring great improvements for sure
asankha
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
