Composer möchte 1 GB RAM haben...

Dieses Abhängigkeitenproblem (inkl. Voroptimierung anhand bekannter Abhängigkeitsbäume) kann man nur mit einem Haufen mathematischer Theorie lösen, da mangelt es leider vielen Programmierern an der nötigen Ausbildung in (höherer) Mathematik. Und selbst wenn das Problem mathematisch gelöst ist, müsstest du das erstmal in PHP umsetzen ;). (Bin per Zufall grade über folgenden Artikel gestoßen, der gibt einen vereinfachten Vorgeschmack auf die Problematik, auch wenn er mit dem aktuellen Thema gar nicht direkt was zu tun hat: http://www.toptal.com/machine-learni...a-tree-kernels)

Zitat:

---

Zitat von MacKP

PS: Ich muß zugeben, das ein Desktop-Tool sehr sehr verlockend klingt. Um dann auch Private Repros mit rein zu nehmen, müßte man diese dort auch einbinden können. Eventuell wäre sowas auch etwas für Version 2 von so einem Tool...Aber auch so etwas will irgendwie finanziert werden könnte ich mir denken. Ist ja doch recht aufwändig für 3 OS sowas zu machen.

---

Naja für OS X und Linux reicht im Prinzip ein Bash-Script, das könnte man sogar in PowerShell portieren. Aber die Kommandozeile ist ja nicht unbedingt für die Zielgruppe geeignet. Deswegen würde ich ein simples Web-Frontend basteln, was in Electron (https://dzone.com/articles/building-...-with-electron, https://www.npmjs.com/package/electron-packager) verpackt ist und die PHP-CLI (per child_process.spawn() oder einem fertigen Package*) aufruft – Daten per Copy&Paste oder Drag'N'Drop oben rein, unten kommt die composer.lock raus. Die App muss dann "nur" sicherstellen, dass PHP installiert ist (oder gleich mitliefern?) und Composer mitliefern bzw. herunterladen.

Langfristig könnte das Tool sogar mit einer API im Contao-Composer-Plugin reden, um sich die benötigten Informationen zu ziehen und die fertige Datei direkt hochzuladen – dafür muss aber eine gute Rechteverwaltung bzw. Authentifizierung eingebaut werden.


* Auswahl an fertigen PHP-Packages für node/electron auf NPMjs.com:

• https://github.com/tomk79/node-php-bin
• https://github.com/sihorton/node-php-cgi
• https://github.com/cscott/node-php-embed
• https://github.com/iqbalfn/exec-php
• https://github.com/iqbalfn/run-php
• https://github.com/fgascon/node-require-php
• https://github.com/chr8993/php_server
• https://github.com/digplan/php-node
• https://github.com/fnobi/php-express
• https://github.com/alangecker/express-php
• https://github.com/xinix-technology/pas bzw. https://github.com/reekoheek/pas-php
• mehr: https://www.npmjs.com/search?q=php

Vielleicht ist in dem Zusammenhang auch das interessant – hilft allerdings nicht beim GUI-Problem: https://moquet.net/blog/distributing-php-cli/

Was man bei der "Composer-as-a-Service" Gechichte auch berücksichtigen müsste, sind Abhängigkeiten der PHP-Version, ja sogar manchmal von PHP-Erweiterung. All dies kann ja als Abhängigkeit definiert werden. Wenn beispielsweise der Service mit PHP 7 läuft und der Webserver auf PHP 5.4 kann es zu ganz anderen Ergebnissen kommen.

Zitat:

---

Zitat von webstar

Was man bei der "Composer-as-a-Service" Gechichte auch berücksichtigen müsste, sind Abhängigkeiten der PHP-Version, ja sogar manchmal von PHP-Erweiterung. All dies kann ja als Abhängigkeit definiert werden. Wenn beispielsweise der Service mit PHP 7 läuft und der Webserver auf PHP 5.4 kann es zu ganz anderen Ergebnissen kommen.

---

Guter Punkt. Kann man die PHP-Version, die Composer annimmt, irgendwie faken?

Sonst kann man natürlich (grade mit den fertigen Docker-Bibliotheken) sich "schnell" die richtige Version laden, aber das ist natürlich ein dicker Haufen Daten, die der Service-Server dann zu schlucken hat.

Zitat:

---

Zitat von FloB

Guter Punkt. Kann man die PHP-Version, die Composer annimmt, irgendwie faken?

Sonst kann man natürlich (grade mit den fertigen Docker-Bibliotheken) sich "schnell" die richtige Version laden, aber das ist natürlich ein dicker Haufen Daten, die der Service-Server dann zu schlucken hat.

---

Wurde alles schon bedacht. :)

Man kann die platform requirements mitgeben.

Hab ich doch schon 2x geschrieben, das kann meine Cloud auch schon :D

Guten Morgen,

möchte auch gerne meinen Senf dazu beigeben mich hat es heute auch mit dem Composer erwischt. Und wir sind schon seit dem Anfang an keine Freunde. :(

Fatal error: Out of memory (allocated 84410368)

Habe 4 Contao Installationen bei 1und1 laufen mit einem älteren Vertrag Dual Unlimited

2 Systeme sind als Backup bzw als Entwicklung und 2 Systeme Live habe das Update von 3.5.6 auf 3.5.8 heute eingespielt und da nach wollte der composer Client kein Update auf 0.16.3 machen zuwenig Speicher!

Also mal am nächsten Backup System vor dem Update auf 3.5.8 den Composer aktualisiert von 0.16.2 auf 0.16.3 ohne Probleme :-) Dennach das Live update auf 3.5.8 durchgeführt und noch mal zum composer auf aktualisieren gedrückt und siehe da selbe Problem Out of Memory !

Jetzt hab ich aktuell 3 System erst den Composer aktualisiert und dann das Live update / das ist erstmal soweit ok mit 0.16.3 kann nur keine Aktualisierungen machen ! Lösung in Arbeit

Ein System bleibt grade bei 0.16.2 bis das upgrade bei 1und1 durch ist.

------
Meine Lösung habe den Vertrag erstmal upgraden lassen von Dual Unlimited auf UNLIMITED PRO 4GB ! Kostet das selbe und spare sogar noch hintenrum bei den Mail Postfächern...

Jetzt zu 1und1 und dem Out of Memory wie auf Seite 1 schon geschrieben sind keine 2 gb oder 4gb garantiert sondern die sind auf Prozesse aufgeteilt und die dürfen max 260MB beim 4GB Tarif haben.

Bitte kein Meckern 1und1 ist mist usw. mach mal geht es nicht anders ! Und ich kann den Unmut von Oben mit dem Composer auch bestätigen, geht mir nicht anders und das wird langsam auch ein Grund gegen Contao sowie auch die weiter Entwicklung von 4.-5.0 was auch wieder einiges an arbeit bedeutet !

Es gibt von Contao genug User die das nicht professional machen, weil sie auch andere Arbeit haben und sich immer weider mit solche neun Problemen auseinander setzen müssen, wie die composer Krankheit!

Sorry für den schlechten Ton aber bin genervt von dem Composer weil er mir heute 3 Stunden arbeit verursacht hat !!! :mad:

Gruß
Zwergenmeister

Allerdings verlierst Du dabei aus den Augen, dass es nicht Contao ist, durch das ein Problem vorhanden ist, sondern einzelne Hoster, die ihre Kunden bezüglich des Arbeitsspeichers - mit Verlaub - schlicht verscheissern.

Nahezu alle PHP-basierte Software wird in Zukunft Composer nutzen, und das ist auch gut so, weil ein funktionierendes Paketmanagement, das Voraussetzung für sichere, verlässliche, interoperable Weiterentwicklung ist, nur so implementiert werden kann.

Sicher sind dazu auch andere Workflows erforderlich, und man kann sich auch fragen, ob Systemupdates nun unbedingt auf einem System, das offen im Netz steht gefahren werden müssen oder nicht besser lokal, auf Maschinen mit ausreichenden Ressourcen ausgeführt werden sollten. Lösungen werden entwickelt werden.

Mir ist bewusst, dass dann irgendwann für Menschen, die Webentwicklung nicht professionell betreiben, das Ende der Fahnenstange erreicht sein kann. Ich empfinde das auch manchmal als unschön, aber ich denke, dass es nicht zu ändern sein wird, sorry.

Auf der anderen Seite bin ich ganz egoistisch und denke, dass nur Professionalisierung mein Geschäftsmodell sichern helfen kann. Ich glaube nicht, dass man in fünf Jahren noch von gebastelten Webseiten für den Bäcker an der Ecke leben kann. Ich glaube noch nicht einmal, dass es den Bäcker an der Ecke in fünf Jahren noch geben wird. Ich kann das schade finden (und empfinde das auch so), oder ich kann die Herausforderung annehmen, mich mit dem Einsatz moderner Werkzeuge vertraut machen und mir dabei auch die technischen Voraussetzungen schaffen. Shared Hosting bei United Internet wird nicht dazu gehören.

Zitat:

---

Mir ist bewusst, dass dann irgendwann für Menschen, die Webentwicklung nicht professionell betreiben, das Ende der Fahnenstange erreicht sein kann.

---

Mit dieser Ankündigung nimmst du mir zum 10. Geburtstag von TL/Contao aber fast den Mut. :confused: Liebe Entwickler und Programmierer denkt auch bitte weiterhin an den nicht-Profi und Hobby-Seitenersteller für Anwender ohne gefüllten Geldbeutel. Denn so hatte ich eigentlich Open Source verstanden, nicht das auf einmal aus dem Projekt ein Kommerz-Produkt wird. Ich würde gern noch die nächsten 10 Jahre bei Contao bleiben trotz der derzeitigen Composer-Ärgernisse.

Bei der rasanten Entwicklung, die im Bereich Web-Programmierung und CMS stattfindet, bin ich mir nicht sicher, ob in 10 Jahren Contao überhaupt noch existiert und wenn doch, ob es dann noch PHP-basiert sein wird. 10 Jahre sind eine Ewigkeit in diesem Bereich. Schau 10 Jahre zurück und du erblickst den Geburtstag von Contao / TypoLight. Schau noch 10 weitere Jahre zurück, PHP war gerade geboren, ebenso wie Microsofts "Frontpage" und tatsächlich bald darauf auch die "CSS Level 1 Recommendation". Schau noch 10 Jahre weiter zurück und du siehst ... was auch immer, jedenfalls kein World Wide Web.

Wer will also wirklich realistisch prognostizieren, was in 10 Jahren sein wird? Wird es überhaupt noch "Websites" im klassischen Sinne geben oder wird alles von Facebook, Google & Co assimiliert? (Wir sind Google, Widerstand ist zwecklos!). Falls es daneben noch was Konkurrenzfähiges geben sollte, wie wird es aussehen? In welcher Sprache wird es programmiert werden? PHP? Ausschliessen kann ich es nicht, aber ich persönlich glaube nicht daran.

Zitat:

---

Zitat von lucina

...
Auf der anderen Seite bin ich ganz egoistisch und denke, dass nur Professionalisierung mein Geschäftsmodell sichern helfen kann. Ich glaube nicht, dass man in fünf Jahren noch von gebastelten Webseiten für den Bäcker an der Ecke leben kann. Ich glaube noch nicht einmal, dass es den Bäcker an der Ecke in fünf Jahren noch geben wird....

---

Hast du dich angesichts der momentanen Weltlage und der Aussichten schon gefragt ob deine oder meine Dienstleistungen noch notwendig sein werden?

Zitat:

---

Zitat von VGT

denkt auch bitte weiterhin an den nicht-Profi und Hobby-Seitenersteller für Anwender ohne gefüllten Geldbeutel. Denn so hatte ich eigentlich Open Source verstanden

---

?? Da hast du die Bedeutung von "Open Source" falsch verstanden, denke ich.

Jetzt wird's hier aber philosophisch :D
Ich gehe davon aus wir sind uns alle bewusst das keiner weiss was in 10 Jahren ist, wir planen ja keine Atomkraftwerke…

Bezüglich der Einfachheit von Contao, wir sind uns dessen sehr wohl bewusst und arbeiten ja auch an entsprechenden Lösungen, sofern diese denn möglich sind.

Wir müssen hier aber bitte auch bedenken, dass es diverse verschiedene Anwender mit verschiedenen Bedürfnissen gibt, und kein System alle bedienen kann. Jimdoo bietet eine iPhone Apps für's Auto-Foto-Hochladen. Wordpress wird wohl immer "einfacher" sein als ein Contao, weil die Zielgruppe aus 100000 Themes wählen kann und nicht CSS können muss. Contao richtet sich (aus meiner persönlichen Sicht) nicht an jemand der einen Homepage-Baukasten benötigt.

Moin,

1) Upgrade bei 1und1 ist durch, Composer läuft wieder. Trotzdem muss es in Zukunft immer mehr RAM werden beim Composer?, das die Paketverwaltung mehr power braucht als das eigentliche Contao macht mich für die Zukunft skeptisch!

