maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Orth (JIRA)" <>
Subject [jira] [Updated] (SUREFIRE-1575) Distribute tests ad-hoc across foks
Date Mon, 01 Oct 2018 11:40:00 GMT


Julian Orth updated SUREFIRE-1575:
    Summary: Distribute tests ad-hoc across foks  (was: Distribute Tests ad-hoc across foks)

> Distribute tests ad-hoc across foks
> -----------------------------------
>                 Key: SUREFIRE-1575
>                 URL:
>             Project: Maven Surefire
>          Issue Type: Improvement
>          Components: Maven Surefire Plugin
>    Affects Versions: 2.22.0
>            Reporter: Julian Orth
>            Priority: Minor
>              Labels: performance
> Hi,
> consider the case where surefire is configured with {{forkCount > 1}}. Currently the
distribution of classes across forks appears to work as follows:
> * Divide all included test classes in {{forkCount}} buckets and write each bucket to
a jar
> * Start {{forkCount}} JVMs, each with one of the jars as an argument
> * Have each JVM run the tests in its jar
> This can cause less than optimal test run times. For example:
> * If a significant number of tests is excluded via the {{groups}} mechanism, all but
one JVM might exit immediately, leaving the remaining JVM to execute all included tests.
> * If a large number of tests runs in a small amount of time and a small number of tests
consume almost 100% of the single-JVM run time, then these expensive tests might be assigned
to a single JVM.
> Therefore, I would like to suggest the following changes to the distribution process:
> * All {{forkCount}} JVMs are started with the same jar.
> * Whenever one of the forks wants to run a test class, it asks the master process for
the next test class name via some IPC mechanism. I assume such an IPC mechanism already exists
for sending _Running_ and _Tests run_ messages.
> * If there is another unrun test class, the master process sends the fully qualified
class name, otherwise it notifies the child that there are no more tests to run.
> * The child then exits if there are no more test classes or runs the test class.
> Via this mechanism, the test run time achieves the theoretically optimal time of {{sum(individual
test run times) / forkCount + (time of longest runnning test class)}}.
> I would be willing to implement this.
> Julian

This message was sent by Atlassian JIRA

View raw message