Loadtest Users
The loadtest user feature flag can be used for load testing on mobile devices.
After turning on the feature flag you can set a "loadtest factor" for a user
| 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 that user the mobile worker syncs, each case in the payload will have that many copies of it made and sent down to the phone. Copies should preserve parent/child relationships. . 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. However, copies are not actually created on CommCare HQ, so you will not see them in reports or in exports.
Caveats about this feature
There are some important caveats about this feature:
...
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
justonly for load testing
the mobile application only.
...
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
| 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. Click below to see an example.
| Expand | ||
|---|---|---|
| ||
<case case_id="55950b66-9915-4303-83c6-951d372d6940" |