Hi Eric
Server C (Linux, 4 cores, 4GB RAM)
WSO2 ESB 1.5
Your test scenario is good, however I must make some comments as you are
running the ESB on a 4 core 4GB machine on Linux, where you should
expect better performance. Some of the reasons for this would be the
following:
1. Use of Keepalive connections and HTTP 1.1 (chunked encoding)
Unless you use keepalives, the OS may need to establish a TCP connection
for each outgoing message which could be costly. Also note that since
the ESB site in the middle, this means that two TCP connections are
established between the client and the ESB and the ESB and the backend
service for each message. Also, unless you use a client that supports
HTTP 1.1 (chunked encoding), content cannot be written to the sockets
unless the complete size of the payload is known (i.e. Content-Length) -
this may require the buffering of the complete message in memory and the
subsequent calculation of the size which may prove to be expensive
2. OS level tuning of TCP and heap memory for the process
Unless you tune your file handles, and TCP sockets available to your OS,
you are not using your ESB to its full capacity.
/etc/sysctl.conf
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_fin_timeout = 30
fs.file-max = 2097152
/etc/security/limits.conf
* soft nofile 4096
* hard nofile 65535
At a minimum, you should increase the file limits and the port range as
shown above, and also if you are using large messages with a high number
of clients concurrently - increase the heap memory allocated for the ESB
process - via the shell script or the wrapper.conf. The default memory
used by the ESB would be just 128MB even on a 4GB machine. Note that
when you use a JDK 1.5.x (preferably 1.5.0_13) on a server grade
machine, you do not require any other JVM tuning! (Yeah, the JVM's these
days are really that good!)
>From my point of view this looks not to bad. I'm quite happy with this
numbers. The overhead increases with the number of concurrency. Also the
CPU load on the ESB rises. So of course we need to cluster the ESB and
balance the load between different instances. Is there any support so
far?
Sure, your config above is stateless and you can run multiple instances
of the ESB using the same configuration. The configuration may be stored
on a SVN for example (i.e. to support versioning, and moving config from
dev->qa->staging->production etc) and loaded locally at each node (for
best fault tolarance) or shared off a common file system or Registry.
You could then place a hardware load balancer in front or use simple DNS
round robin load balancing etc
Another requirement regards traceability of requests. I really like the
tracing infos of WSO2. I guess they are designed to locate configuration
problems.
Using the INFO-Level I receive a lot of useful information, of course
more than I need. So tracing might be the wrong approach here.
Of course, writing any kind of trace information, logs etc has a cost
and you should NOT use these during performance testing. You are correct
on the tracing facility that its targetted to help resolve development
time integration issues
What I really would like to have are the following infos:
Incoming request:
Timestamp, Source-IP, unique requestID (based on selected custom header
information)
Outgoing request:
Timestamp, Destination-IP, unique requestID (based on selected custom
header information)
This information should go to a database asynchronously. Entries could
be grouped using the requested.
Any ideas how to achieve this without notably performance degradation?
You may use the DBReport mediator - but this is blocking - i.e. will
block the call until the DB transaction commits. You are also able to
use a custom mediator that logs to a in-memory (i.e. non-persisted) JMS
destination, where a number of MDB's read from these and writes to the
DB asynchronously - we have done this exact same scenario for another
customer of ours a few months back.
All measuring was taken without any TCP/IP-Stack optimization. I
basically did it to see how much "overhead" an ESB will introduce.
You should also compare how better the ESB would perform with some
slight tuning, and I am sure you will appreciate the results :-)
I am delighted to hear about these tests and would be really happy to
help you on any issues or questions you have on this
asankha
_______________________________________________
Esb-java-user mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
