...
| 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.
...
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.
...
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
| Multiexcerpt include macro | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
...