Testing MobileFirst Server performance

Testing authentication flow performance

The following realms, which are part of the default security test for Android, iOS, and Windows Phone Silverlight 8, are tested:

Remote disable realm

Check on every request that the application is not blocked.

AntiXSRF realm

Check on every request that WL-Instance-Id is equal to the one sent in the init response.

Anonymous User realm

Generate a random user ID that is used for such things as reports and identifying the user.

Device no provisioning

Check that the token value inside the authorization header is equal to the one sent in the initialization response.

For more information about the realms, see The authentication configuration file.

When you run a performance test, your first step is to complete the authentication flow. If you do not do so, security challenges are raised and your requests are rejected with "401" errors. This step involves sending an init request to the MobileFirst Server and extracting the relevant data from the response. The init request has the following structure: http://{Host}:{Port}/{Context}/apps/services/api/{AppName}/{environment}/init

This is an example of a jMeter test:

The dynamic parameters in the Form Data (skinLoaderChecksum, isAjaxRequest, and x) are appended to the URL. During performance testing, the skin and skinLoaderChecksum parameters are not needed because jMeter does not really run the app: jMeter only simulates the client app. The parameter x aims to prevent response data from being returned from cache. As a result, you do not need to append the parameters during performance testing or you can generate a random value for the dynamic parameter x. A better option is always to clean cookies in your performance testing tool before you start loading test threads.

Response data from MobileFirst initialization service

The response data from the MobileFirst init request differs depending on the security test you apply on your MobileFirst application environment. By default, if you have no additional security test, the response data structure for the common and iPhone environment are shown in the following figures. (The data structure for the Android and Windows Phone Silverlight 8 environment is the same as that for the iPhone environment.)

The difference between the common and iphone environment data structures is that the common environment has no wl_deviceNoProvisioningRealm challenge by default.

Extracting the init response data

You need to extract the WL-Instance-Id and the token from the init response and send them as headers in all requests to the MobileFirst Server. If you do not do so, the authentication check fails and the request is rejected. Challenge data is different for each session, so you need to extract and store the challenge data for each thread. For more information, see Testing back-end invocation later in this section.

Changing the response status to HTTP 200

When the performance testing thread runs the initialization for the first time, MobileFirst Server responds to challenge data with an HTTP 401 status. This is to be expected, so the performance tool should treat this HTTP status as a success. The HTTP status can be changed to HTTP 200 by using the performance testing tools script. In this way, the performance testing tool will record the request as a success, otherwise the performance testing report might mark this request as having failed and might record it as an error. This would greatly impact the performance testing report.

Testing back-end invocation

You should start testing back-end invocation only after you have finished testing authentication flow. You can choose any type of back end that you want. The request for the back-end invocation has the following structure: http://{Host}:{Port}/{Context}/apps/services/api/{AppName}/{environment}/query.

The following figure shows an example array of parameters:

The following figure shows an example of request headers:

By default, the jMeter tool encodes the URL. If your performance testing tool does not support URL encoding, you must use encoded parameter values.

For the Android, iPhone, and Windows Phone Silverlight 8 environments, since they contain wl_deviceNoProvisioningRealm by default, you need to send the Authorization header. . The format for HTTP Authorization header is shown as follows. You need to replace ${device-token} with the token you extracted in the initialization phase. {"wl_deviceNoProvisioningRealm":{"device":{"id":"1234567890","os":"5.0","model":"testModel","environment":"iphone"},"app":{"id":"testId","version":"1.0"},"token":"${device-token}","custom":{}}} When the response data "isSuccessful" is true, this indicates that the response data from the MobileFirst Adapter procedure was successfully received and now you can continue with your back-end testing.

Logging in

When the MobileFirst adapter procedure is protected by a security test or the connectAs property is set to endUser, you need to log in to the MobileFirst Server before calling this procedure. To check if the MobileFirst adapter procedure needs a login, you can call the procedure followed by the steps described earlier, and check the response data from the MobileFirst Server. If the response data includes isSuccessful:true and authStatus:required, you should log in to the MobileFirst Server first, otherwise the requests to this procedure are rejected by MobileFirst Server. The way you log in to the MobileFirst Server depends on the authentication type. If the app is protected by form-based authentication or adapter-based authentication, you can call the login procedure after successfully completing initialization. In general, the login procedure should not be protected by a security test; it can be directly called after initialization is completed. For other authentication types, you can capture the network traffic on MobileFirst Server by using network traffic capture tools (for example, Fiddler or Wireshark). The network traffic data shows the detailed URL and parameters that you can use to log in to the MobileFirst Server. The following screen image shows an example of a login function that calls the setActiveUser API with the supplied user ID and password:

Logging out

For more information about the parameters, see HTTP Interface of the production server.

Database reporting

To activate database reporting, you need to specify reports.exportRowData=true in your worklight.properties file. You also need to set up the reports database. For more information, see (deprecated) Reports database. After you enable database reporting, you can use the back-end invocation step described earlier. See the database reporting section in the Scalability and Hardware Sizing document at the Developer Center website for IBM MobileFirst™ Platform Foundation.

Single sign-on (SSO), direct update, push notification, and geolocation

See the relevant section in the Scalability and Hardware Sizing document at the Developer Center website for IBM MobileFirst Platform Foundation.

General example: Using jMeter as a performance testing tool

HTTP cookie management

Cleaning the cookies on every thread iteration ensures that no data and user information is being cached during this iteration. If you want to keep cookie information, you need to clean the user information at the end of the iteration to avoid unexpected errors during load testing. For example, if the user does not log out during the previous iteration, the next iteration might be affected by that user.

HTTP Header Management

The necessary x-wl-platform-version and x-wl-app-version that were described earlier can be defined here; you can also define the WL-Instance-Id and WL_deviceNoProvisioningRealm token placeholders. You can use a jMeter script to extract the real challenge data and replace the placeholders for each thread iteration as shown in the following image:

Initialization phase

1. Extract and replace the WL-Instance-Id placeholder:

   

2. Extract and replace the WL_deviceNoProvisioningRealm token placeholder:

   

3. Change initialization HTTP status 401 and 403 to HTTP status 200: