Hardware & Software

The Worklight Server can utilize three Application Servers: Apache Tomcat, WebSphere Application Server and Liberty profile. Worklight server must be installed on a 64-bit operating system with all software at 64 bit.

JDK

The Worklight Server can run on IBM JDK or Oracle JDK. Notice that when using Liberty profile application server, the performance with Oracle JDK are 15% better than IBM JDK.

JVM Tuning - Memory allocation

The following are general guidelines for JVM Memory allocations. For specific memory calculation please check the hardware calculator at http://www.ibm.com/developerworks/mobile/worklight/getting-started.html (PDF and excel sheet).

• Set the JVM to have at least 2GB memory. This means you can not use less than 2GB, however that might not be enough and you will have to specify more, based on the requirements.
• For a production environment, setting the minimum heap size and maximum heap size to the same value can provide the best performance by avoiding heap expansion and contraction.
• Specific application server configuration:

WebSphere Application Server:

Log in to the admin console. Go to Servers > Server types > WebSphere application servers: choose each server and set Java memory settings under Java Process definition > JVM arguments

Liberty see jvm.options section:

http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.wlp.core.doc%2Fae%2Ftwlp_admin_customvars.html

Apache Tomcat:

Find the Catalina script and set JAVA_OPTS to inject memory.

Tuning HTTP Connections

This configuration defines threading and execution settings for the application server.

Each incoming request requires a thread for the duration of that request. If more simultaneous requests are received than can be handled by the currently available request processing threads, then additional threads will be created up to the configured maximum.

Specific application server configuration:

WebSphere Application Server:

Log in to the admin console. Go to Servers > Server types > WebSphere application servers > server_name > Web container. By default the maximum number of threads is 50.

Liberty see executer section in: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.wlp.nd.multiplatform.doc%2Fautodita%2Frwlp_metatype_4ic.html

By default the maximum number of threads is unbounded.

Apache Tomcat:

http://tomcat.apache.org/tomcat-7.0-doc/config/http.html

By default the maximum number of threads is 200.

There are several considerations when setting http threads configuration:

• For example, if the longest call takes 500 ms and you have maximum of 50 threads, then you can have about 100 requests per second.
• In case you have a slow back-end you will need to increase the number of default threads. In addition you will need to increase the number of back-end connection threads (See setting of maxConcurrentConnectionsPerNode below).
• In case you expect high value of concurrent users you will need to increase the number of default threads
• Liberty specific: even though the maximum number of threads is theoretically unbounded, the executor service makes informed choices about whether adding another thread will actually be useful.

Tuning Database Connections

The most important parameter is the number of connection threads from the server to the database. This configuration is done in the data source.

There are two Worklight features that rely heavily on the Database. These are SSO (single sign on) and reports. When using these features you need to make sure you have enough database connection threads.

The only limitation is that each node in the Worklight server cluster cannot have more than MAX_DB_INCOMING_CONNECTIONS/NUM_OF_CLUSTER_NODES connection threads, where MAX_DB_INCOMING_CONNECTIONS is the maximum incoming connections defined in the database server and NUM_OF_CLUSTER_NODES is the number of Worklight server nodes in the cluster. A "Rough" rule of thumb would be to set the number of database connections to be the number of http threads in the application server as long as we keep the limitation above. For data source configuration check:

WebSphere Application Server:

http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Fudat_conpoolset.html

Liberty see datasource section in:

http://publib.boulder.ibm.com/infocenter/radhelp/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.wlp.nd.multiplatform.doc%2Fautodita%2Frwlp_metatype_4ic.html

Apache Tomcat:

http://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html

Tuning Back-end Connections

maxConcurrentConnectionsPerNode – The maximum number of concurrent requests that can be performed on the back-end application from the Worklight server node. The worklight server will create a thread pool with maxConcurrentConnectionsPerNode  size for that purpose. This maxConcurrentConnectionsPerNode parameter is set in the adapter.xml in the connectivity entry.

There are two considerations when setting this parameter:

• If there is no limitation in the back-end about the incoming connections then, a "Rough" rule of thumb will be to set the number of connection threads per adapter to be the number of http threads in the application server. A more precise rule of thumb will be to understand the percent of requests going to each back-end and set the number respectively.
• The back-end may have a limitation on the incoming connection threads: In that case we can have only BACKEND_MAX_CONNECTIONS/NUM_OF_CLUSTER_NODES connection threads where BACKEND_MAX_CONNECTIONS is the maximum incoming connections define in the back-end server and NUM_OF_CLUSTER_NODES is the number Worklight server nodes in the cluster.

Important change starting Worklight 6.3:  All requests to the backend remain on the http thread. The worklight server will NOT allocate new thread for the backend request. The only use of  maxConcurrentConnectionsPerNode  is for blocking the number of connections to the http backend. That mean you can put real big value  here in case you do not want to limit the backend calls. We used 5000 as a big number in our performance tuning.

Slow backend: In case your backend is slow you will need to increase your settings, specially:

1 - Number of  http threads in the application server. For backend that responded in 750ms we used 3000 http threads.

2 - maxConcurrentConnectionsPerNode  in the adapter.xml. For backend that responded in 750ms we used 3000.

3 - OS settings, for example increase the number of open files. We used 4096.

4 - The workload was based on 2900 JMETER clients threads

5 - 3000 threads were define on the backend server.

Push Notifications

For push notification information see the Push Notification section in the Scalability and Hardware Sizing PDF and hardware calculator in  http://www.ibm.com/developerworks/mobile/worklight/getting-started.html

Analytics

For analytics server configuration see the Operational Analytics section in the Scalability and Hardware Sizing PDF and hardware calculator in  http://www.ibm.com/developerworks/mobile/worklight/getting-started.html

Worklight Server Internal Configuration

serverSessionTimeout –  Client inactivity timeout, after which the session is invalidated. A session is an object stored in the server memory for each connecting device. Among other things, it stores authentication information. Active sessions are determined by the number of sessions opened vs. the sessions timing out due to lack of activity. Default session timeout is 10 minutes. The default can and should be configured. Customers typically set this to anywhere from 5 to 10 minutes. This parameter affects the server memory consumption.

In addition, the mobile client has a "heartbeat" property which allows the mobile client to ping the server while the App is in the foreground so that the server session will not time out.

Also note that when a mobile App moved into the background, it no longer interacts with the server or sends a “heartbeat” leading to the server session dropping after the specified server session timeout.

Example: Suppose every minute 1,000 users start a session against the server. Even if they exit the application after 3 minutes, their session will remain active on the server for 10 minutes, leaving us with 10 x 1,000 = 10,000 sessions.

Intervals for Background Tasks – The below worklight.properties parameters can control over the background tasks intervals. Background tasks perform several actions on the database and/or file system.

• sso.cleanup.taskFrequencyInSeconds –The SSO (Single Sign on) mechanism stores session data in a database table. This parameter is the interval for the SSO cleanup task to check if there are inactive accounts in the SSO table and if found it will delete them. Default is 5 seconds, that’s mean that every 5 seconds we will check the database for inactive accounts. Inactive account is account that was idle for more than serverSessionTimeout.
• push.cleanup.taskFrequencyInSeconds – Delete inactive push notification subscriptions, currently implemented only for Apple APNS. Default is 60 minutes.