Reduzieren der Speicherauslastung mit Symfony und der PHPUnit-Bridge

Question

Ab Symfony 2.7 wurde die Symfony PHPUnit Bridge als hervorragende Möglichkeit erstellt, um Hinweise auf Verwarnungen aus Ihren Tests zu erhalten (siehe auch associated Symfony blog entry). Als Teil dieses Pakets wurde die Speicherbereinigung ebenfalls deaktiviert, wodurch der Speicherbedarf einer großen Testsuite außer Kontrolle geraten könnte.

Zum Beispiel, ohne die Brücke:

Time: 5.01 minutes, Memory: 964.75Mb 

OK, but incomplete, skipped, or risky tests! 
Tests: 1189, Assertions: 2380, Incomplete: 2. 

und die gleichen Testsuite mit der Brücke aktiviert:

Time: 4.98 minutes, Memory: 3003.00Mb 

OK, but incomplete, skipped, or risky tests! 
Tests: 1189, Assertions: 2380, Incomplete: 2. 

Remaining deprecation notices (9) 

In der Dokumentation wird darauf hingewiesen, dass die Beseitigung der Abfallsammlung während des Testens soll das Auftreten von Segmentierungsfehlern unter bestimmten Bedingungen reduzieren, was wir noch nicht erlebt haben.

Ich weiß, dass wir Garbage Collection in unserer anwendungsspezifischen PHPUnit-Bootstrap-Datei einfach reaktivieren könnten, oder wir könnten auch die Bridge aus dem Auto-Loader entfernen und manuell nur den Deprecation-Handler registrieren. Ich interessiere mich jedoch mehr für die Absicht, die hinter dieser Inklusion steht (und wirklich, vielleicht fehlt lediglich eine Dokumentation darüber, wie man dieses Verhalten vermeiden kann).

Abgesehen davon, gibt es eine damit verbundene Änderung, die wir machen müssen, wie wir unsere Tests strukturieren, um damit umzugehen? Dies ist eine Testsuite, die viele Full-Stack-Funktionstests enthält und so weiter. Es scheint, als würde das Laufen ohne Müllsammlung viele große Testsuiten zerstören, es sei denn, ich verpasse etwas.

Dies ist unter PHP 5.5.9, PHPUnit 4.7.7 und Symfony 2.7.3.

Answer 1

Der Code, wo die Garbage Collection gedreht wird, erwähnt auch die PHP bug that it is set to avoid. Es existiert kein definitiver Code, um den Fehler einfach und zuverlässig zu zeigen, und es ist nicht klar, ob neuere Versionen (in der 5.6- und der esp 7.0-Serie) immun gegen das Problem wären.

Drehen von GC, kann auch die Geschwindigkeit beschleunigen den Lauf - aus genau den gleichen Gründen wie das, was mit Composer passiert ist - Garbage Collection kann eine erhebliche Menge an Zeit dauern.

Wenn Sie diese Option in Ihren Startskripten wieder aktivieren, nachdem sie in der Bridge deaktiviert wurde, kann dies mit dem Arbeitsspeicher helfen.

Ich wäre eher geneigt, herauszufinden, warum Ihre Tests so viel Speicher benötigen - zu sehen, wie viel Speicher vor und nach Tests verwendet wird, und das Löschen der Objekte in den tearDown() Funktionen könnte viel Speicher löschen.