+1 to reducing maxParallelForks. On 22 July 2014 at 12:28:24 am, Radim Kubacki (radim.kuba...@gradleware.com) wrote:
More observations: I've tried this today with my Windows and it seems that there is a big difference between maxParallelForks 3 and 4. The test consistently passes with 3 is lower value on my VMWare box with 6GB RAM and 2 CPUs. It also consistently fails with maxParallelForks=4. I know that our Windows machines and much better hardware but it seems that especially :launcher:integTest starts a lot of processes and probably hits some I/O threshold where things get noticeably slower. Reducing the throughput at this level seems better/more reliable to me than increasing various timeouts. My suggestion is to reduce maxParallelForks to 3. Possibly we can do it only for :launcher (and perhaps :toolingApi) where we have these tests that run multiple child processes per test. Other subprojects can live with current settings at the moment. Opinions? -Radim On Sun, Jul 20, 2014 at 9:29 PM, Radim Kubacki <radim.kuba...@gradleware.com> wrote: We have a few tests that are failing sporadically due to some timeouts: ToolingApiLoggingCrossVersionSpec."logging is live" is one of them. CancellingDaemonIntegrationSpec."cancels correct build" seem to fall into this category too. They fail more often on our Windows CI box and the failure are usual when there is higher CPU load. I added debug logging to see where the time is spent and here are some numbers (based on http://builds.gradle.org/viewLog.html?buildId=112016&tab=buildResultsDiv&buildTypeId=Gradle_Master_Coverage_WindowsJava18#testNameId1103271250747874825) Output starts at 22:05:08.897 and there will be some time before to spawn the process. Daemon setup ends at with '22:05:10.892 [INFO] [ org.gradle.launcher.daemon.server.exec.ExecuteBuild] Executing build with daemon context...' Then there is a gap 1.5s before '22:05:12.333 [INFO] [org.gradle.BuildLogger] Starting Build' Next chunk is '22:05:13.051 [DEBUG] [org.gradle.initialization.ScriptEvaluatingSettingsProcessor] Timing: Processing settings took: 0.669 secs' Another 1+s to get lock and write build script to a cache - 22:05:14.344 [DEBUG] [org.gradle.groovy.scripts.internal.DefaultScriptCompilationHandler] Timing: Writing script to cache at C:\tcagent2\work\2d33fa4c6d642769\intTestHomeDir\worker-1\caches\2.1-20140719192339+0000\scripts\build_td6v684jmvp2dj2md0b4vs8dr\ProjectScript\buildscript\classes took: 0.48 secs 3.5s to compile the build script is a biggest part - 22:05:17.864 [DEBUG] [org.gradle.groovy.scripts.internal.DefaultScriptCompilationHandler] Timing: Writing script to cache at C:\tcagent2\work\2d33fa4c6d642769\intTestHomeDir\worker-1\caches\2.1-20140719192339+0000\scripts\build_td6v684jmvp2dj2md0b4vs8dr\ProjectScript\no_buildscript\classes took: 3.482 secs Task is executed soon after (22:05:18.253 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter] Executing actions for task ':t1'.) but it is too late for the test that has 10secs timeout to read output from the test. My questions: Can we make the test faster? Like adding empty settings.gradle? Can we speed up script compilation? Do we know what is happening before '[org.gradle.BuildLogger] Starting Build'? Of course I can increase the timeout but before that I'd like to see why it is not sufficient in some cases. -Radim