2) Ich wollte hier keine Grundsatz Diskussion los treten nur habt bitte auch Rücksicht auf die User die das nicht professionell machen und davon gibt es einige, habe das Gefühl das es immer mehr in die kommerzielle Ecke gedrängt wird.

Ich nutze Contao seit 2009 und war mit der Entwicklung immer Recht zufrieden und es hatte viele Vorteile nur einiges nervte in der Zeit gewaltig.

- aufdrücken von responsive Design ganz am Anfang von 3.0 wurde ja wieder Teils zurück gerudert.
- Die Umstellung auf den Composer
- die ganze Umstellung auf 4.0/5.0, das ist auch ein Punkt wo ich sage wenn mir das zu komplex wird, suche ich mit ein anderes CMS oder eine Agentur.

Nachtrag wenn ich mir so die ganzen likes unter den Posts anschaue, seit ihr ja schon ein recht ein geschworenes Team :eek:
Gruß
Zwergenmeister

Ich würde es gut finden, wenn die Contao Systemanforderungen angepasst werden bzw. ein Hinweis auf den benötigten Arbeitsspeicher wenn man Composer einsetzen möchte.
Ich empfinde es als extrem schwierig den Kunden klar zu machen, dass der gebuchte Hosting Tarif nun nicht mehr ausreichend ist.
Ich hatte aktuell solch einen Fall. Bei den meisten kleinen Webspace Paketen ist Contao in Software Paket enthalten.
Zitat eines Kunden: "Also ich konnte die aktuelle Contao Version mit einem Klick auf meinem Paket installieren. Keine Ahnung was sie bei der Installation falsch gemacht haben. Nehmen Sie doch die 1 Klick Installation, diese läuft ja auf meinem Paket."
Tja, da muss ich mir eine gute Antwort überlegen.

