Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

feat: Introduced additonal parallelism to the test suite execution #204

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

feat: Introduced additonal parallelism to the test suite execution #204

wants to merge 3 commits into from

Conversation

MatousJobanek
Copy link
Contributor

  • the test-bed build uses Maven parallelism with 50 threads per cpu core
  • the same is used for build invocation on Travis (could be used locally)
  • the Travis is building in three virtual machines at once:
    • one for unit tests
    • one for functional tests - to separate unit tests and functional tests I had to introduce two profiles inside of the pom files
    • one for generating documentation - no to do it in the previous builds/vm twice
  • speeding up Java startup using properties: -XX:+TieredCompilation -XX:TieredStopAtLevel=1

Fixes #126

@lordofthejars
Copy link
Member

lordofthejars commented Oct 3, 2017 via email

@MatousJobanek MatousJobanek mentioned this pull request Oct 3, 2017
Merged
@MatousJobanek
Copy link
Contributor Author

yup - they are different solutions => separated PRs.
Yours is important as well - to minimize the test suite

@MatousJobanek MatousJobanek mentioned this pull request Oct 4, 2017
Open
bartoszmajsak
bartoszmajsak reviewed Oct 5, 2017
View reviewed changes
Copy link
Member

@bartoszmajsak bartoszmajsak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not a huge fan of having multiple profiles - ideally I would prefer to have the same command used everywhere. On the other hand if we gain a lot by splitting execution to 3 parallel builds, even after #203, then let's go with it.

Maybe some brief explanation about why certain profiles exist (in the poms) would help us in the future to remember.

@MatousJobanek
Copy link
Contributor Author

MatousJobanek commented Oct 6, 2017 •
edited
Loading

Yeah, I'm not a huge fan of profiles either so I completely understand your point/feeling.
On the other hand, I would really welcome a simple way of executing only unit tests - just an example of the practical usage on the command line.
In addition, there is no change of the usage - you can still use the original standard command of building/testing the whole project.
Anyway, I'll rebase it with the latest changes, compare the time and if there is an improvement in the build time, then I'll add the explanation and finish the PR.

  • rebase
  • compare the build time
  • add documentation explanation

@bartoszmajsak
Copy link
Member

I would really welcome a simple way of executing only unit tests - just an example of the practical usage on the command line.

mvn test won't work here?

@MatousJobanek
Copy link
Contributor Author

mvn test won't work here?

nope, that will execute the whole test suite

@MatousJobanek
Copy link
Contributor Author

This brings an interesting question. How about removing the profiles and configure the failsafe plugin for functional tests? Then it would be possible to run only unit tests using mvn clean test, we could still have separated builds in Travis and we would get rid of the profiles...

@MatousJobanek MatousJobanek force-pushed the travis branch 3 times, most recently from 52d5817 to 5f9bcfb Compare October 11, 2017 19:38
@MatousJobanek
feat: Introduced additonal parallelism to the test suite execution
e960b4c 
* the test-bed build uses Maven parallelism with 50 threads per cpu core
* the same is used for build invocation on Travis (could be used locally)
* the Travis is building in three virtual machines at once:
  * one for unit tests
  * one for functional tests - to separate unit tests and functional tests I had to introduce two profiles inside of the pom files
  * one for generating documentation - no to do it in the previous builds/vm twice
* speeding up Java startup using properties: -XX:+TieredCompilation -XX:TieredStopAtLevel=1
@MatousJobanek
changed order of the suite execution
cca1c28
@MatousJobanek
cleanup
206e71d
@MatousJobanek
Copy link
Contributor Author

The build times are pretty weird - in my Travis account, the build takes 15:41 but here on arquillian's 19:17
Similarly look also the Maven builds of the project:
on my travis account 13:53
on Arquillian's account 17:26
The differences are quite huge and seem to be stable. Any idea what could be the cause? How about your accounts? Are they also faster? @bartoszmajsak @lordofthejars @hemanik @dipak-pawar

@bartoszmajsak
Copy link
Member

This brings an interesting question. How about removing the profiles and configure the failsafe plugin for functional tests? Then it would be possible to run only unit tests using mvn clean test, we could still have separated builds in Travis and we would get rid of the profiles...

That's exactly what was the bottom line of my short question :)

@bartoszmajsak
Copy link
Member

bartoszmajsak commented Oct 18, 2017 •
edited
Loading

The build times are pretty weird

Could that be that there are other projects under arq organization which had running builds at the same time? Might be that we have resources constraints per organization on Travis.

I would simply measure against one of the places - preferably most isolated one - to compare before/after time.

@bartoszmajsak
Copy link
Member

What do we do with this work @MatousJobanek ?

@MatousJobanek
Copy link
Contributor Author

I'll park it for a while and return back to it when I have time

@bartoszmajsak bartoszmajsak reopened this Oct 27, 2017
@bartoszmajsak
Copy link
Member

I re-opened and added "on hold" label so we won't miss it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@bartoszmajsak bartoszmajsak bartoszmajsak left review comments

@lordofthejars lordofthejars Awaiting requested review from lordofthejars

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
Status: On Hold Status: Work In Progress
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@MatousJobanek @lordofthejars @bartoszmajsak