Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Load testing offline-enabled mobile apps

Updated on September 10, 2021

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.

The content described in this article is considered advanced and is likely to change in subsequent releases of Pega Platform™.


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 Dev Studio > System > Operations > Logs > Logging Level Settings.
    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 Alerts. 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.


  1. Start a third-party application, such as HP LoadRunner.
  2. Call the stateful REST service:
  3. 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 actions array 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 installationId value in each request to simulate multiple devices. The installationId can be a random string value.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us