LG,
Dirk

Zitat:

---

Zitat von dirksche

Ich würde es gut finden, wenn die Contao Systemanforderungen angepasst werden bzw. ein Hinweis auf den benötigten Arbeitsspeicher wenn man Composer einsetzen möchte.

---

Da man nicht pauschal sagen kann, wieviel Arbeitsspeicher für eine Composer Operation nötig ist, kann man hier auch keine konkreten Systemanforderungen stellen.

Also nach meiner Erfahrung kann man den Composer erst ab 128 MB Arbeitsspeicher nutzen... und das auch nur mit Einschränkungen.
Wie wäre es dann mit einer Empfehlung? Es muss ja kein konkreter Wert sein... aber ein Empfohlen ab 128 MB würde ja schon reichen.
Somit hätte man etwas offizielles was man auch den Kunden unter die Nase halten kann ;-)

Hallo dirksche,
es gibt da schon Hinweise bei Composer selber.
Das Problem ist allerdings, das es nicht bestimmbar ist, wie viel RAM man denn nu braucht. Das kommt eben auf die Erweiterungen an, die man einsetzt. Je mehr Erweiterungen und Abhängigkeiten, desto mehr. Man kann also nicht sagen: 'Mindestens 128MB', da das dann nicht für alle reicht.
Im Grunde sehe ich da eher uns in der Pflicht den Kunden richtig aufzuklären. Bisher hatte ich damit bei meinen Kunden auch noch kein Problem.
Wenn ich sowas wie MeteModels einsetze und noch ein paar andere Erweiterungen, dann erklären ich den Kunden das vorher und sage denen auch, das es zwei Wege gibt: Per Hand installieren und updaten = sehr tuer / Über Composer = Günstig / Über Composer, wenn ich die Installation immer bei mir updaten muß, da das Hosting vom Kunden es nicht kann = teuer. Richtet sich also ganz klar nach der Zeit, die ich da rein stecken muß. Kunde kann dann wählen ob er mehr für das Hosting zahlt oder mehr für mich pro update oder in der Entwicklung (wenn man noch sehr viele updates macht).

