Proposal: add tooling for memory load tests #160
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is just a proposal for the subject, built on code I've developed taking inspiration from internal QE tooling used in acceptance jobs (using
MBeans
).I am not sure if it can be actually useful for all of us - although it would be cool - so feel free to let me know your thoughts.
The idea is to have some key components that
stress test classes
can use in an easy way and so that the test developer can focus on providing the code needed to create race conditions and evaluate results.The
tooling-performance
module has been created to provide the following components:Tester
: executes test sessions and perform measurements, collecting results for the ongoing test sessionGauge
: the tool that aTester
uses to perform measurementsProtocol
: a component that is responsible for executing the proper actions needed during a test session and can communicate with theTester
that runs itEvaluator
: provides results evaluation business logic, returning an outcomeUsage is demonstrated by the class
MultipleSubsequentDeploymentMemoryStressTest
which has been added to themicroprofile-open-api
module.It defines one memory stress tests that runs a multiple redeploy protocol, aiming at detecting memory leaks.
The variable that is probed is
Heap Used space
and the evaluation is based on increase over allowed tolerance of final value compared to the initial one.The test case has been able to detect the leak reported at https://issues.redhat.com/browse/WFLY-10991
As said, this is just a proposal which can be considered with lower priority than the PRs that are actually providing tests for TP coverage, just let me know what you think.
P.S.: I had to add
manual mode
toarquillian.xml
to control container start and stop. I think this is not wanted so any idea is welcome (another container definition?).Please make sure your PR meets the following requirements: