Eric
One question: What is the CPU count on the client when this is happening?
Comments
Please try adding [0] at the end of the XPath expression. I'm not sure
if this will make a difference, but it might. The whole message should
not be parsed, just the headers.
As regards clustering, you should be able to use ESB with any IP
spraying or load-balancing technique, e.g. hardware load-balancer, LVS,
etc. We have put some work into sharing state across a cluster for
throttling and caching. We also have done some work on hot-update across
a cluster - basically you "gracefully shutdown" each server in turn,
with the result that no requests are lost, and the load balancer
redirects work to the rest of the cluster.
As regards writing asynchronously to a database, I'm sure we can come up
with a mediator that does that - maybe we spawn a worker thread at
startup that writes to the DB from a queue and the mediator writes to
the queue. Based on your tests so far, I don't think this kind of
database writer will affect your performance much.
Paul
Hubert, Eric wrote:
Hi all,
I would like to share some measurements regarding the performance of
WSO2 ESB regarding content based routing.
Before I post the concrete numbers I would like to introduce my simple
test environment.
Server A (Linux, 4 cores, 4 GB RAM)
JBoss AS 4.2 running a simple WebService (JBoss WS, JSR 181 POJO-based)
Server B (Linux, 4 cores, 4 GB RAM)
JBoss AS 4.2 running the same simple WebService as Server A (JBoss WS,
JSR 181 POJO-based)
Server C (Linux, 4 cores, 4GB RAM)
WSO2 ESB 1.5
Client (Windows XP, 2 cores, 3 GB RAM)
soapUI 2.0
The WebService exposes one simple test method which "fakes a real
service implementation" of a constant time of about 50 ms.
The implementation of the test method contains something like that:
Thread.sleep(50);
InetAddress localMachine = InetAddress.getLocalHost();
return "Hello " + name + " on " + localMachine.getHostName();
where name is a method parameter.
A simple SOAP requests looks like that:
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:esb="http://service.esb.jamba.de/";>
<soapenv:Header>
<esb:version>1.0</esb:version>
</soapenv:Header>
<soapenv:Body>
<esb:hello>
<arg0>Test</arg0>
</esb:hello>
</soapenv:Body>
</soapenv:Envelope>
The version number can be varied during the tests. Based on the version
number I used a switch mediator in the WSO2 ESB.
Here is an extract of the generated config:
<syn:switch xmlns:esb="http://service.esb.jamba.de/";
xmlns:ns1="http://org.apache.synapse/xsd";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
source="/child::soapenv:Envelope/child::soapenv:Header/child::esb:versio
n">
<syn:case regex="1.0">
<syn:send>
<syn:endpoint key="SimpleWebService_V1.0"/>
</syn:send>
</syn:case>
<syn:case regex="1.1">
<syn:send>
<syn:endpoint
key="SimpleWebService_V1.1"/>
</syn:send>
</syn:case>
</syn:switch>
Maybe the XPath expression could be improved. I'm not very familiar with
XPath. So far I did no tests with big messages. Will the whole message
get parsed if I only need the content from the header?
I then created a test case in soapUI which includes two test steps. One
request with version 1.0 and one with 1.1.
1) First of all I wanted to test the direct endpoints. So I pointed the
first request to Server A and the second request to server B.
2) After that I pointed both request to Server C (WSO2 ESB), which
routes half of the requests to Server A and half of the requests to
Server B based on the version-info in the soap header.
For both scenarios I used three different tests:
A) Number of Start Threads 1, Number of End Threads 1, 60 seconds (no
concurrency)
B) Number of Start Threads 1, Number of End Threads 10, 60 seconds
C) Number of Start Threads 10, Number of End Threads 50, 120 seconds
And here are the numbers:
A1) Direct Access to endpoints
---------------------------
avg. response time (ms) 62
min. response time (ms) 56
max. response time (ms) 86
response count 480
responses per second 16
bytes per second 4143
A2) Using WSO2 in the middle
avg. response time (ms) 76
min. response time (ms) 60
max. response time (ms) 96
response count 391
responses per second 13
bytes per second 3550
max. CPU-Load 15%/400%
B1) Direct Access to endpoints
---------------------------
avg. response time (ms) 62
min. response time (ms) 56
max. response time (ms) 84
response count 2535
responses per second 158
bytes per second 4120
B2) Using WSO2 in the middle
avg. response time (ms) 78
min. response time (ms) 59
max. response time (ms) 102
response count 2108
responses per second 129
bytes per second 3416
max. CPU-Load 70%/400%
C1) Direct Access to endpoints
---------------------------
avg. response time (ms) 72
min. response time (ms) 55
max. response time (ms) 251
response count 23092
responses per second 692
bytes per second 3459
C2) Using WSO2 in the middle
avg. response time (ms) 77
min. response time (ms) 58
max. response time (ms) 402
response count 21240
responses per second 649
bytes per second 3897
max. CPU-Load 170%/400%
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?
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. 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?
Anyhow here are the numbers with tracing enabled (INFO-Level).
A2) Using WSO2 in the middle (tracing INFO)
avg. response time (ms) 77
min. response time (ms) 58
max. response time (ms) 87
response count 887
responses per second 15
bytes per second 4032
max. CPU-Load 15%/400%
B2) Using WSO2 in the middle with tracing enabled (INFO-Level)
avg. response time (ms) 77
min. response time (ms) 57
max. response time (ms) 440
response count 2159
responses per second 130
bytes per second 3416
max. CPU-Load 70%/400%
C2) Using WSO2 in the middle with tracing enabled (INFO-Level)
avg. response time (ms) 86
min. response time (ms) 59
max. response time (ms) 517
response count 17067
responses per second 590
bytes per second 2950
max. CPU-Load 267%/400%
All measuring was taken without any TCP/IP-Stack optimization. I
basically did it to see how much "overhead" an ESB will introduce.
Regards,
Eric
--
Eric Hubert
Software Architect
Associate Director Research & Development
_______________________________________________
Esb-java-user mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
Office: +1 646 290 8050
Cell: +44 798 447 4618
blog: http://pzf.fremantle.org
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
_______________________________________________
Esb-java-user mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