Viele Grüße

Ist es programmtechnisch nicht eventuell möglich, dass er bei der Installation/Update einer Erweiterung sich nur ausschließlich um diese kümmert und nicht gleich Vollgas gibt?

Ich kann mit dem Composer ohne Umwege noch nicht einmal eine kleine Erweisterung deinstallieren, was von 2 Monaten noch der Fall war.

@ Georgi,
das geht eben nicht einfach nur um diese eine Erweiterung.
Der muß gleich alle Prüfen, falls die Erweiterungen unterschiedliche php-Versionen verlangen oder unterschiedliche Versionen von einer Erweiterung oder oder.. und das kann der nur, wenn der direkt richtig los legt ;-)

Viele Grüße

Ich möchte gerne einmal an dieser Stelle auch meine Erfahrungen schildern, die ich in den letzten Tagen gemacht habe. Weil ich es leid war, immer wieder auf vermeintliche Grenzen des PHP-Memory-Limits mit Composer zu stoßen, habe ich mir einen der kleinsten Cloud-Server eines anderen Anbieters gemietet, ohne Mindestlaufzeit, aber selbstadministiert. Ich habe testweise eine der infrage kommenden Installationen von meiner bisherigen Hosting-Plattform auf den Server übertragen und beide Installationen synchronisiert (syncCto). Wenn ich jetzt den Composer auf dem Cloudserver starte, dann erhalte ich folgende Statistik:

