Hi Asankha,
thanks for your reply. Please see my comments inline!
> 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.
Ok, but I think as we did not perform load tests and the number of
concurrent connections was quite low (about 6) these will not effect our
results. But I collect all the info for the next tests (including load
tests).
>> Linux version 2.6.23.1-amd64-75
> Hmm... are you running an AMD 64 bit version on an Intel Xeon?
I know this sounds a bit strange, but I asked our operation staff. They
told me that it is just a misleading name and the same kernel code base
will be used.
> Seems like your OS is 64 bit, but your JDK is 32 bit..
Yes, that is the current status. But we can change the JDK version to
any version you suggest. The same does not apply to the OS. We will have
almost no influence on it.
> 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...
Hmm, as stated before. We can change the JDK, but not the OS. So shall I
install a 64bit version of 1.5.0_14 or 1.5.0_15? We could also use a
Java 1.6 Update 6, 64 bit. If you know some troubles with the 64 bit
Java version in conjunction with the ESB than we can use a 32 bit
version as well. Right now we had used a 32 bit version of JDK 5
(1.5.0_10), because this version was installed on the machine. Anyhow I
would like to use a dedicated Java version in the home of the esb user.
> Also, if you are really interested about performance, and want to
squeeze
> the maximum out of the NIO transport, you could use the epoll support
> available with JDK 1.5.0 update 10 and later. Since you are using a
Linux
> kernel > 2.6, this would be possible
Would you suggest this or are there any disadvantages?
In order to activate the epoll support we had to add a line to the
wrapper.conf like the following?:
wrapper.java.additional.18=-Djava.nio.channels.spi.SelectorProvider=sun.
nio.ch.EPollSelectorProvider
> 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
Ok, I will have to find out why the developers had explicitly turned
this off. :-( Thanks for your evaluation and suggestions!
Regards,
Eric
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
