> With the Python runner I see these run times on just lucene core tests: > 2 cpus: 72.2 sec 5 cpus: 35.0 sec 10 cpus: 28.1 sec 15 cpus: > 26.2 sec 20 cpus: 26.0 sec 25 cpus: 27.5 sec
I would say this is aligned with my intuition -- after you exceed the physical number of cores things don't speed up anymore. > 10 cpus: 88.3 sec 15 cpus: 80.2 sec 20 cpus: 77.4 sec 25 cpus: 76.7 sec > The above were just running on beast, but the Python runner can This is probably because some tests don't add anything to CPU load (they're disk bound or use the network)? The speedup is also not that significant -- adding 15 cpus only yielded about 10 secs. > Hmm so does that include compile time (my numbers don't)? Sounds > likeno? I'm also measuring from first launch to last finish. Oh, you mean ANT compile/ execution time before actual testing? No, I don't include that -- the execution time is actual spawned jvms. > Yes I think that's the problem! > Ideally ant would just gather up all "jobs" to run and then > we'daggregate/distribute across JVMs. Could be done by emitting test class/ classpath names from each module and then running a final testing task that would execute whatever was appended to the current run... but it seems clumsy to me, don't know how to do it better though. > tochange the JVM settings (eg CLASSPATH) per test module we havetoday > so we must make separate modules for that...? Yeah, that would be one thing -- different classpaths/ vm properties etc. This could be problematic. > I re-ran above -- looks like the times came down some so the new > antrunner is basically the same as the Python runner (on core tests): > great! Thanks. I'm still working on the rough edges (like reporting a jvm crash, there were problems with ibm j9) and Stanislaw is preparing a nice(r) test report. We will contribute a patch once this is done and if there is interest we would love to contribute this in. Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
