Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Loadtest Users

The "Loadtest Users" feature is Generally Available for load testing on mobile devices, for Pro Plan subscriptions and higher.

A mobile worker's "loadtest factor" is found under the "Action" tab of the "Edit Mobile Worker" page, as shown below.

When the mobile worker syncs, each case in the payload will have that many copies. So if the loadtest factor is set to 20, and there are 5 cases to be synced, then a total of 100 cases will be sent to the mobile worker's device.

Copies are not created on CommCare HQ, so they will not appear in reports or exports.

Cases to be synced

When a mobile worker syncs their device, not all their cases are in the payload sent to the device: HQ only sends the cases that are not already on the device, or that need to be updated.

So to send loadtest cases to the device, they need to be added on HQ. This can be done using App Preview or Web Apps, or by importing cases from Excel. (Similarly, to sync loadtest cases in App Preview or Web Apps, they need to be added on a mobile device or imported.)

  1. Register new cases as the mobile worker using App Preview or Web Apps, or import cases from Excel with the mobile worker set as the owner.
  2. Set the mobile worker's loadtest factor.
  3. Sync the mobile worker's device

WARNING: If the loadtest cases include case updates, syncing will fail with an error: "Server provided improperly formatted data, please try again or contact your supervisor" (Mobile) or "Could not sync user data. Please report an issue if this persists." (App Preview). This is because loadtest cases need to be new cases, not case updates. To resolve the error, set "loadtest factor" to 1 and sync the case updates.

About loadtest cases

Copies will be named with a number after the case name indicating what copy it is. For example, if the original case is named "My Case", then the first copy will be named "My Case (1)", the second copy "My Case (2)", etc.

Case relationships

Loadtest cases preserve parent/child relationships: If "Child Case" is the child case of "Parent Case", then "Child Case (1)" will be the child case of "Parent Case (1)", etc. In other words, loadtest case indexes point to other loadtest cases, not to real cases.

Modifying loadtest cases

CommCare allows the user to modify a loadtest case, but CommCare HQ will not create that case.

Deleting loadtest cases

Deleting a loadtest case will have no effect on HQ. However, if CommCare HQ creates the same loadtest case again, Web Apps and CommCare Mobile will throw an error when the user tries to sync, and syncing will fail.

Real cases related to loadtest cases

CommCare allows the user to create a real child case whose parent is a loadtest case. It does not allow a user to create a real extension case whose host case is a loadtest case, but it does allow a user to create an extension case whose host case is the child of a loadtest case.

All of these scenarios will result in silently broken case indexes in CommCare HQ.

Best practice: Use a temporary mobile worker

It is recommended to create a temporary mobile worker for loadtesting, and to delete that mobile worker when loadtesting is complete. The loadtest user should only own test data. They should not own data about real people or things.

Caveats about this feature

There are some important caveats about this feature:

  • Form submissions against copies will not properly handle case processing. It is recommended you only test form submissions against the original cases and not the copies.
  • This feature does not allow you to test sync performance at scale; it is only for load testing the app.
  • Once the sync payload is generated, the user's loadtest factor is reset. This is a safeguard against performance issues.
  • The maximum total number of cases that will be synced is 50,000 (unless the user has more than 50,000 real cases). Beyond 50,000 cases, app load will be less important than other aspects of user experience. This is also a safeguard against performance issues.


Technical details: The Sync Payload

As mentioned in "About loadtest cases", the case names of loadtest cases have " <number>" appended. Case IDs also have "-<number>" appended. All other values will be identical. For example:

<case case_id="55950b66-9915-4303-83c6-951d372d6940"
      user_id="7d9a624219a549babbc87e5f2bb65476"
      date_modified="2022-03-15T18:07:23.454000Z">
  <create>
    <case_type>household</case_type>
    <case_name>1 Ardmillan Terrace</case_name>
    <owner_id>7d9a624219a549babbc87e5f2bb65476</owner_id>
  </create>
  <update>
    <date_opened>2022-03-15</date_opened>
  </update>
</case>
<case case_id="55950b66-9915-4303-83c6-951d372d6940-1"
      user_id="7d9a624219a549babbc87e5f2bb65476"
      date_modified="2022-03-15T18:07:23.454000Z">
  <create>
    <case_type>household</case_type>
    <case_name>1 Ardmillan Terrace (1)</case_name>
    <owner_id>7d9a624219a549babbc87e5f2bb65476</owner_id>
  </create>
  <update>
    <date_opened>2022-03-15</date_opened>
  </update>
</case>
<case case_id="55950b66-9915-4303-83c6-951d372d6940-2"
      user_id="7d9a624219a549babbc87e5f2bb65476"
      date_modified="2022-03-15T18:07:23.454000Z">
  <create>
    <case_type>household</case_type>
    <case_name>1 Ardmillan Terrace (2)</case_name>
    <owner_id>7d9a624219a549babbc87e5f2bb65476</owner_id>
  </create>
  <update>
    <date_opened>2022-03-15</date_opened>
  </update>
</case>



  • No labels