Composer RAM-Fresser

[BugBuster]

Ich bin erstaunt, dass das bei uberspace funktioniert:

[9.1MB/0.13s] Loading composer repositories with package information
[9.5MB/0.38s] Updating dependencies (including require-dev)
[566.6MB/28.96s]   - Removing bugbuster/integrity_check (3.5.14)
[566.6MB/29.03s]   - Installing bugbuster/integrity_check (3.5.15)
[566.8MB/29.03s]     Downloading
[566.9MB/31.07s] 
[566.9MB/31.18s]   - installed 52 files
[191.3MB/33.27s] Writing lock file
[191.3MB/33.27s] Generating autoload files
[191.5MB/34.86s] Runonce created with 1 updates
[191.5MB/34.86s] Clean contao internal config cache
[191.5MB/34.92s] Clean contao internal dca cache
[191.5MB/34.98s] Clean contao internal language cache
[191.5MB/35.03s] Clean contao internal sql cache
[191.9MB/35.28s] Memory usage: 191.92MB (peak: 567.98MB), time: 35.28s

566MB um eine Erweiterung zu aktualisieren? Ja, ich weiß, der prüft auch alle anderen Pakete und Abhängigkeiten.
Aber meine Güte, vor einem Monat waren es noch ~200 MB, das wird ja immer mehr, ohne das ich weitere Erweiterungen installiert habe.

Langsam tendiere ich auch zu der Meinung: "Das kannste schon so machen, aber dann isses halt kacke...".

[Spooky]

Manchmal geht das auch über 1GiB, wenn Symfony involviert ist.

[tab]

Grauenhaft. Aber ich denke mal, das Problem ist bekannt und es wird bestimmt bereits an praktikablen Lösungen gearbeitet. Composer mit einem derartigen RAM-Verbrauch auf dem Webserver laufen zu lassen, ist jedenfalls keine. Oder sie beschränkt jedenfalls die Verwendbarkeit von Contao dramatisch, indem sie sehr hohe Anforderungen an den Webserver/Webspace stellt. Und spätestens wenn Symfony ins Spiel kommt, gibt es für die denkbaren Anforderungen mit der momentanen Lösung keine obere Grenze. Die können morgen oder übermorgen auch bei 16GB liegen, oder 128GB, oder ... Da kann dann theoretisch sehr schnell auch der Desktop-Rechner mal nicht mehr reichen, um das Optimierungsproblem zu lösen.

[Contao-Academy]

Der RAM-Verbrauch ist ein echtes Problem bei vielen Hostings. Ich hoffe auch, dass es hierfür irgendwie eine Lösung gibt. Manchmal hilft es, wenn man unter Einstellungen die "Minimale Stabilität" auf "Stabil" umstellt. Kommt halt auch drauf an, welche Erweiterungen man einsetzt.

[Webstylerin]

Ich muss mir jetzt hier auch mal etwas Luft machen, der Speicherverbrauch ist echt nicht mehr feierlich.

Gerade mache ich an einer Seite weiter, die Anfang des Jahres aufgesetzt wurde und nun endlich weiter gehen kann. Also als erstes mal Contao und Erweiterungen aktualisieren und schwupps, Composer macht mir einen Strich durch die Rechnung.

Die Seite liegt auf einem Entwicklungsserver eines meiner Kunden der bisher mit dem Composer keine Probleme hatte. Das ist jetzt wohl vorbei, denn jetzt reicht ihm der Speicher nicht mehr. Minimale Stabilität steht auf "Stabil"!

Ich werd demnächst mal meine Standarderweiterungen durch gehen und schauen, ob ich die alle noch im ER2 finde, langsam reichts nämlich. Entweder das Ding haut mir eine Fehlermeldung nach der anderen um die Ohren oder der Speicher reicht nicht. Ganz besonders lustig, wenn es lange ging und auf einmal reichts nicht mehr.

Die Idee vom Composer ist super, aber die Wirklichkeit eher die Hölle.

Sorry für den Jammerthread, aber es vergeht fast kein Tag an dem der Composer in irgendeiner Installation nicht rum zickt.

[Spooky]

Wir haben letztens ein neues Symfony Projekt aufgesetzt (nichts mit Contao). Da reichte auch 1G nicht mehr . // oops, schon gepostet

[mandrael]

Hallo! Ich mache gerade ein Upgrade einer Seite von Contao v2 auf v3.5 und überlege, Composer statt ER2 einzusetzen. Etliche Erweiterungen scheinen ja nur mehr dort vorzufinden zu sein. Zb. martin-kozianka/contao-fullcalendar , der gut ics einbinden kann. Ich habe gerade eine Testinstallation mit Composer am Laufen und frage mich, ob ich ihn nun einsetzen soll oder nicht. Was man hier so alles über RAM-Probleme liest, ist wirklich bedenklich. Mit Standardeinstellungen bekomme ich auch die Fehlermeldung "Fatal error: Out of memory (allocated 423362560)" - wenn ich "ab Alpha" einstelle, geht es mit den paar Erweiterungen, die derzeit drauf sind.
Contao läuft schon Jahre auf df und wir sind recht zufrieden; die bieten aber im Webhosting auch auf Nachfrage maximal 256Mb an. So wie ich das sehe, müsste ich das ganze Web wegen Composer auf einen anderen Anbieter übertragen, zB Webgo, nur um Composer (vielleicht stabil) nutzen zu können? Ich habe nirgends Systemanforderungen für Contao 3.5 mit Composer gesehen; kann man sagen, ab welcher Hauptspeichergröße der Composer zuverlässig läuft?
lg Michael