Memory usage: 95.49MB (peak: 272.9MB), time: 123.61s

Anhang 17498

Beim nahezu identischen Testlauf auf dem Web-Space des bisherigen Hosting-Anbieters, bei einem Vertrag mit max. 512MB PHP-Memory-Limit, erhalte ich diese Fehlermeldung:

Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 32 bytes) in phar: ...

Angesichts solcher Ergebnisse und Erfahrungen, die ja auch schon mehrfach hier im Forum angeklungen sind, ist es sehr wohl entscheidend, wo und mit welchem Vertrag ein Webauftritt entwickelt wird.

So "nervig" es sein kann, laufend mit wirklichen und/oder vermeintlichen Softwarefehlern konfrontiert zu sein, so sehr scheint es mir aber auch anerkennenswert zu sein, was ein Team leistet, das ein solches Projekt wie Contao entwickelt, mit allen möglichen Erweiterungen und Tools ... und das mit einer weitgehend offenen Lizenz!

Aus meiner Sicht kann es nur die Konsequenz geben, dass man sich sorgfältig um eine adäquate Entwicklungsplattform bemüht. Dadurch kann man sich auf Dauer viele Nerven sparen, viel Zeit und nicht zuletzt auch viel Geld, auch wenn man vielleicht zunächst etwas mehr Geld in die Hand nehmen muss, als bisher; dies kann man den meisten seriösen Kunden auch argumentativ vermitteln, denke ich ...

Zitat:

---

Zitat von Ulrich

Angesichts solcher Ergebnisse und Erfahrungen, die ja auch schon mehrfach hier im Forum angeklungen sind, ist es sehr wohl entscheidend, wo und mit welchem Vertrag ein Webauftritt entwickelt wird.

---

Naja, wenn bei einem Projekt selbst 512MiB nicht mehr reichen, kommt man um andere Lösungen nicht herum.

Zitat:

---

Zitat von Spooky

Naja, wenn bei einem Projekt selbst 512MB nicht mehr reichen, kommt man um andere Lösungen nicht herum.

---

Die Frage ist doch, ob ich die 512MB tatsächlich zur Verfügung habe! Die Statistik auf dem Server zeigt im nahezu identischen Vergleich, dass der Peak des Memory Usage bei 272.9MB lag, also bei weitem weniger Memory tatsächlich benötigt wird. Daraus ist doch zu schließen, dass mir bei einem Vertrag, der mir max. 512MB zusichert, die meiste Zeit nicht einmal die ~275MB zur Verfügung stehen ...

Offenbar gibt es bei vielen Hosting-Verträgen eine signifikante Diskrepanz zwischen den angegebenen Maximalwerten und den tatsächlich im Durchschnitt zu Verfügung stehenden Resourcen! Dies scheint mir doch bemerkenswert ... oder ich habe etwas völlig missverstanden ...

Zitat:

---

Zitat von Ulrich

Die Frage ist doch, ob ich die 512MB tatsächlich zur Verfügung habe! Die Statistik auf dem Server zeigt im nahezu identischen Vergleich, dass der Peak des Memory Usage bei 272.9MB lag, also bei weitem weniger Memory tatsächlich benötigt wird. Daraus ist doch zu schließen, dass mir bei einem Vertrag, der mir max. 512MB zusichert, die meiste Zeit nicht einmal die ~275MB zur Verfügung stehen ...

---

Verstehe ich nicht was du meinst. Beim ersten Test verlangt (nur Composer alleine) nach 275MiB RAM. Beim zweiten Test verlangt alles zusammen insgesamt mehr als 512MiB.

Sieht eigentlich der Fehlermeldung nach schon so aus, als ob du die 512 MB wirklich zur Verfügung hättest. Sonst würde auch eine kleinere "Allowed memory size" angezeigt.

Zitat:

---

Zitat von Spooky

Verstehe ich nicht was du meinst. Beim ersten Test verlangt (nur Composer alleine) nach 275MiB RAM. Beim zweiten Test verlangt alles zusammen insgesamt mehr als 512MiB.

---

Offenbar hast Du mich wirklich missverstanden. Die Bedingungen, für beide Composer-Tests, sind auf beiden Plattformen, abgesehen von den real zur Verfügung stehenden Resourcen, nahezu identisch. Beide Installationen sind synchronisiert, dieselbe Contao-Version, dieselben Erweiterungen, dieselben Einstellungen ...

Zitat:

---

Zitat von Ulrich

