One thing we could do with some tests I know is to remove some of them.
EC currently runs the same test on multiple volume configurations (2+1,
3+1, 4+1, 3+2, 4+2, 4+3 and 8+4). I think we could reduce it to two common
configurations (2+1 and 4+2) and one or two special configurations (3+1
and/or 3+2). This will remove the biggest ones, that take most of the time,
while keeping the basic things still tested.
Xavi
On 3 November 2017 at 17:50, Amar Tumballi wrote:
> All,
>
> While we discussed many other things, we also discussed about reducing
> time taken for the regression jobs. As it stands now, it take around 5hr
> 40mins to complete a single run.
>
> There were many suggestions:
>
>
>- Run them in parallel (as each .t test is independent of each other)
>- Revisit the tests taking long time (20 tests take almost 6000
>seconds as of now).
>- See if we can run the tests in docker (but the issue is the machines
>we have are of 2cores, so there may not be much gain)
>
>
> There are other suggestions as well:
>
>
>- Spend effort and see if there are repeated steps, and merge the
>tests.
> - Most of the time is spent in starting the processes and cleaning
> up.
> - Most of the tests run the similar volume create command
> (depending on the volume type), and run few different type of I/O in
> different tests.
> - Try to see if these things can be merged.
> - Most of the bug-fix .t files belong to this category too.
>- Classify the tests specific to few non-overlapping volume types and
>depending on the changeset in the patch (based on the files changed) decide
>which are the groups to run.
> - For example, you can't have replicate and disperse volume type
> together.
>
>
>
>
> More ideas and suggestions welcome.
>
>
> Regards,
> Amar
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel
