Loadtest Users
The "Loadtest Users" feature is Generally Available for load testing on mobile devices, for Pro Plan subscriptions and higher.
| Multiexcerpt include macro | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
| Excerpt |
|---|
This feature allows you to load test the size of your CommCare application. |
| Table of Contents | ||
|---|---|---|
|
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 there are the mobile worker has 5 cases to be synced, 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 the mobile worker's their 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.)
- 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.
- Set the mobile worker's loadtest factor.
- 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 updatesAlthough 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 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.
...
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,is capped at 500,000. By that point app load will be less important than other aspects of user experience. This is
alsoa safeguard against performance issues.
Technical details: The Sync Payload
| Multiexcerpt include macro | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
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:Click below to see an example.
| Expand | ||
|---|---|---|
| ||
<case |
...
case_id="55950b66-9915-4303-83c6-951d372d6940" |
...
Ardmillan |
...
Terrace</case_name> |
...
case_id="55950b66-9915-4303-83c6-951d372d6940-1" |
...
Ardmillan |
...
Terrace |
...
(1)</case_name> |
...
case_id="55950b66-9915-4303-83c6-951d372d6940-2" |
...
Ardmillan |
...
Terrace |
...
(2)</case_name> |