Сокращение использования памяти с помощью Symfony и моста PHPUnit
Начиная с Symfony 2.7, Symfony PHPUnit Bridge был создан как отличный способ получения уведомлений об устаревании из ваших тестов (см. соответствующая запись в блоге Symfony также). Как часть этого пакета, сборка мусора также была отключена, что, по-видимому, выводит из-под контроля объем памяти большого набора тестов.
Например, без моста:
Time: 5.01 minutes, Memory: 964.75Mb
OK, but incomplete, skipped, or risky tests!
Tests: 1189, Assertions: 2380, Incomplete: 2.
И тот же набор тестов с включенным мостом:
Time: 4.98 minutes, Memory: 3003.00Mb
OK, but incomplete, skipped, or risky tests!
Tests: 1189, Assertions: 2380, Incomplete: 2.
Remaining deprecation notices (9)
В документации отмечается, что удаление сборки мусора во время тестирования предназначено для уменьшения возникновения ошибок сегментации при определенных условиях, чего мы еще не испытывали.
Я понимаю, что мы могли бы просто повторно включить сборку мусора в нашем загрузочном файле PHPUnit для конкретного приложения, или мы могли бы также удалить мост из автозагрузчика и вручную зарегистрировать только обработчик устаревания. Тем не менее, меня больше интересует намерение, которое стоит за этим включением (и действительно, может быть, все, чего не хватает, так это некоторой документации о том, как избежать такого поведения).
Помимо этого, есть ли связанные изменения, которые мы должны внести в способ структурирования наших тестов, чтобы справиться с этим? Это набор тестов, который включает в себя множество полнофункциональных функциональных тестов и еще много чего. Кажется, что запуск без сборки мусора может нарушить многие большие тестовые наборы, если я что-то упустил.
Это в PHP 5.5.9, PHPUnit 4.7.7 и Symfony 2.7.3.
Решение
Код, где включена сборка мусора, также упоминает Ошибка в PHP, которую нужно избегать. Не существует никакого определенного кода, который бы мог легко и надежно заставить ошибку показать себя, и неясно, будут ли более свежие версии (в 5.6 и серии esp 7.0) защищены от этой проблемы.
Поворот gc может также ускорить скорость выполнения — по тем же причинам, что и с Composer — сборка мусора может занять значительное время.
Включите его снова в скриптах запуска, после того как он будет отключен в мосте, может помочь с памятью.
Я был бы более склонен выяснить, почему ваши тесты занимают так много памяти — посмотреть, сколько памяти используется до и после тестов, и очистить объекты, используемые в tearDown() функции могут многое сделать для очистки памяти.
Другие решения
Других решений пока нет …