Load testing offline-enabled mobile apps
Before you make an offline-enabled mobile app available in a production environment, perform load testing to eliminate the performance issues. Load testing is accomplished by simulating concurrent users sending payloads.
Load testing a desktop application differs from load testing a mobile app that runs in the browser or as a native app. However, in both cases you make HTTP requests to the server with a payload package to simulate concurrent users.
Before you load test a custom mobile app that you have developed by using the Pega Platform, make sure you that are familiar with the following actions and items:
- Packaging, full synchronization, and delta synchronization
- An HTTP proxy between a device and a server
- A third-party application used to perform load testing, such as HP LoadRunner
Packaging is the process of preparing data that is sent to the server. Completing a full synchronization means that the device client storage is empty on the server side because all of the content was successfully sent. Delta synchronization means that you base the synchronization only on what the device already contains in storage, and, as a result of previous synchronizations, you send only the differences (deltas). Delta synchronizations are lightweight and optimized for speed.
The difference between profiling a regular mobile app and an offline-enabled mobile app is that you must call the offline packaging request. This request is performed during the initial login and when the user performs an action and the device is connected to the server.
To load test an offline-enabled custom mobile app, follow these guidelines:
- Measure the time that was spent during packaging. You obtain this information by examining the server log. You must first enable the debug setting for the
com.pega.pegarules.session.internal.mgmt.autostreams.packaging.PackageRuntimemask. To do so, click .
By combining the client-side log with the server-side log, you can identify:
- The top 10 items that take the most time to package
- The amount of time that was spent on full synchronization and delta synchronization
- The number of items that were packaged
- To identify any SQL performance issues and long-running interactions, review all of the received alerts. To do so, from the Dev Studio developer toolbar, click . Make sure that all database queries that are performed during packaging have proper indexes and are not doing any table scans.
- When you have understood and optimized the performance of a single client mobile app, the next step is to simulate the packaging that runs concurrently for multiple devices. Load test the packaging with multiple users as described in the next section.
- Start a third-party application, such as HP LoadRunner.
- Call the stateful REST service:
- Send a payload in the request body that simulates a real device.
Before making this call, use an HTTP proxy between the device and the server to obtain a good sample of a payload package.
The following sample is for a captured payload:
This payload is a URL-encoded version of the following:
The sample payload displayed above causes a full synchronization operation because the
clientStoreContent array is empty. Triggering delta synchronization depends on how the application is used. The captured JSON contains all of the fields displayed above and additional ones, making the payload larger in size. For example, the
clientStoreContent array contains values. The captured JSON can also contain values in the
actions array if an action was executed in the application. Make sure to do the following actions:
- Empty the
actionsarray to avoid repeating the action with each load test. Do not empty this array if you want to also load test the action processing performance.
- Do not share cookies between requests.
- Use a different
installationIdvalue in each request to simulate multiple devices. The
installationIdcan be a random string value.