Tuning

Optimize the MobileFirst Server configuration by tuning the allocation of Java virtual machine (JVM) memory, HTTP connections, back-end connections, and internal settings.

The MobileFirst Server works with three application servers:

• Apache Tomcat
• WebSphere Application Server
• Liberty profile

For best results, install MobileFirst Server on a 64-bit operating system, and use only 64-bit software.

JDK

The MobileFirst Server can run on IBM JDK or Oracle JDK. Note, however, that when using a Liberty Profile Application Server, performance with Oracle JDK is 15% higher than with IBM JDK.

JVM memory allocation

The Java instance of the application server allocates memory. Consider the following general guidelines for JVM memory allocations:

• Set the JVM memory to at least 2 GB. This means we can not use less than 2GB, but 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, as it avoids heap expansion and contraction.

• Set the required memory size of the application server:

  • Liberty: See the jvm.options section in Customize the Liberty profile environment. Create this file if it does not exist.

  • WebSphere Application Server: proceed as follows.

    1. Log in to the administration console.

    2. Go to Servers > Server types > WebSphere application servers.

    3. Select each server and set Java memory settings under Java Process definition > JVM arguments.

  • Apache Tomcat: find the catalina script and set JAVA_OPTS to inject memory.

For information about how to calculate memory size, see the Scalability and Hardware Sizing document and the hardware calculator spreadsheet.

Tune 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:

• Liberty: See the executor section in Liberty profile: Configuration elements in the server.xml file.

  By default, the maximum number of threads is unlimited.

• WebSphere Application Server: Proceed as follows:

  1. Log in to the administration console.

  2. Go to Servers > Server types > WebSphere application servers > server_name > Web container.

     By default, the maximum number of threads is 50.

• Apache Tomcat: See The HTTP Connector page in the Apache Tomcat website.

  By default, the maximum number of threads is 200.

Bear in mind the following points when we configure HTTP threads:

• If, for example, the longest call takes 500 milliseconds and we configure a maximum of 50 threads, we can handle approximately 100 requests per second.

• If the environment includes a back-end system that runs slowly, increase the number of default threads. In addition, increase the number of back-end connection threads. See Tune database connections.

• If we expect a high number of concurrent users, increase the number of default threads.

• Liberty specific: Even though the maximum number of threads is unlimited, the executor service makes informed choices whether adding another thread will actually be useful.

Tune database connections

In tuning database connections, the most important parameter is the number of connection threads from the server to the database. This configuration is made in the data source. There are two IBM MobileFirst Platform Foundation features that rely heavily on the database: SSO (single sign-on) and reports. When using these features, we must ensure we have enough database connection threads. The only limitation is that each node in the MobileFirst Server cluster can have no 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 MobileFirst Server nodes in the cluster. A rough rule of thumb is to set the number of database connections to be the number of HTTP threads in the application server, as long as you maintain the limitation above.

Each incoming request uses a thread. If more simultaneous requests are received than can be handled by the currently available request-processing threads, more threads are created up to the configured maximum.

For data source configuration, check the following:

• WebSphere Application Server: See Connection pool settings.

• Apache Tomcat: See JNDI Datasource HOW-TO.

• Liberty Server: See the Datasource section in Liberty profile: Configuration elements in the server.xml file.

Tune back-end connections

maxConcurrentConnectionsPerNode

The maxConcurrentConnectionsPerNode parameter defines the maximum number of concurrent calls to the back-end service from the MobileFirst Server node. This maxConcurrentConnectionsPerNode parameter is set in the <connectionPolicy> element of the adapter XML file.

Start from IBM MobileFirst Platform Foundation v6.3, all requests to the back-end remain on the HTTP thread. The MobileFirst Server does NOT allocate a new thread for the backend request. The only use of maxConcurrentConnectionsPerNode is for blocking the number of connections to the HTTP back-end. The implication is we can specify a large value for maxConcurrentConnectionsPerNode (for example, 5000), so as not to limit the back-end calls.

Handling slow backend servers

If the backend server is slow, increase the values for your server settings, in particular the following:

• Number of HTTP threads in the application server: For a backend that responds in 750 ms, for example, 3000 HTTP threads is recommended.

• maxConcurrentConnectionsPerNode in the adapter XML file: For a backend that responds in 750 ms, for example, 3000 is recommended.

• OS settings: Increase the number of open files. 4096 is the recommended number.

• Clients threads: A good rule of thumb is 2900 JMETER clients threads.

• Backend server: 3000 threads is recommended.

Push Notifications

For push notification information see the Push Notification section in the Scalability and Hardware Sizing document and the hardware calculator spreadsheet.

Analytics

For Analytics Server configuration see the Analytics section in the Scalability and Hardware Sizing document and the hardware calculator spreadsheet.

MobileFirst Server internal configuration

Consider the following factors:

• The serverSessionTimeout property defines 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 data, it stores authentication information. Active sessions are determined by the number of sessions opened versus the sessions timing out due to lack of activity. The default session timeout is 10 minutes, but it can and should be configured. Users typically set the timeout to anywhere from 5 to 10 minutes. This parameter affects the server memory consumption.

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

  When a mobile app has moved into the background, it no longer interacts with the server, nor sends a "heartbeat". The result is that the server session drops after the specified server session timeout.

• For example, suppose every minute 1,000 users start a session against the server. Even if they exit the application after 3 minutes, their sessions will remain active on the server for 10 minutes, leaving 10 x 1,000 = 10,000 sessions.

Intervals for background tasks

The following worklight.properties parameters control the intervals at which background tasks. 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. If any are found, it deletes them. Default is 5 seconds, meaning that every 5 seconds, the database is checked for inactive accounts. An inactive account is one that has remained idle for longer than the value of the serverSessionTimeout property.

push.cleanup.taskFrequencyInSeconds

Deletes inactive push notification subscriptions. The default is 60 minutes. This parameter is currently implemented only for Apple APNS.

Parent topic: Configure MobileFirst Server