Having more output will slow stuff down. However, that is not the main issue.
I had pointed out before various testability issues with ATS. We have a number of tests that have to wait for an amount of time for the test to work. These delays are absolute, in that we have to wait the full time given. These delays add up. fast. one test with 3 20 sec delays means one minute. much of that time probably is not needed, and if the test could react to a state correctly then the test would run faster. This is the low hanging fruit that exists today. From there other items could be done or found to speed up the total time for the build. However I would push first on making sure states we want to test are detectable, and race issues ( cough cough log files) the delay resolution of information get optimized. There are a number of knobs in autest to control shutdown and startup times, however, these all (I believe all is the case) are reactive on a state of the process which we can test for quickly. I should have already tweaked these in the setup.cli.ext file. On Fri, Feb 1, 2019 at 1:58 PM Miles Libbey <mlib...@apache.org> wrote: > Since we have no data what is taking time to run the suite of tests, > isn't it premature to be considering optimizations that may or may not > affect the time? > > miles > > On Fri, Feb 1, 2019 at 11:36 AM Walt Karas > <wka...@verizonmedia.com.invalid> wrote: > > > > Pushkar pointed out to me the link to get the _sanbox for Au tests run > > by CI checks: https://ci.trafficserver.apache.org/autest/ > > > > The availability of the _sandbox means we can see trace debug output > > if the test configures ATS to generate it. But enabling this output > > will cause some increase in the time to run all the tests, which is > > becoming an issue. What does everyone think, to trace or not to trace > > in the merged versions of the Au tests? >
