Asankha, thank you very much for your feedback! Please find my answers below!
> 1. Use of Keepalive connections and HTTP 1.1 (chunked encoding) To my knowledge I'm using keepalive connections and http 1.1, but I'm not sure. Under load test options of soapUI I didn't checked the option "close connections between each request". The RAW response header information looks like that: HTTP/1.1 200 OK Transfer-Encoding: chunked Date: Thu, 31 Jan 2008 12:12:31 GMT Content-Type: text/xml; charset=UTF-8 Server: Synapse-HttpComponents-NIO X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 > 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 No tuning so far, as I have no root access. I will give a task to our admins. Thanks for the detailed infos! > 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!) No problems to increase the heap space. The ESB is running under jdk1.6.0_02. > 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. Up to now we have no registry, but we would like to have a central, high available registry with version support. We are thinking about building our own registry backed by a subversion repository. How are changes to the configuration propagated between the nodes in your cluster implementation? > You could then place a hardware load balancer in front or use simple DNS > round robin load balancing etc Using a hardware load-balancer is an option we are thinking about. > You may use the DBReport mediator - but this is blocking - i.e. will > block the call until the DB transaction commits. Unfortunately this does not seem to be an option for us. Low latency is the highest priority. > 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. This sounds interesting. Maybe you could think of a new standard component like JMSReport mediator as I think this is a quite typical need. By the way, why do you emphasize on "non-persistent" JMS destinations? > You should also compare how better the ESB would perform with some > slight tuning, and I am sure you will appreciate the results :-) I will do so, if I find the time. The next thing for me will be the update to the current version 1.6. Is there any information about upgrading with regard to existing configurations? Do I only need to backup the synapse.xml from $ESB_HOME/webapp/WEB-INF/classes/conf, extract the archive to the same directory and replace the synapse.xml? At the moment I don't use the registry/repository. A short upgrading how-to would be nice. Regards, Eric _______________________________________________ Esb-java-user mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
