
<html><body><p>Matthew, this helps tremendously. As you can tell the conclusion I was heading towards was not accurate.<br><br>Now to look a bit deeper.<br><br>Thanks,<br><br>Bob Hansen<br>z/VM OpenStack Enablement <br><br><tt>Matthew Treinish <mtreinish@kortar.org> wrote on 09/21/2016 11:07:04 AM:<br><br>> From: Matthew Treinish <mtreinish@kortar.org></tt><br><tt>> To: "OpenStack Development Mailing List (not for usage questions)" <br>> <openstack-dev@lists.openstack.org></tt><br><tt>> Date: 09/21/2016 11:09 AM</tt><br><tt>> Subject: Re: [openstack-dev] [tempest]Tempest test concurrency</tt><br><tt>> <br>> On Wed, Sep 21, 2016 at 10:44:51AM -0400, Bob Hansen wrote:<br>> > <br>> > <br>> > I have been looking at some of the stackviz output as I'm trying to improve<br>> > the run time of my thrid-party CI. As an example:<br>> > <br>> > <a href="http://logs.openstack.org/36/371836/1/check/gate-tempest-dsvm-">http://logs.openstack.org/36/371836/1/check/gate-tempest-dsvm-</a><br>> full-ubuntu-xenial/087db0f/logs/stackviz/#/stdin/timeline<br>> > <br>> > What jumps out is the amount of time that each worker is not running any<br>> > tests. I would have expected quite a bit more concurrecy between the two<br>> > workers in the chart, e.g. more overlap. I've noticed a simliar thing with<br>> > my test runs using 4 workers.<br>> <br>> So the gaps between tests aren't actually wait time, the workers aresaturated<br>> doing stuff during a run. Those gaps are missing data in the subunit streams<br>> that are used as the soure of the data for rendering those timelines. The gaps<br>> are where things like setUp, setUpClass, tearDown, tearDownClass, and<br>> addCleanups which are not added to the subunit stream. It's just an <br>> artifact of<br>> the incomplete data, not bad scheduling. This also means that testr does not<br>> take into account any of the missing timing when it makes decisions based on<br>> previous runs.<br>> <br>> > <br>> > Can anyone explain why this is and where can I find out more information<br>> > about the scheduler and what information it is using to decide when to<br>> > dispatch tests? I'm already feeding my system a prior subunit stream to<br>> > help influence the scheduler as my test run times are different due to the<br>> > way our openstack implementation is architected. A simple round-robin<br>> > approach is not the most efficeint in my case.<br>> <br>> If you're curious about how testr does scheduling most of that happens here:<br>> <br>> <a href="https://github.com/testing-cabal/testrepository/blob/master/">https://github.com/testing-cabal/testrepository/blob/master/</a><br>> testrepository/testcommand.py<br>> <br>> One thing to remember is that testr isn't actually a test runner, it's a test<br>> runner runner. It partitions the tests based on time information and passes<br>> those to (multiple) test runner workers. The actual order of execution inside<br>> those partitions is handled by the test runner itself. (in our case <br>> subunit.run)<br>> <br>> -Matt Treinish<br>> [attachment "signature.asc" deleted by Bob Hansen/Endicott/IBM] <br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></tt><BR>

</body></html>