Offenbar hast Du mich wirklich missverstanden. Die Bedingungen, für beide Composer-Tests, sind auf beiden Plattformen, abgesehen von den real zur Verfügung stehenden Resourcen, nahezu identisch. Beide Installationen sind synchronisiert, dieselbe Contao-Version, dieselben Erweiterungen, dieselben Einstellungen ...

---

Und du hast am ersten System auch ein memory_limit von 512MiB eingestellt? Und der Stand der Erweiterungsverwaltung war auf beiden System derselbe?

Außerdem musst du bedenken, dass auf unterschiedlichen Systemen auch die Speicherauslastung potentiell unterschiedlich sein kann.

Zitat:

---

Zitat von tab

Sieht eigentlich der Fehlermeldung nach schon so aus, als ob du die 512 MB wirklich zur Verfügung hättest. Sonst würde auch eine kleinere "Allowed memory size" angezeigt.

---

Das sehe ich anders, was heisst denn "allowed"? ... das ist doch das zugesicherte Maximum. Nicht zugesichert, in solchen Verträgen, ist die dauernde Verfügbarkeit des "erlaubten Maximums". Das ist aber genau der Punkt bezüglich der - aus meiner Sicht irreführenden - Fehlermeldung: sie nennt nicht das tatsächlich verfügbare Maximum zur Laufzeit, sondern das "erlaubte" Maximum (wenn es denn zur Verfügung steht) ...

Zitat:

---

Zitat von Spooky

... Außerdem musst du bedenken, dass auf unterschiedlichen Systemen auch die Speicherauslastung potentiell unterschiedlich sein kann.

---

Genau davon "rede" ich doch: die Installation des Contao-Projektes ist nahezu identisch, die Resourcen der jeweiligen Plattformen natürlich nicht. Die nahezu identische Contao-Installation sollte jedoch auf beiden Plattformen Resourcen in nahezu identischem Umfang beanspruchen ...

Zitat:

---

Zitat von Ulrich

Das sehe ich anders, was heisst denn "allowed"? ... das ist doch das zugesicherte Maximum. Nicht zugesichert, in solchen Verträgen, ist die dauernde Verfügbarkeit des "erlaubten Maximums". Das ist aber genau der Punkt bezüglich der - aus meiner Sicht irreführenden - Fehlermeldung: sie nennt nicht das tatsächlich verfügbare Maximum zur Laufzeit, sondern das "erlaubte" Maximum (wenn es denn zur Verfügung steht) ...

---

Nein, dann steht dort in der Regel auch weniger memory limit. Also wenn du zB bei 1&1 einen Vertrag hast, der ein vermeintliches memory limit von 128 MiB hat, dann könnte es sein, dass dann schon bei 117440512 bytes Schluss ist und das würde dann auch bei der Fehlermeldung so drin stehen.

Hast du es auf deinem eigenen System nun mit einem memory_limit von 512 MiB getestet?

Zitat:

---

Zitat von Ulrich

Die nahezu identische Contao-Installation sollte jedoch auf beiden Plattformen Resourcen in nahezu identischem Umfang beanspruchen ...

---

Wenn die PHP Umgebung nicht exakt die selbe ist, dann kann man davon nicht ausgehen.

Kann sein, dass es bei dir anders aussieht, obwohl ich es eigentlich nicht glaube, weil die Fehlermeldung von PHP ausgegeben wird und nicht sonst irgendwie vom Server. Würde PHP davon ausgehen, dass 512M verfügbar sind und erst 256M allokiert haben, dann würde es diese Fehlermeldung nicht ausgeben, sondern zumindest erst einmal versuchen, den Speicher zu allokieren. Ich beziehe meine diesbezüglichen Erfahrungen aber nur vom 1&1 shared hosting. Anderswo hatte ich das noch nicht :D. Da steht dann z.B. das memory_limit laut phpinfo bei 128M, aber in der Meldung sieht man dann, dass bei 32M Schluss ist. Da stand bei mir bisher immer der reale Wert, der dann auch erreichbar ist.

Edit: Ah, Spooky war schneller, aber bei 1&1 würdest du vermutlich keine 112M (117440512 Bytes) bekommen, sondern eher nur 32M (33554432 Bytes).
Eventuell hängt es auch damit zusammen, wie der Server und PHP konfiguriert sind. Also ob das verfügbare Memory z.B. von vornherein auf mehrere Prozesse/Threads aufgeteilt wird.

Zitat:

---

Zitat von tab

Edit: Ah, Spooky war schneller, aber bei 1&1 würdest du vermutlich keine 112M (117440512 Bytes) bekommen, sondern eher nur 32M (33554432 Bytes).

---