[Spooky]

kann man sagen, ab welcher Hauptspeichergröße der Composer zuverlässig läuft?

Das kann man nicht sagen, weil das auf die composer Operation ankommt. Wenn composer komplexe oder viele Abhängigkeiten (oder beides) auflösen musst, steigt der Speicherverbrauch. Man kann keine Aussage treffen wie zB "Mit 1GiB RAM hast du sicher immer genug". Darüberhinaus brauchst du diese Menge an Arbeitsspeicher ja nicht für den Betrieb der Website, sondern nur für die composer operationen - welche besser über die command line ausgeführt werden sollten. Dort hast du meistens (vorsicht, auch hier nicht immer) kein spezifisches memory limit, oder ein sehr großes.

[css-umsetzung]

Wir haben letztens ein neues Symfony Projekt aufgesetzt (nichts mit Contao). Da reichte auch 1G nicht mehr . // oops, schon gepostet

Das ist doch aber echt Krank oder? Denn das bedeutet das ich die Seiten zum updaten auf meinen Server holen und sie danach zurück schieben muss, was ja mal zu 90% nicht so einfach geht weil die symlinks stress machen.

Kein normaler webspace bekommt von seinem Anbieter 1,5G

Ich verstehe wirklich nicht, wie sich so etwas mit diesen Anforderungen so durchsetzen kann.

Ein Hoch auf das können der composer Entwickler die hier so, mit den nicht vorhandenen Ressourcen rumschlampen.

[Spooky]

Das ist doch aber echt Krank oder? Denn das bedeutet das ich die Seiten zum updaten auf meinen Server holen und sie danach zurück schieben muss, was ja mal zu 90% nicht so einfach geht weil die symlinks stress machen.

Bei Symfony Projekten haben wir das immer schon so gemacht. Primär aber eigentlich deswegen, weil wir nicht bei jedem Server auch SSH Zugriff hatten.

[Zwergenmeister]

Der Composer macht von Anfang an nur Ärger und nervt bei jedem update ! Fehler, Fehler Fehler, mehr Speicher, Speicher, Speicher

Habe nach 1,5 Jahren auch langsam genug und wechsel wieder zu ER2 oder muss bald alternativen zu Contao suchen.

[css-umsetzung]

Ja, leider ist das so

Ich habe noch keine contao Installation gesehen die den composer hat und dauerhaft fehlerfrei arbeitet.

[mandrael]

Hmm, ich habe nun die neue Contao3-Seite mit dem ER2 umgesetzt und sie läuft wunderbar (wenn ER2 auch nicht alle Updates in der Liste anzeigte und ich manuell durchklicken und auf installieren klicken musste). Ich bin immer für Neues zu haben und experimentierfreudig, aber es müsste klare Vorteile bringen. Ich habe auch ein paar kommerzielle Erweiterungen verwendet, was Composer noch nicht unterstützen soll (Lizenzschlüssel). Na, ich bin gespannt auf die ck2017. Contao ist ja ganz fantastisch und verdient eine Erweiterungsverwaltung aus einem Guss, mit denen sowohl Entwickler als auch Anwender glücklich sind, und die vor allem nicht Anforderungen stellt, die nur ein dedicated server erfüllt.

Gesendet von meinem SM-N910F mit Tapatalk

[BugBuster]

Der Composer macht von Anfang an nur Ärger und nervt bei jedem update ! Fehler, Fehler Fehler, mehr Speicher, Speicher, Speicher

Konnte ich bei mir abstellen, nachdem ich in System -> Einstellungen den Composer bei "Ausführungsmodus" umgestellt habe von "während der aktuellen HTTP Anfrage" auf "als Unterprozess des aktuellen Webprozesses". Der Befehl steht bei mir derzeit so:

/usr/bin/env php -d memory_limit=1G -d max_execution_time=900

Dort bekomme ich, zumindest bei meinem Hoster, mehr RAM als im laufendem PHP Prozess.

[FloB]

Vielleicht könnte man mit Weiterleitungen/iFrames/AJAX und ein Aufsplitten der Composer-Prozesse es schaffen ein bisschen mehr Ressourcen für den Composer rauszuschlagen? Contao selber verschlingt ja auch RAM. Möglicherweise könnten einige davon profitieren (die von der Einstellung nix wissen bzw. keine Konsolenbefehle via PHP schicken dürfen), wenn man ein minimales standalone Script für jeden einzelnen Ressourcen-intensiven Composer-Schritt hat?

Die genannte Backend-Einstellung sollte auch besser automatisch gesetzt/gecheckt werden, je nachdem, was der Server grade so hergibt … macht es einfacher für den gemeinen (und auch Profi-)Anwender.