Loadtest Users

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

Using this Feature

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 the mobile worker has 5 cases, then a total of 100 cases will be sent to their device. Loadtest users will get a full restore; all their cases will be sent to their device.

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

Although it is difficult to cause invalid data by interacting with loadtest cases, it is possible. To prevent this, when a mobile worker's loadtest factor is set to a value greater than 1, they are automatically marked as a "demo user". This means that any forms that they submit, or changes that they make to cases, will be ignored by CommCare HQ.

When you view a loadtest user, CommCare HQ will notify you of this:

If you set the user's loadtest factor back to 1 (or delete its value), then the user will no longer be marked as a demo user.

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 IDs are also kept unique by appending a number. For example, if the case ID of the original case is "abc123", then the case ID of the first copy will be "abc123-1", the second copy "abc123-2", etc.

NOTE: All other case property values are copied exactly. It is important to keep this in mind, because if a CommCare app relies on a case property other than the case ID to be unique, that functionality will not work correctly with loadtest cases.

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.

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:

• This feature does not allow you to test sync performance at scale; it is only for load testing the app.

• The maximum total number of cases is capped at 500,000. By that point app load will be less important than other aspects of user experience. This is 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>}