Comments 17
Еще из вариантов:
- Проверить что debug mode выключен (переменная окружения
APP_DEBUG=0
) - Для paratest хорошо проверить сколько у вас ядер на runner, и возможно поиграть с настройками (processes, functional)
+3
`APP_DEBUG` был включен, отключение сильно не повлияло. Думаю, это связано с тем что до этого явно отключил логирование в Doctrine.
По paratest: разные настройки крутил, но результат чуть лучше чем без него либо даже хуже в случае использования functional (в документации у них как раз сказано, что functional даже медленнее будет из-за накладных расходов). По ядрам: запускал с 2, 4 и 8.
А вот что помогло, это использование `--runner WrapperRunner`. Вышел за 2 минуты: `Time: 01:59.494`
По paratest: разные настройки крутил, но результат чуть лучше чем без него либо даже хуже в случае использования functional (в документации у них как раз сказано, что functional даже медленнее будет из-за накладных расходов). По ядрам: запускал с 2, 4 и 8.
А вот что помогло, это использование `--runner WrapperRunner`. Вышел за 2 минуты: `Time: 01:59.494`
0
У меня paratest стал давать прирост производительтности только начиная с нескольких тысяч тестов (сложно сравнивать, тесты у всех разные).
Не заметил, как вы запускаете БД для тестов. Я обычно поднимаю тестовый сервер в докере, причем data_dir монтируется в памяти (tmpfs: /var/lib/mysql/data — или где оно там лежит?). Прирост может быть значительный, иногда очень. Каждый тест в своей транзакции и ROLLBACK в конце — мастхэв, конечно (я видел, вы используете, здорово)
0
PHPUnit 9.0 умеет сам запускаться параллельно, попробуйте этот способ
+2
Жаль, что про xhprof или другие похожие методы профилирования Вы не упомянули. Обычно там много интересного находится, если Вы туда регулярно не смотрите :).
+2
Еще помогает в ускорении — тюнинг базы. Например, если у вас postgres, то можно отключить WAL.
0
не сильно связано с php, скорее больше со структурой.
Если у вас есть прямые callы в БД, то их лучше по возможности заменить на REST запросы.
по поводу параллельного запуска, попробуйте увеличить/уменьшить количество параллельных потоков
+изменение базы, лишний столбец может увеличить время выполнения. Поиск по базе с помощью searchtype like, а не exact, тоже может увеличить время запроса, а значит и время выполнения в случае большого количества тестов.
Можно и с самими тестами играться, оптимизировать время их выполнения, можно делать не 15-20 ассертов в одном тесте, а один, но большой, на весь запрос или ответ. Все специфично от проекта.
Если у вас есть прямые callы в БД, то их лучше по возможности заменить на REST запросы.
по поводу параллельного запуска, попробуйте увеличить/уменьшить количество параллельных потоков
+изменение базы, лишний столбец может увеличить время выполнения. Поиск по базе с помощью searchtype like, а не exact, тоже может увеличить время запроса, а значит и время выполнения в случае большого количества тестов.
Можно и с самими тестами играться, оптимизировать время их выполнения, можно делать не 15-20 ассертов в одном тесте, а один, но большой, на весь запрос или ответ. Все специфично от проекта.
+1
Совет, на случай, если вы запускаете свои тесты в Docker-окружении:
Можете создать дополнительный контейнер, в котором не будет модуля xDebug вовсе — это позволит ускорить выполнение тестов еще, как минимум, в 2 раза.
Объяснение: простое отключение xDebug через конфигурацию — гораздо менее эффективно по сравнению с отсутствием модуля в системе.
Можете создать дополнительный контейнер, в котором не будет модуля xDebug вовсе — это позволит ускорить выполнение тестов еще, как минимум, в 2 раза.
Объяснение: простое отключение xDebug через конфигурацию — гораздо менее эффективно по сравнению с отсутствием модуля в системе.
0
Мне ускорить тесты так же помогло отключение сборщика мусора. Но в этом случае конечно же должно быть достаточно свободной памяти.
0
Sign up to leave a comment.
Беги, PHPUnit, беги: как я оптимизировал время выполнения тестов