Re: Concurrency support for run-tests
| From: | Michael Wallner | Date: | Thu, 10 Jul 2014 09:08:52 +0000 |
| Subject: | Re: Concurrency support for run-tests | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-75351@lists.php.net to get a copy of this message | ||
On Wed 09 Jul 2014 22:00:49 CEST, Stas Malyshev wrote:
> Hi!
>
>> Having thought a bit about the subject, the heuristic I came up with was to
>> 1) do not run tests from the same extension in parallel, and 2) do not run
>> tests from certain extensions in parallel (e.g., mysql and pdo_mysql).
Heuristics are not reliable enough.
> How about making it a whitelist? For tests/extensions we know it's easy
> to paralellize (like ones not having external dependencies/servers/etc)
> simple script could whitelist a lot of them. For those more tricky, we
> could whitelist them gradually.
>
Whitelists are very limitating by nature, nobody will go and add tests
to this whitelist, I think. I don't think a script is a viable way to
whitelist tests (think about all those tests with with includes or
config files, etc). Tests that fail due to concurrency will be easier
noticed and added to a concurrency group or even better be fixed.
I added a CONCURRENCY_GROUP section, see
https://github.com/m6w6/php-src/compare/parallel-run-tests?expand=1
If the next test to execute is in the same CONCURRENCY_GROUP as one
which is already/still running, it will be pushed back.
So tests with f.e. listening servers could use "port:9999" as
CONCURRENCY_GROUP or mysql tests could use "mysql:dbname", etc. As
example, I added the open_basedir tests to one group because they all
tamper around with the same subdirectories.
I also added a shuffle($test_files) if $concurrency is greater than 2
because that helps running the test suite concurrently actually.
Anybody got an idea why the tests are sorted at all?
--
Regards,
Mike