[
https://jira.codehaus.org/browse/SUREFIRE-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338071#comment-338071
]
Tibor Digana edited comment on SUREFIRE-1048 at 1/4/14 3:21 AM:
----------------------------------------------------------------
Yes it can be closed.
The user should hava a chance to change the performance of the build using
these params. The same params are used to express that e.g. methods do not have
any explicitly defined thread-count.
For instance in version 2.16 if parallel=all, threadCount=16 and
threadCountSuites=2, threadCountClasses=5, where threadCountMethods is left
unspecified, then concurrency of methods is varying between 9 - 14 or 15. The
same may happen with classes if parallel=suitesAndClasses in 2.17.
If you specify the ratio e.g. 10%-20%-70% per every entity of param "parallel"
then the only parameter which is mostly used in performance tuning is
threadCount.
There are two new parameters of timeout in this parallelism.
was (Author: tibor17):
Yes it can be closed.
The user should hava a chance to change the performance of the build using
these params. The same params are used to express that e.g. methods do not have
any explicitly defined thread-count.
For instance in version 2.16 if parallel=all, threadCount=16 and
threadCountSuites=2, threadCountClasses=5, where threadCountMethods is left
unspecified, then concurrency of methods is varying between 9 - 14 or 15. The
same may happen with classes if parallel=suitesAndClasses in 2.17.
If you specify the ration e.g. 10%-20%-70% per every entity of param "parallel"
then the only parameter which is mostly used in performance tuning is
threadCount.
There are two new parameters of timeout in this parallelism.
> Surefire does not use the total amount of threads specified by threadCount
> --------------------------------------------------------------------------
>
> Key: SUREFIRE-1048
> URL: https://jira.codehaus.org/browse/SUREFIRE-1048
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
> Affects Versions: 2.16
> Reporter: Fabio Kenji Kume
> Attachments: surefire-parallel-test.zip
>
>
> Hello,
> We've been using Surefire Plugin's parallel settings since 2.16 in order to
> run our selenium-based integration tests.
> The way we run it is by using the following parameters:
> parallel='all', perCoreThreadCount=false, threadCount=20,
> useUnlimitedThreads=false, threadCountSuites=0, threadCountClasses=0,
> threadCountMethods=0
> We are running a Junit Suite using Categories. What we've noticed, though, is
> that even if we specify the total thread count as 20, we never see that
> number of tests being run in parallel. We could check that fact by viewing
> our selenium-grid's console, where we would see that the number of selenium
> grid nodes that were being used for tests were never the full 20.
> We've played around with different threadCount numbers and got the following
> results:
> threadCount / slots being used at selenium-grid
> 3 / 1
> 4 / 2
> 5 / 3
> 6 / 3
> 7 / 4
> 8 / 5
> 9 / 5
> 10 / 6
> 11 / 7
> 13 / 8
> It seems the number of threads being used is never the total of threads
> specified.
> I've created another project so I could test this around, which is attached
> to this issue.
> In it, I've created a Junit rule that will print the whenever a test starts,
> and a Test Suite using categories from another testcase.
> When I run it using threadCount = 10, I get the following:
> mvn clean test -Dtest=**/ExpSuite.java
> reports
> [INFO] parallel='all', perCoreThreadCount=false, threadCount=10,
> useUnlimitedThreads=false, threadCountSuites=0, threadCountClasses=0,
> threadCountMethods=0
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running second.ExpTest
> [Mon Dec 23 16:11:15 BRST 2013] START test_1
> [Mon Dec 23 16:11:15 BRST 2013] START test_7
> [Mon Dec 23 16:11:15 BRST 2013] START test_6
> [Mon Dec 23 16:11:15 BRST 2013] START test_3
> [Mon Dec 23 16:11:15 BRST 2013] START test_5
> [Mon Dec 23 16:11:15 BRST 2013] START test_10
> [Mon Dec 23 16:11:15 BRST 2013] START test_4
> [Mon Dec 23 16:11:15 BRST 2013] START test_2
> [Mon Dec 23 16:15:30 BRST 2013] START test_8
> [Mon Dec 23 16:15:32 BRST 2013] START test_9
> Seems that last two tests didn't get to run at the same time as the others,
> since they have very different date values. However, if I run them specifying
> the exact number of threadCountSuites, threadCountClasses and
> threadCountMethods, the tests run all in parallel:
> [INFO] parallel='all', perCoreThreadCount=false, threadCount=0,
> useUnlimitedThreads=false, threadCountSuites=10, threadCountClasses=10,
> threadCountMethods=10
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running second.ExpTest
> [Mon Dec 23 15:50:51 BRST 2013] START test_2
> [Mon Dec 23 15:50:51 BRST 2013] START test_7
> [Mon Dec 23 15:50:51 BRST 2013] START test_8
> [Mon Dec 23 15:50:51 BRST 2013] START test_9
> [Mon Dec 23 15:50:51 BRST 2013] START test_10
> [Mon Dec 23 15:50:51 BRST 2013] START test_1
> [Mon Dec 23 15:50:51 BRST 2013] START test_3
> [Mon Dec 23 15:50:51 BRST 2013] START test_4
> [Mon Dec 23 15:50:51 BRST 2013] START test_6
> [Mon Dec 23 15:50:51 BRST 2013] START test_5
> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3,320.712
> sec - in second.ExpTest
> If I try running only the test class (ExpTest), I get the following:
> mvn clean test -Dtest=**/ExpTest.java
> [INFO] parallel='all', perCoreThreadCount=false, threadCount=10,
> useUnlimitedThreads=false, threadCountSuites=0, threadCountClasses=0,
> threadCountMethods=0
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running second.ExpTest
> [Mon Dec 23 17:07:46 BRST 2013] START test_3
> [Mon Dec 23 17:07:46 BRST 2013] START test_8
> [Mon Dec 23 17:07:46 BRST 2013] START test_1
> [Mon Dec 23 17:07:46 BRST 2013] START test_2
> [Mon Dec 23 17:07:46 BRST 2013] START test_7
> [Mon Dec 23 17:07:46 BRST 2013] START test_6
> [Mon Dec 23 17:07:46 BRST 2013] START test_10
> [Mon Dec 23 17:07:46 BRST 2013] START test_5
> [Mon Dec 23 17:07:46 BRST 2013] START test_4
> [Mon Dec 23 17:12:37 BRST 2013] START test_9
> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2,710.144
> sec - in second.ExpTest
> We still didn't get the 10 threads to run.
> I've looked around the source code and it seems to be related to how surefire
> calculates the ratio of threads that should be allocated to run methods,
> suites and classes.
> Could you help me with this?
> Thank you,
> Fabio Kenji
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
