Thanks Mike. Answers/ comments in-line below > [junit4] Slave 16: 0.29 .. 24.65 = 24.36s > [junit4] Slave 17: 0.36 .. 30.62 = 30.26s > [junit4] Slave 18: 0.44 .. 30.84 = 30.41s > [junit4] Slave 19: 0.50 .. 28.65 = 28.15s > [junit4] Execution time total: 36.69s > [junit4] Tests summary: 278 suites, 1550 tests, 3 ignored
I forgot how nasty your beast computer is... 20 slaves?! Remind me how many actual (real) cores do you have? Did you experiment with different slave numbers? I ask because I noticed that: 1) it makes little sense to run cpu-intense tests on hyper-cores, doesn't yield much if anything, 2) you should leave some room for system vm threads (GC, compilers); the more VMs, the more room you'll need. > Does the "Execution time total" include compilation, or is it just the > actual test runtime? The total is calculated before slave VMs are launched and after they complete, so even launch time is included. It's here: https://github.com/carrotsearch/randomizedtesting/blob/master/ant-junit4/src/main/java/com/carrotsearch/ant/tasks/junit4/JUnit4.java > Can this change run "across" the different groups of tests we have > (core, modules/*, contrib/*, solr/*, etc.)? I found that to be a > major bottleneck in the current "ant test"'s concurrency, ie we have a > pinch point after each group of tests (must wait for all JVMs to > finish before moving on to next group...), but I think fixing that in > ant is going to be hard? If I understand you correctly the problem is that ANT in Lucene/ Solr is calling to sub-module ANT scripts and these in turn invoke the test macro. So running everything from a single test task would be possible if we had a master-level test script, it's not directly related to how the tests are actually executed. That JUnit4 task supports globbing in suite selectors so it could be executed with, say, -Dtests.class=org.apache.lucene.blah.* to restrict tests to run just a certain section of all tests, but include everything by default. Don't know how it affects modularization though -- the tests will run faster but they'll be more difficult to maintain I guess. > When I use the hacked up Python test runner (runAllTests.py in luceneutil), This was my inspiration -- Robert pointed me at that, very helpful although you need your kind of machine to run so many SSH sessions :D > change (balancing the tests across JVMs). BUT: that's on current > trunk, vs your git clone which is somewhat old by now... so it's an > apples/pears comparison ;) Oh, come on, my fork is only a few days behind! :) I've pulled the current trunk and merged. I'd appreciate if you could re-run again, this time with, say, 5, 10, 15 and 20 threads. I wonder what the speedup/ overhead is. Thanks. Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
