Loadtest Users

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

...

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.

...

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 should preserve parent/child relationships. So if : 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.Copies are not created on CommCare HQ, so they will not appear in reports or exports

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

...

• 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>