Naja, das ist ja nicht fixiert, das hängt ja von der Auslastung des Servers ab, wieviel du tatsächlich bekommst. Wenn du einen Vertrag mit 128MiB hast, bekommst du das ja auch - aber nicht immer.

Naja, da habe ich neulich was anderes gelernt in einem anderen Thread. Nämlich, dass ich da auch bei meinem Vertrag, der mir 2GB garantiert, diese nicht mit einem Prozess/Thread allein nutzen kann. Muss mal schauen wo das war.

Edit: Es war sogar dieser Thread (auf Seite 1) und ich habe es damals selbst getestet, bei 134M war Schluss mit lustig trotz garantierter 2GB.

Zitat:

---

Zitat von Ulrich

Memory usage: 95.49MB (peak: 272.9MB), time: 123.61s
...Vertrag mit max. 512MB PHP-Memory-Limit, erhalte ich diese Fehlermeldung:
Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 32 bytes) in phar: ...
...ist es sehr wohl entscheidend, wo und mit welchem Vertrag ein Webauftritt entwickelt wird.
...sorgfältig um eine adäquate Entwicklungsplattform bemüht.

---

Das hieße ja, daß der Composer unschuldig ist und der Hoster schummelt.

Bei meinem bisherigen Provider stand im Fehler immer als überschrittener Wert der "allowed max", der im Vertrag zugesichert und auch in der Konfiguration eingestellt war, in aktuellen Fall die 512MB, die ausreichen sollten, wenn ich nur ca. 270MB max benötige.

Ich habe aber auf dem CloudServer (php.ini -> allowed max = 128MB!!) eben einen anderen Test ausgeführt, nämlich in den Contao-Einstellungen das max. für Composer auf 512MB eingestellt und da passiert etwas, das ich nicht verstehe:

$ /usr/bin/env php -d memory_limit=512MB -d max_execution_time=900 composer.phar update --no-ansi --no-interaction --dry-run --profile
PHP Fatal error: Allowed memory size of 262144 bytes exhausted (tried to allocate 104 bytes) in Unknown on line 0

Wenn der Wert laut Standard auf 1G steht, dann läuft Composer durch ... :eek:

Und wenn du jetzt direkt danach nochmal ein composer update durchführst (mit der 512MiB cli Einstellung).

Zitat:

---

Zitat von Spooky

Und wenn du jetzt direkt danach nochmal ein composer update durchführst (mit der 512MiB cli Einstellung).

---

php.ini:

client steht auf -1 (unlimited) http://php.net/manual/de/ini.core.php#ini.memory-limit
server bisher auf 128MB

Der Test mit memory-limit 512MB bringt denselben Fehler (bei Composer-Einstelltung 512MB) ...

Es scheint nur die Hälfte dessen zur Verfügung zu stehen, was in der Composer-Einstellung eingestellt ist.

Bzgl. der php.ini: für das command line environment gibt es meistens eine separate php.ini

Der Server limitiert das wahrscheinlich - jedoch ist es komisch, dass es mit 1G trotzdem funktionieren würde.

Zitat:

---

Zitat von Spooky

Bzgl. der php.ini: für das command line environment gibt es meistens eine separate php.ini

Der Server limitiert das wahrscheinlich - jedoch ist es komisch, dass es mit 1G trotzdem funktionieren würde.

---

Na ja, die Hälfte von 1G sind 512MB, wenn die real genutzt werden können, dann reicht es ... ich hab das aber, ehrlich gesagt, noch nicht ganz verstanden; an meiner Grundaussage kann ich aber festhalten: es ist vernünftig, sich um eine adäquate Entwicklungsplattform zu kümmern ...

da es immer wieder Probleme mit dem Composer auf den Unterschiedlichen Hosting Paketen gibt,
habe ich mich sehr lange geweigert den Composer zu verwenden.
Doch leider kommt man fast nicht mehr ohne ihm aus.

Ich selber erstelle Projekte immer Lokal, und hab somit mit dem Composer soweit keine Probleme.
Bei Änderungen oder Anpassungen muss ich nicht in das Live System eingreifen.
Es ist aber immer ein Aufwand das ganze vernünftig zu Synchronisieren.

Es wäre sicher eine Überlegung wert Contao genau in diesem Bereich zu erweitern, und den Benutzer
von vornherein die Möglichkeit, für eine einfach zu verwendende Synchronisierung bereitzustellen.
(Synchronisation, Backup Funktion, direkt im Core einbinden....)
Bin mir sicher dass die Benutzer dies sofort annehmen und damit auch arbeiten, da es noch weitere
vorteile mit sich bringt. (einfaches Backup, Live Version wird nur aktualisiert wenn alles OK ist, usw.)

