Performance testing
We can run performance tests on the different features of the MobileFirst Server. This section describes how to run the Apache jMeter performance test tool, but the procedure is similar for other tools.
The following features can have an impact on MobileFirst Server performance:
- Authentication flow
- Back-end invocation
- Database reporting
- Single sign-on (SSO)
- Direct update
- Push notification
- Geolocation
This section focuses on testing the impact of authentication flow and back-end invocation on MobileFirst Server performance.
Test authentication flow performance
The following realms, which are part of the default security test for Android, iOS, and Windows Phone 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 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, the first step is to complete the authentication flow. If we 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
| Parameter | Description |
|---|---|
| x-wl-app-version | Application version. |
| x-wl-platform-version | Version of the product that built the application. |
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 we can generate a random value for the dynamic parameter x.
A better option is always to clean cookies in the performance testing tool before we 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 the MobileFirst application environment. By default, if we 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 8 environment is the same as that for the iPhone environment.)
Figure 1. Response data from common environment
Figure 2. Response data from 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 we do not do so, the authentication check fails and the request is rejected. Challenge data is different for each session, so we need to extract and store the challenge data for each thread. See Test back-end invocation later in this section.
Change 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 using the performance testing tool's 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.
Test back-end invocation
You should start testing back-end invocation only after we have finished testing authentication flow. Choose any type of back end you want. The request for the back-end invocation has the following structure: http://{Host}:{Port}/{Context}/apps/services/api/{AppName}/{environment}/query.
| Parameter | Description |
|---|---|
| adapter | MobileFirst Adapter name. |
| procedure | MobileFirst procedure name |
| parameters | Procedure parameters should be an array. |
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 the performance testing tool does not support URL encoding, use encoded parameter values.
For the Android, iPhone, and Windows Phone 8 environments, since they contain wl_deviceNoProvisioningRealm by default, we 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 we 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, we need to log in to the MobileFirst Server before calling this procedure. To check if the MobileFirst adapter procedure needs a login, we 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, we 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, we can capture the network traffic on MobileFirst Server using network traffic capture tools (for example, Fiddler or Wireshark). The network traffic data shows the detailed URL and parameters we 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
The following options are available for logging out of the MobileFirst Server:
- Not logging out for each iteration
- MobileFirst Server automatically logs the user out when the session times out. This option consumes more memory than logging out, but is useful to maximize memory usage during performance testing. To adopt this option, we need to clean cookies for each iteration in the performance testing tool.
- Logging out after each iteration using the MobileFirst logout service
- It is recommended to clean cookies for each iteration to avoid sharing data between iterations. The logout request has the following structure: http://{Host}:{Port}/{Context}/apps/services/api/{AppName}/{environment}/logout
For more information about the parameters, see HTTP Interface of the production server.
Database reporting
To activate database reporting, we need to specify reports.exportRowData=true in your worklight.properties file. You also need to set up the reports database. See Reports database. After you enable database reporting, we can use the back-end invocation step described earlier. See the database reporting section in the Scalability and Hardware Sizing document at https://developer.ibm.com/mobilefirstplatform/documentation/additional-documents/.
Single sign-on (SSO), direct update, push notification, and geolocation
See the relevant section in the Scalability and Hardware Sizing document at https://developer.ibm.com/mobilefirstplatform/documentation/additional-documents/.
General example: Use 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. To keep cookie information, we 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; we can also define the WL-Instance-Id and WL_deviceNoProvisioningRealm token placeholders. We 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
-
-
Extract and replace the WL-Instance-Id placeholder:
-
Extract and replace the WL_deviceNoProvisioningRealm token placeholder:
-
Change initialization HTTP status 401 and 403 to HTTP status 200:
-
Parent topic: Configure MobileFirst Server