CPU and Memory Utilisation

[nagkumar]

In my tests I have seen no out of memory but CPU has gone 100% multiple times and most times beyond 50% CPU

Maybe instead of using the fall loop to invoke the same test, do consider using of https://www.baeldung.com/junit-5-repeated-test so that the junit had the usual method to repeat the as now JUnitPerf not only handling repeat call in the for loop but also doing some work of following @beforeeach @AfterEach etc.. b.t.w JUnit 5 does support multiple methods with @beforeeach and @aftereach...

Using @RepeatedTest at least when junitperf spec says totalExecutions =x, then even JUnit 5 dashboard would also show x test has run x times etc..

Again, this suggestion of mine is meant for JUnitPerf to focus on performance aspects only not to repeat to follow junit 5 test running lifecycle as much as possible. The Close example is https://jmeter.apache.org/api/org/apache/jmeter/protocol/java/sampler/JUnitSampler.html which tests unit tests all externally.. In fact, this sampler only supports JUnit4 and JUnit3, not JUnit 5 yet.. hope someday that would be ready..

In short, depending on JUnitPerfTest Spec, can you think of adding repeat test annotation dynamically and let JUnithandle the rest.. and still would you be able to collect the time taken for latency

[nagkumar]

Reference for multiple BeforeEach and AfterEach

https://medium.com/javarevisited/execution-order-of-junit-annotations-cda673cda470#:~:text=We%20can%20have%20multiple%20BeforeEach,Before%20annotation%20in%20JUnit%204.

[noconnor]

@RepeatedTest does not allow for running parallel executions of the test in a thread pool, which is very useful when load testing API's. It would also not be possible to execute a test for a fix duration (with warmup & rampup periods), which again is useful when load testing API endpoints. If would also not be possible to set a target rate per second (see maxExecutionsPerSecond), again useful for load testing.

Support for running all/multiple BeforeEach and AfterEach methods is already available

To limit CPU usage during the test you can use maxExecutionsPerSecond

[nagkumar]

If would also not be possible to set a target rate per second

but what if the need any needs just totalExecutions=x (lightweight performance testing)

In such min, performance needs @RepeatedTest may still be good. Also, it may also help JUnitPerf to prove their measurements are similar to JUnit 5 (in case you give the option to do perf testing even with RepeatedTest approach for the cases that are applicable.

does not allow for running parallel executions

Not sure why JUnit has this.. even if this is a limitation now, hope they will be able to fix it in the future.

[nagkumar]

To limit CPU usage during the test you can use maxExecutionsPerSecond

May be good to talk about limiting CPU usage control in the comments of this code or rename maxExecutionsPerSecond variable accordingly

  // Test will execute no more that specified "rateLimit" executions per second
  // Default value is no limit
  int maxExecutionsPerSecond() default -1;

[noconnor]

I'll add a note about CPU usage to the main readme page