Dies wäre sicher eine sinnvolle und Praktische Erweiterung von CONTAO, und das Problem mit dem
Composer wäre somit auch behoben.

Gruß Thomas

Also so in Prinzip so etwas wie syncCto? 😀 http://contao-synccto.com

Gesendet von meinem D5803 mit Tapatalk

FollowUp to SyncCto.

Ich verwende SyncCto selber...
Laut ER wird 3.5 angeblich nicht unterstützt ;-) (erst auf der webseite von SyncCto gibt es den Hinweis dass auch 3.5 unterstützt wird)
SyncCto ist AUCH eine externe Erweiterung welche installiert werden muss.
SyncCtoPro ist für manchen sicher viel zu Teuer. (wenn erweiterte Einstellungsmöglichkeiten benötigt werden)

Eine solche Funktionalität gehört eigentlich in das Grundsystem, und wäre sicher ein großer Plus Punkt für Contao.

Es geht ja generell um eine angepasste Lösung das Problem mit dem Composer zu umgehen.
Dazu muss auf externe Erweiterungen zurückgegriffen werden, wo man sich wieder abhängig macht.
Dies ist sicher nicht Optimal, und wird sicher auch nicht von jedem akzeptiert.

Zitat:

---

Zitat von speedweb

Laut ER wird 3.5 angeblich nicht unterstützt ;-) (erst auf der webseite von SyncCto gibt es den Hinweis dass auch 3.5 unterstützt wird)
SyncCto ist AUCH eine externe Erweiterung welche installiert werden muss.

---

Naja, das liegt einfach daran, dass wir syncCto im ER nicht mehr aktualisieren. Laut Composer ist syncCto sehr wohl kompatibel mit Contao 3.5 :)

Zitat:

---

Zitat von speedweb

Eine solche Funktionalität gehört eigentlich in das Grundsystem, und wäre sicher ein großer Plus Punkt für Contao.

---

Den Core so schlank wir möglich zu halten finde ich ne gute Sache und daher gehört so etwas wie syncCto nicht in den Core. Und das sage ich jetzt nicht, weil das eine Extension von uns ist, die Zeit für die Bugfixes und Wartung könnten wir auch besser für andere Dinge gebraucht ;). Mit syncCto zieht man sich na gleich ne ganze Handvoll Pakete mit ins System, alles ja theoretische Fehlerquellen.

Zitat:

---

Zitat von speedweb

Es geht ja generell um eine angepasste Lösung das Problem mit dem Composer zu umgehen.
Dazu muss auf externe Erweiterungen zurückgegriffen werden, wo man sich wieder abhängig macht.
Dies ist sicher nicht Optimal, und wird sicher auch nicht von jedem akzeptiert.

---

Wenn du die Speicherauslastung von Composer meinst, dass ist dieses Problem nur bei Composer zu Lösen - einen Workaround gleich in den Core packen zu wollen ist da nicht die beste Lösung, Und wie gesagt mit syncCto ziehen gleich eine ganze Familie von Fremdpaketen bei dir ein:

- Multicolumnwizard (der gehört allerdings in den Core)
- DC-General
- eine Ziperweiterung
- phpseclib
- diffihelmann
- guzzlehttp.

SyncCto ist für mich keine Option. Es würde ja bedingen dass die lokale Contao Installation lauffähig ist. Wir nutzen Magallanes für deployment von Contao 4 Installation mit Composer. Ich werde vermutlich in meinem Vortrag auf der Contao Konferenz darauf kurz eingehen :-)

Zitat:

---

Zitat von speedweb

Es geht ja generell um eine angepasste Lösung das Problem mit dem Composer zu umgehen.

---

Hier ist die Rede von einer lokalen Installation und einem anschließenden "Zurückspielen".

Gibt es dazu vielleicht eine einfache Anleitung?

Also, ich habe mir jetzt folgende Voraussetzungen geschaffen: Lokale Installation mit https://contao2go.org/. Dort mache ich via Composer in der Paketerweiterung die Updates oder Neu-/De-installationen von Erweiterungen. Konkret: Nach den letzten Updates auf 3.5.9 via easyupdate wurde die Aktualisierung des [Integrity Check] erforderlich (wg neuer Checksummen). Dann per WinSCP im Modulordner den Ordner [Integrity Check] synchronisiert. Anschließend den gesamten Composer-Ordner des RootVerzeichnises synchronisiert; letzteres war leider zeitaufwändig. Gibt es auch eine einfachere Lösung für einen "Nichtprofi"? (außer syncCto)

Gruß Georgi