Tuning the OS• Optimize core network settings for high throughput network activity • /etc/sysctl.conf• Increase the number of open file descriptors allowed by the OS • /etc/security/limits.conf
Tuning the JVM• Allocate sufficient memory for the heap • -Xms256m -Xmx2048m -XX:MaxPermSize=256m• Consider reducing the new ratio • -XX:NewRatio=n• Consider using the concurrent mark and sweep collector • -XX:+UseConcMarkSweepGC• Read more on JVM and GC tuning • http://wso2.org/library/articles/2010/11/taming- java-garbage-collector
Tuning the ESB• Configure transport thread pools • Configured through nhttp.properties file • IO dispatcher threads carry out network IO at the wire level • Recommended to have one IO dispatcher per CPU core • Server workers and client workers mediate the messages • More the merrier (But keep memory usage and load in mind)
Message Relay Mode• WSO2 ESB uses Apache AXIOM and the StAX API for processing XML • XML payloads are streamed through the ESB • Pull parsing model• But for pure routing, load-balancing and header- only mediation we can avoid even this step• Message relay mode works around this glitch and enables 100% pure streaming of messages • Works regardless of size and format of messages
Enabling Message Relay• Enable the binary relay builder (axis2.xml) • Instructs the ESB to stream the incoming messages through without touching their payloads• Enable the expanding message formatter (axis2.xml) • Allows the ESB to send messages that were received through the binary relay builder<messageBuilder contentType="application/xml" class="org.wso2.carbon.relay.BinaryRelayBuilder"/><messageFormatter contentType="application/xml" class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>• Above configuration tells the ESB to process all application/xml messages in message relay mode.
HTTP Relay Transport• Brand new in WSO2 ESB 4.0 release• Non blocking HTTP transport implementation specially designed for streaming messages• Doesn’t require the binary relay builder and expanding formatter• To enable, simply uncomment the relevant entries in the axis2.xml file
Error Handling• In a large scale, high throughput deployment, errors are not unusual – Expect the unexpected• Configure endpoints to gracefully handle the common errors • Connection timeouts • Connection close/reset • Connection refused • HTTP protocol violations!!!!
More on Error Handling• Configure sequences to clearly log errors and if needed notify system administrators• In case the back end server fails to respond, send detailed fault responses to clients – Makes your application more appealing to the customers• Pay attention to HTTP error codes
Monitoring• In general keep an eye on: • CPU usage • Memory usage • Thread counts • Fault counts • Latency/Response time • Active connections
Monitoring Tools• Utilities Provided by OS • top • netstat• Mediation statistics• JMX Clients • Jconsole