Беги, PHPUnit, беги: как я оптимизировал время выполнения тестов

[theRavel]

Еще из вариантов:

1. Проверить что debug mode выключен (переменная окружения APP_DEBUG=0)
2. Для paratest хорошо проверить сколько у вас ядер на runner, и возможно поиграть с настройками (processes, functional)

[parshinpn]

`APP_DEBUG` был включен, отключение сильно не повлияло. Думаю, это связано с тем что до этого явно отключил логирование в Doctrine.

По paratest: разные настройки крутил, но результат чуть лучше чем без него либо даже хуже в случае использования functional (в документации у них как раз сказано, что functional даже медленнее будет из-за накладных расходов). По ядрам: запускал с 2, 4 и 8.

А вот что помогло, это использование `--runner WrapperRunner`. Вышел за 2 минуты: `Time: 01:59.494`

[crocodile2u]

У меня paratest стал давать прирост производительтности только начиная с нескольких тысяч тестов (сложно сравнивать, тесты у всех разные).

Не заметил, как вы запускаете БД для тестов. Я обычно поднимаю тестовый сервер в докере, причем data_dir монтируется в памяти (tmpfs: /var/lib/mysql/data — или где оно там лежит?). Прирост может быть значительный, иногда очень. Каждый тест в своей транзакции и ROLLBACK в конце — мастхэв, конечно (я видел, вы используете, здорово)

[xEpozZ]

PHPUnit 9.0 умеет сам запускаться параллельно, попробуйте этот способ

[parshinpn]

В документации не смог найти такой опции. Если скинете ссылку, то опробую.

[crocodile2u]

--process-isolation         Run each test in a separate PHP process

Вы это имеете в виду? Я не уверен, что это то же самое.

[trawl]

Т.е. самый большой прирост вы получили от снижения криптографии паролей.

Если копнуть в эту же сторону, можно вообще вместо md5 использовать textplain и получить ещё кое-какой прирост.

[parshinpn]

Да, с паролями получилось лучше всего. `textplain` vs `md5` практически одинаков, около 1-3 секунд разница

[youROCK]

Жаль, что про xhprof или другие похожие методы профилирования Вы не упомянули. Обычно там много интересного находится, если Вы туда регулярно не смотрите :).

[parshinpn]

Отличная идея, постараюсь в свободное время поисследовать

[m0ody]

Еще помогает в ускорении — тюнинг базы. Например, если у вас postgres, то можно отключить WAL.

[madmis]

Можно больше деталей про то, как это сделать? Из того что удалось найти, пишут что WAL невозможно отключить.

[m0ody]

fsync = off
full_page_writes = off


Имел ввиду все таки не wal, а fsync
Естественно отключать нужно только для тестового кластера.

[madmis]

Благодарю. Обязательно попробую.

[ValikSirbik]

не сильно связано с php, скорее больше со структурой.
Если у вас есть прямые callы в БД, то их лучше по возможности заменить на REST запросы.
по поводу параллельного запуска, попробуйте увеличить/уменьшить количество параллельных потоков
+изменение базы, лишний столбец может увеличить время выполнения. Поиск по базе с помощью searchtype like, а не exact, тоже может увеличить время запроса, а значит и время выполнения в случае большого количества тестов.
Можно и с самими тестами играться, оптимизировать время их выполнения, можно делать не 15-20 ассертов в одном тесте, а один, но большой, на весь запрос или ответ. Все специфично от проекта.

[iTearo]

Совет, на случай, если вы запускаете свои тесты в Docker-окружении:
Можете создать дополнительный контейнер, в котором не будет модуля xDebug вовсе — это позволит ускорить выполнение тестов еще, как минимум, в 2 раза.
Объяснение: простое отключение xDebug через конфигурацию — гораздо менее эффективно по сравнению с отсутствием модуля в системе.

[magicdevel]

Мне ускорить тесты так же помогло отключение сборщика мусора. Но в этом случае конечно же должно быть достаточно свободной памяти.