Repository navigation
Improve ValidatesRunner performance. Parallelize runs - #40292
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #40292 +/- ##
============================================
+ Coverage 56.14% 58.57% +2.42%
- Complexity 2288 13739 +11451
============================================
Files 1121 2579 +1458
Lines 177152 270095 +92943
Branches 1488 11172 +9684
============================================
+ Hits 99467 158205 +58738
- Misses 75161 105890 +30729
- Partials 2524 6000 +3476
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Assigning reviewers: R: @chamikaramj for label java. This pull request likely touches a core component ("core" label). Please review with scrutiny. Note: If you would like to opt out of this review, comment Available commands:
The PR bot will only process comments in the main thread (not review comments). |
e2ae93f to
f4d293b
Compare
|
Note: Java ValidatesRunner finished in about 1hr. About 15 minutes of that was compilation time (it appears our remote build cache is not working). The actual test suite finished in about 45 minutes - a significant improvement from 6 hours! |
kennknowles
left a comment
There was a problem hiding this comment.
The implementation of the runner has some classic coding agent stuff, like being overspecified (specialized to ValidatesRunner as opposed to just general) and doing things in sort of a too-literal / not abstract enough way, but it works and helps right now and we can improve it if we need to. It does not have major readability issues so it is OK.
|
@kennknowles it isn't specialized to ValidatesRunner - the only specialization is that there is ValidatesRunner-specific parallelism, because I wanted the ability to configure a different parallelism for NeedsRunner tests. |
Large test classes ParDoTest$StateTests, PAssertTest, MapViewTest, ViewTest, ParDoTest$TimerTests, SplittableDoFnTest executed their @test methods 1-at-a-time on their assigned Gradle worker, spending >99% of their time blocked in waitUntilFinish() polling remote Dataflow jobs. Gradle4 does not natively parallelize tests within a test class.
Fix:
BeamParallelJunit4Runner: A JUnit 4 runner extending BlockJUnit4ClassRunner that dispatches @test methods within a class concurrently onto a shared fixed thread pool per worker JVM, with independent parallelism controls for
ValidatesRunnervs. other tests. For now we modify only ValidatesRunner tests to use this, but in the future we can extend to more test suites.A small number of tests were unsafe for parallel execution. Some of them were fixable (e.g. use of a static HashMap which we replaced with a ConcurrentHashMap). Others are fundamentally unsafe (e.g. any test that checks for specific log entries), and those have been marked with the SerialTest annotation to prevent parallelizing them.