Nick, Would you like to file a ticket to track this?
I think the first baby step is to log the amount of time each test cases take. This is supposed to happen already (see the flag), but somehow the time are not showing. If you have some time to figure that out, that'd be great. https://github.com/apache/spark/blob/master/project/SparkBuild.scala#L350 On Fri, Aug 8, 2014 at 10:10 AM, Reynold Xin <r...@databricks.com> wrote: > ScalaTest actually has support for parallelization built-in. We can use > that. > > The main challenge is to make sure all the test suites can work in > parallel when running along side each other. > > > On Fri, Aug 8, 2014 at 9:47 AM, Ted Yu <yuzhih...@gmail.com> wrote: > >> How about using parallel execution feature of maven-surefire-plugin >> (assuming all the tests were made parallel friendly) ? >> >> >> http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html >> >> Cheers >> >> >> On Fri, Aug 8, 2014 at 9:14 AM, Sean Owen <so...@cloudera.com> wrote: >> >> > A common approach is to separate unit tests from integration tests. >> > Maven has support for this distinction. I'm not sure it helps a lot >> > though, since it only helps you to not run integration tests all the >> > time. But lots of Spark tests are integration-test-like and are >> > important to run to know a change works. >> > >> > I haven't heard of a plugin to run different test suites remotely on >> > many machines, but I would not be surprised if it exists. >> > >> > The Jenkins servers aren't CPU-bound as far as I can tell. It's that >> > the tests spend a lot of time waiting for bits to start up or >> > complete. That implies the existing tests could be sped up by just >> > running in parallel locally. I recall someone recently proposed this? >> > >> > And I think the problem with that is simply that some of the tests >> > collide with each other, by opening up the same port at the same time >> > for example. I know that kind of problem is being attacked even right >> > now. But if all the tests were made parallel friendly, I imagine >> > parallelism could be enabled and speed up builds greatly without any >> > remote machines. >> > >> > >> > On Fri, Aug 8, 2014 at 5:01 PM, Nicholas Chammas >> > <nicholas.cham...@gmail.com> wrote: >> > > Howdy, >> > > >> > > Do we think it's both feasible and worthwhile to invest in getting our >> > unit >> > > tests to finish in under 5 minutes (or something similarly brief) when >> > run >> > > by Jenkins? >> > > >> > > Unit tests currently seem to take anywhere from 30 min to 2 hours. As >> > > people add more tests, I imagine this time will only grow. I think it >> > would >> > > be better for both contributors and reviewers if they didn't have to >> wait >> > > so long for test results; PR reviews would be shorter, if nothing >> else. >> > > >> > > I don't know how how this is normally done, but maybe it wouldn't be >> too >> > > much work to get a test cycle to feel lighter. >> > > >> > > Most unit tests are independent and can be run concurrently, right? >> Would >> > > it make sense to build a given patch on many servers at once and send >> > > disjoint sets of unit tests to each? >> > > >> > > I'd be interested in working on something like that if possible (and >> > > sensible). >> > > >> > > Nick >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org >> > For additional commands, e-mail: dev-h...@spark.apache.org >> > >> > >> > >
