This section describes some recommended performance tuning configurations to optimize WSO2 API Manager. It assumes that you have set up the API Manager on Unix/Linux, which is recommended for a production deployment.
Performance tuning requires you to modify important system files, which affect all programs running on the server. WSO2 recommends that you familiarize yourself with these files using Unix/Linux documentation before editing them.
The values that WSO2 discusses here are general recommendations. They might not be the optimal values for the specific hardware configurations in your environment. WSO2 recommends that you carry out load tests on your environment to tune the API Manager accordingly.
When it comes to performance, the OS that the server runs plays an important role.
If you are running MacOS Sierra and experiencing long startup times for WSO2 products, try mapping your Mac hostname to 127.0.0.1 and ::1 in the
/etc/hosts file as described. For example, if your Macbook hostname is "john-mbpro. local", then add the mapping to the canonical 127.0.0.1 address in the
/etc/hosts file, as shown in the example below.
127.0.0.1 localhost john-mbpro.local
Following are the configurations that can be applied to optimize the OS-level performance:
To optimize network and OS performance, configure the following settings in the
/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.
net.ipv4.tcp_fin_timeout = 30 fs.file-max = 2097152 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 net.core.rmem_default = 524288 net.core.wmem_default = 524288 net.core.rmem_max = 67108864 net.core.wmem_max = 67108864 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.ipv4.ip_local_port_range = 1024 65535
For more information on the above configurations, see sysctl.
To alter the number of allowed open files for system users, configure the following settings in the
/etc/security/limits.conffile of Linux (be sure to include the leading * character).
* soft nofile 4096 * hard nofile 65535
Optimal values for these parameters depend on the environment.
To alter the maximum number of processes your user is allowed to run at a given time, configure the following settings in the
/etc/security/limits.conffile of Linux (be sure to include the leading * character). Each Carbon server instance you run would require up to 1024 threads (with default thread pool configuration). Therefore, you need to increase the nproc value by 1024 per each Carbon server (both hard and soft).
* soft nproc 20000 * hard nproc 20000
When an XML element has a large number of sub-elements and the system tries to process all the sub-elements, the system can become unstable due to a memory overhead. This is a security risk.
To avoid this issue, you can define a maximum level of entity substitutions that the XML parser allows in the system. You do this using the
entity expansion limit as follows in the
<API-M_HOME>/bin/api-manager.bat file (for Windows) or the
<API-M_HOME>/bin/api-manager.sh file (for Linux/Solaris). The default entity expansion limit is 64000.
In a clustered environment, the entity expansion limit has no dependency on the number of worker nodes.
WSO2 Carbon platform-level settings¶
In multi-tenant 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.
<Valve className="org.wso2.carbon.tomcat.ext.valves.CarbonStuckThreadDetectionValve" threshold="600"/>
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.
Timeout configurations for an API call¶
The following diagram shows the communication/network paths that occur when an API is called. The timeout configurations for each network call are explained below.
The Gateway to Key Manager network call to validate the token only happens with the OAuth token. This network call does not happen for JSON Web Tokens (JWTs). JWT access tokens are the default token type for applications. As JWTs are self-contained access tokens, the Key Manager is not needed to validate the token, and the token is validated from the Gateway.
Key validation occurs via a Servlet HTTP call and the connection timeout can be configured by changing the following configuration details in the
<API-M_HOME>/repository/conf/deployment.tomlfile. All timeout values are in milliseconds.
[transport.client.http.properties] SO_TIMEOUT = 60000 CONNECTION_TIMEOUT = 60000
If the Key Manager caching is enabled, the calls between the API Gateway and Key Manager are cached. As a result, the Key Manager is not invoked for each API call.
Client call API Gateway + API Gateway call Backend
For backend communication, the API Manager uses PassThrough transport. This is configured in the
<API-M_HOME>/repository/conf/deployment.tomlfile. For more information, see Configuring passthrough properties. Add the following section to the
deployment.tomlfile to configure the Socket timeout value.
The default value for
http.socket.timeoutdiffers between WSO2 products. In WSO2 API-M, the default value for
General API-M-level recommendations¶
Some general API-M-level recommendations are listed below:
|Improvement Area||Performance Recommendations|
|API Gateway nodes||
Increase memory allocated by modifying the
Set the following in the
The default values mentioned are the values identified at the time of releasing API-M. However, if you want high concurrency, use the values mentioned below:
|PassThrough transport of API Gateway||
Recommended values for the
Make the number of threads equal to the number of processor cores.
The API Gateway routes the requests from your client to an appropriate endpoint. The most common reason for your client getting a timeout is when the Gateway's timeout is larger than the client's timeout values. You can resolve this by either increasing the timeout on the client's side or by decreasing it on the API Gateway's side.
Here are a few parameters, in addition to the timeout parameters discussed in the previous sections.
|Key Manager nodes||
Set the MySQL maximum connections:
Set the open files limit to 200000 by editing the
Set the following in the
If you use WSO2 Identity Server (WSO2 IS) as the Key Manager, then the root location of the above path and the subsequent path needs to change from
Set the following connection pool elements in the same file. Time values are defined in milliseconds.
Note that you set the
Registry indexing configurations¶
The registry indexing process, which indexes the APIs in the Registry, is only required to be run on the API Publisher and Developer Portal nodes. To disable the indexing process from running on the other nodes (Gateways and Key Managers), you need to add the following configuration section in the
[indexing] enable = false