Using Doctrine entities as Module arguments causes memory leaks
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 2/5
- Geschätzter Aufwand
- 1-3 Stunden
- Anfängerfreundlichkeit
- 45/100
- Issue-Typ
- Dokumentation
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- php
- Bereich
- databases, documentation
Rechercherichtung
Beginne damit, die Dokumentation des Doctrine-Moduls und den Abschnitt zu finden, der die Argumente von Modulmethoden oder die Einrichtung von Fixtures beschreibt. Füge eine Warnung hinzu, dass Doctrine-Entitäten persistente Collections und Entity Managers behalten können, wenn sie als Argumente gespeichert werden, und empfehle, wo angemessen skalare Daten zu verwenden; fertig ist die Aufgabe, wenn der Hinweis klar dokumentiert ist.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Background:
We have a fairly big project using Codeception. Recently, the memory usage during tests reached around ~2 GB of memory, resulting in exceeding the limit on CI test runs.
We have managed to pin down the issue to the fact that we were using Doctrine entities as arguments in a lot of module methods when creating fixture data.
The problem stems from persistent collections - all of them have Entity Manager injected into them and Codeception stores all arguments used in module methods. This caused the old instances of entity manager service not being cleared up and memory usage steadily piling up.
We were not using the Doctrine module, since it was too troublesome due to the persistent EntityManager service.
Solution:
The only way to correctly resolve it was to use scalar data instead of full entities. This has drastically reduced memory usage.
This is not something that I would expect the Codeception team to resolve, but I think that in the section of the Doctrine module you could provide a paragraph or two warning people about this issue. It can save someone folks a lot of work.
Cheers
- Vorherrschende Sprache
- PHP
- Sterne
- 4
- Forks
- 2
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus Codeception/module-doctrine
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 38/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 30/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
Codeception/module-doctrine#2 · 1 Kommentar · 1 Reaktion ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 42/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 64/100
Codeception/module-doctrine#6 · 1 Kommentar ·
Alle Issues in Codeception/module-doctrine
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
Maintainer antworten meist innerhalb von 1 Tag
-
Awaiting Triage bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
Maintainer antworten meist innerhalb von 1 Tag
-
product / databases
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
VilnaCRM-Org/user-service#525 ·
Maintainer antworten meist innerhalb von 21 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
shukiv/jabali-panel#2029 ·
Maintainer antworten meist innerhalb von 1 Tag