This section describes some recommended performance tuning configurations to optimize the WSO2 Message Broker. It assumes that you have set up the MB on a server running Unix/Linux, which is recommended for a production deployment. It is recommended to have at least one MB server node for failover. Therefore, a clustered deployment is recommended for most production systems with at least two MB server nodes.
- Performance tuning requires you to modify important system files, which affect all programs running on the server. We recommend you to familiarize yourself with these files using Unix/Linux documentation before editing them.
- The parameter values we discuss below are just examples. They might not be the optimal values for the specific hardware configurations in your environment. We recommend you to carry out load tests on your environment to tune the ESB accordingly.
To optimize network and OS performance, configure the following settings in
/etc/sysctl.conffile of Linux. These settings specify a larger port range, a more effective TCP connection timeout value, and a number of other important parameters at the OS-level.
It is not recommended to use
net.ipv4.tcp_tw_recycle = 1when working with network address translation (NAT), such as if you are deploying products in EC2 or any other environment configured with NAT.
To alter the number of allowed open files for system users, configure the following settings in /etc/security/limits.conf file of Linux (be sure to include the leading * character).
Optimal values for these parameters depend on the environment.
If one or more worker nodes in a clustered deployment require access to the management console, increase the entity expansion limit as follows in the
<MB_HOME>/bin/wso2server.bat file (for Windows) or the
<MB_HOME>/bin/wso2server.sh file (for Linux/Solaris). The default entity expansion limit is 64000.
WSO2 Carbon platform-level settings
In multitenant mode, the WSO2 Carbon runtime limits the thread execution time. That is, if a thread is stuck or taking a long time to process, Carbon detects such threads, interrupts and stops them. Note that Carbon prints the current stack trace before interrupting the thread. This mechanism is implemented as an Apache Tomcat valve. Therefore, it should be configured in the
<PRODUCT_HOME>/repository/conf/tomcat/catalina-server.xml file as shown below.
classNameis the Java class used for the implementation. Set it to
thresholdgives the minimum duration in seconds after which a thread is considered stuck. The default value is 600 seconds.
The following sections describe how you can configure the MB-level settings to optimize performance.