REST Services performance

Setting the heap size

If the heap size is not set correctly for the WebSphere® Application Server, exceptions might occur. For example, an OutOfMemoryError exception might indicate that the maximum heap size for the Java Virtual Machine is too low. You can increase the value, but do not it make bigger than the physical memory; if you do, disk I/O caused by swapping might occur.

Limiting the amount of information returned

An OutOfMemoryError exception might also be caused by the way your client application is programmed.

To limit the number of items to be retrieved from a IBM® Content Manager repository, the Query API has an optional parameter, limit. For an example of how to use it, see POST /items/query?limit=10&latestVersion=true.

To control the details of the data that are returned, the Query and Retrieve APIs have an optional parameter, retrieve. By default, PIDs are returned; set retrieve to include attributes and part meta data. For examples of using retrieve, see:

POST /items/query?limit=2&retrieve=attributes&latestVersion=false

POST /items/query?limit=2&retrieve=partsMetaData&latestVersion=true

Enabling database connection pooling

For high volume, concurrent REST Services requests, consider enabling database connection pooling. For more information, see Configuring WebSphere Application Server connection pooling for use with a client.

Enabling datastore pooling

The IBM Content Manager REST Services support the use of CMBConnectionPool to pool datastores for multiple IBM Content Manager servers.

Each server that is accessed by REST Services uses one CMBConnectionPool; however, all of the servers use the same settings. The settings are in the cmbconnectionpool.properties file, under WAS_HOME/profiles/profileName/installedApps/cellName/cmwebsvc.ear/cmgmt/.

Upgrading REST Services

Before you upgrade REST Services or apply a fix pack, back up the cmbconnectionpool.properties and cmrestservices.properties files, because they are overwritten by the update process. After updating REST Services, copy the files back to their original directory.

Using REST Services with WebSphere® Liberty

If you use REST Services with WebSphere® Liberty, copy the cmbconnectionpool.properties file to the WebSphere® Liberty installation directory. For more information, see Configuring the to run on.

Settings in the cmbconnectionpool.properties file

REST Services use the following settings that are in the cmbconnectionpool.properties file:

MinFreeConnections=0
TraceEnabled=false
ConnectionType=0
MaxConnections=100
MaxConnectionsPerUserid=0
MaxFreeConnections=100
MaxFreeConnectionsPerUserid=0
MaxThreadWaitTime=5000
MaxConnectionBehavior=1
TimeOut=600000

To change these settings to your requirements, see The CMBConnectionPool bean.

The connection settings (for example, ServerName/Username) for each server come from the login request or other requests with the token filled in the Authorization header. The connect string is ignored when the connection pool is enabled. The server administrator must set everything in the configuration files for the connection pool, so that clients cannot specify a connect string.

Using the connection pool in REST Services

1. In the cmrestservices.properties file, set enableConnectionPool=true. This parameter enables the connection pool in REST Services.
2. In the cmbconnectionpool.properties file, set the following parameters of the connection pool to your required values:

   MinFreeConnections=0
   TraceEnabled=false
   ConnectionType=0
   MaxConnections=100
   MaxConnectionsPerUserid=0
   MaxFreeConnections=100
   MaxFreeConnectionsPerUserid=0
   MaxThreadWaitTime=5000
   MaxConnectionBehavior=1
   TimeOut=600000

   Ignore the other parameters that are in the file.

3. Use the login endpoint or token to connect to different servers, like this:

   //connect to icmnlsdb1 with login endpoint
   HttpPost httpPost = new HttpPost(REST_URI + "/login");
   ObjectMapper mapper = new ObjectMapper();
   ObjectNode node = mapper.createObjectNode();
   node.put("servername", icmnlsdb1);
   node.put("username", icmadmin1);
   node.put("password", password1);
   ...
   //save the token for future connect
   HttpResponse httpResponse = HttpClientBuilder.create().build().execute(httpPost);
   HttpEntity entity = httpResponse.getEntity();
   authenticationTokens1 = EntityUtils.toString(entity, "UTF-8");
   ...do some work...
   
   //connect to icmnlsdb1 with the saved token
   httpPost.addHeader(HttpHeaders.AUTHORIZATION, authenticationTokens1);
   ...do some work...
   
   //connect to icmnlsdb2 with login endpoint
   HttpPost httpPost = new HttpPost(REST_URI + "/login");
   ObjectMapper mapper = new ObjectMapper();
   ObjectNode node = mapper.createObjectNode();
   node.put("servername", icmnlsdb2);
   node.put("username", icmadmin2);
   node.put("password", password2);
   ...
   //save the token for future connect
   HttpResponse httpResponse = HttpClientBuilder.create().build().execute(httpPost);
   HttpEntity entity = httpResponse.getEntity();
   authenticationTokens2 = EntityUtils.toString(entity, "UTF-8");
   ...do some work...
   
   //connect to icmnlsdb2 with the saved token
   httpPost.addHeader(HttpHeaders.AUTHORIZATION, authenticationTokens2);
   ...do some work...