* Ignore tests that are no longer used. Each time a library or binary is added, that requires compilation to create the *empty* test harness, which then is executed and takes multiple seconds to start up, do nothing, and return success. This removes test's for libraries that aren't actually using or running any tests. Additionally, each time a new test binary is added, that adds a ton of compilation time, but also test execution time as the binary for each test runner must start up, execute, and shutdown. So this merges all the testkit integration tests to a single running which significantly speeds up test execution. * Improve IDL exists behaviour, improve memberof verification Again to improve test performance. This improves the validation of idx existance to be a faster SQLite call, caches the results as needed. Memberof was taking up a large amount of time in verify phases of test finalisation, and so a better in memory version has been added. * Disable TLS native roots when not needed * Cleanup tests that are hitting native certs, or do nothing at all |
||
---|---|---|
.. | ||
names-dataset | ||
src | ||
build.rs | ||
Cargo.toml | ||
Dockerfile | ||
profile-sample.toml | ||
README.md |
Orca - A Kanidm Load Testing Tool
Make a profile.toml
orca setup-wizard --idm-admin-password ... \
--admin-password ... \
--control-uri 'https://localhost:8443' \
--profile ./profile.toml
Test the connection
orca conntest --profile ./profile.toml
Generate a State File
orca generate --profile ./profile.toml --state ./state.json
Run the test preflight to populate the sample data
orca populate --state ./state.json
Run the load test
orca run --state ./state.json
Design Choices
What is a profile?
A profile defines the connection parameters and test randomisation seed. From a profile you define the parameters of the test you wish to perform.
What is a state file?
A statefile is the fully generated state of all entries that will be created and then used in the load test. The state file can be recreated from a profile and it's seed at anytime. The reason to separate these is that state files may get quite large, when what you really just need is the ability to recreate them when needed.
This state file also contains all the details about accounts and entries so that during test execution orca knows what it can and can not interact with.
Why have a separate generate and preflight?
Because generating the data is single thread limited, this would also bottleneck entry creation. By generating the data first, we can then execute preflight entry creation in parallel.