Pull to refresh

Comments 17

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

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

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

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

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


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

PHPUnit 9.0 умеет сам запускаться параллельно, попробуйте этот способ
В документации не смог найти такой опции. Если скинете ссылку, то опробую.
--process-isolation         Run each test in a separate PHP process

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

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


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

Да, с паролями получилось лучше всего. `textplain` vs `md5` практически одинаков, около 1-3 секунд разница
Жаль, что про xhprof или другие похожие методы профилирования Вы не упомянули. Обычно там много интересного находится, если Вы туда регулярно не смотрите :).
Отличная идея, постараюсь в свободное время поисследовать
Еще помогает в ускорении — тюнинг базы. Например, если у вас postgres, то можно отключить WAL.
Можно больше деталей про то, как это сделать? Из того что удалось найти, пишут что WAL невозможно отключить.
fsync = off
full_page_writes = off


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

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

Sign up to leave a comment.

Articles