Composer RAM-Fresser

Ich bin erstaunt, dass das bei uberspace funktioniert:

Code:

---

[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...".

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

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.

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.

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.

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

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

Zitat:

---

Zitat von mandrael

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.

Zitat:

---

Zitat von Spooky

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.

Zitat:

---

Zitat von css-umsetzung

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.

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.

Ja, leider ist das so :(

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

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

Zitat:

---

Zitat von Zwergenmeister

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:

Code:

---

/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.

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.

Es ist ja nur ein einzelner Prozess, den kannst du ja nicht aufteilen. Das müsste man wenn dann direkt im composer implementieren.

Und da wäre wahrscheinlich ein optionaler out-of-core Modus die bessere Alternative.

Zitat:

---

Zitat von Spooky

Es ist ja nur ein einzelner Prozess, den kannst du ja nicht aufteilen. Das müsste man wenn dann direkt im composer implementieren.

---

Aber der Prozess lässt sich ja doch in einzelne Teilschritte zerteilen, oder? Also information gathering, SAT solving, package download & upgrade … Genau das jeweils in separate minimale PHP-Prozesse auslagern (wie gesagt minimales Wrapper-Script per JS / iframe mit HTTP-Redirect aufrufen), um für jeden Teilschritt jeweils das Maximum an RAM zur Verfügung zu haben.

Ich denke mal, dass das SAT solving alleine schon den größen Anteil ausmacht und das daher nichts bringen wird.

Also ich mach mir auch immer mehr sorgen um die ganze Sache.

Der Witz ist das man zuerst alles installieren kann und dann nach x Wochen wird ein Update gemeldet und man will dabei auch die Packages aktualisieren und dann hängt man fest.
Wir haben schon DF genutzt dort hatten wir zum Glück ein Paket mit SSH und per SSH hat man mehr Ressourcen als über den Browser somit konnte man oft doch updaten.

Seit einiger Zeit nutze ich nur noch die VServer von NetCup und dort habe ich 6GB RAM und kann es mir nun einstellen. Dennoch bin ich mit der Entwicklung sehr unzufrieden und bin am Alternativen suchen.

Will ja net jeden Kunden für eine "10 Seiten Webseite" einen VServer andrehen um den Composer zufriedenzustellen. Von der Wartung gar nicht zu sprechen.

Wenn man aber sich mal an das Konzept der Inhalte gewöhnt hat dann will man es eigentlich nicht mehr missen. Naja schauen wir mal ob man eine Alternative findet oder ob es wieder besser wird, wobei da zweifel ich dran wenn man die letzten 2 Jahre so sieht.

Zitat:

---

Zitat von Spooky

Ich denke mal, dass das SAT solving alleine schon den größen Anteil ausmacht und das daher nichts bringen wird.

---

Dann wird es ja schon reichen ausschließlich diesen Prozessschritt in eine minimale Umgebung auszulagern. Das entspräche ja auch der Lösung mit einem externen Solver-Server, nur dass der Schritt halt nicht extern ausgeführt wird, sondern in einem miminmalen PHP-Prozess auf dem Server. Dieser kann ja – je nach verfügbaren Funktionen – automatisch entweder per System-Befehl standalone oder per Web Request (also via JS oder iframe) aufgerufen werden. Wichtig ist ja nur, dass für den resourcen-intensivsten Schritt das Maximum an Resourcen zur Verfügung steht, also nichts geladen wird, was nicht absolut für diesen Schritt nötig ist.

Dann kannst du dir aber auch gleich einfach das composer.lock file für deine composer.json auf einem anderen Server erzeugen lassen und dann auf dem Zielserver mit composer install verwenden ;). Das ist weniger kompliziert als irgendwie zu versuchen die composer Prozesse aufzuteilen.

Zitat:

---

Zitat von Spooky

Dann kannst du dir aber auch gleich einfach das composer.lock file für deine composer.json auf einem anderen Server erzeugen lassen und dann auf dem Zielserver mit composer install verwenden ;). Das ist weniger kompliziert als irgendwie zu versuchen die composer Prozesse aufzuteilen.

---

Es geht ja darum es für den einfachen Fall für den Anwender so umstandslos wie möglich zu machen. Und damit die dauerhaften Klagen über die Unbenutzbarkeit des Composers zu reduzieren. Selbstverständlich kann man auch die Staging-Geschichte machen, das ist aber bei vielen Projekten einfach nicht nötig oder unrealistisch. Alle profitieren davon, wenn das System versucht so klug wie möglich zu sein und dem Anwender damit so viel Arbeit wie möglich abnimmt (aber trotzdem fortgeschrittenere Methoden zulässt, sofern diese gewünscht sind).

Das kann ja auch automatisch passieren. Wenn man auf "Pakete aktualisieren" klickt, wird die composer.json + die Platform Information an den "composer server" geschickt, der erzeugt die composer.json und gibt diese zurück und der composer-client führt dann automatisch composer install aus. Problem ist: wenn das in einem Zug passieren soll, braucht man auch wiederum eine entsprechend lange max_execution_time.

Das wurde ja woanders schon mal besprochen.

Zitat:

---

Zitat von Spooky

Das kann ja auch automatisch passieren. Wenn man auf "Pakete aktualisieren" klickt, wird die composer.json + die Platform Information an den "composer server" geschickt, der erzeugt die composer.json und gibt diese zurück und der composer-client führt dann automatisch composer install aus. Problem ist: wenn das in einem Zug passieren soll, braucht man auch wiederum eine entsprechend lange max_execution_time.

Das wurde ja woanders schon mal besprochen.

---

Ja, Toflar hat da an was gebastelt. Spielt aber keine Rolle. Es gibt aber bisher keinen öffentlichen Server dafür, und selbst wenn es einen gibt, wird dieser sich offensichtlich nicht kostenlos betreiben lassen. Und obwohl ich mit Freude für das LiveUpdate zahle (obwohl ich es vergleichsweise selten nutze und es kostenlose Alternativen gibt), sehe ich nicht ein, warum jetzt einige für einen Resolve zahlen sollten, nur weil sie eine Mini-Website mit Contao betreiben.

Egal ob der Resolve jetzt auf einem externen oder dem selben Server ausgeführt wird, klar ist, dass man mit dem Heraustrennen der kritischen Prozesse viele Beschwerden gegenüber Composer lösen kann. Die (lokale) SAT-Auflösung in einem minimalen PHP-Prozess wäre ein erster Schritt, der auch den Weg zu einem externen Resolve-Server ebnen kann, wenn dieser jemals eingerichtet wird. Fakt ist, dass man bereits jetzt schon was tun kann, was nicht allzu kompliziert sein sollte und Einigen helfen kann.

Mein Punkt war aber, dass das meiner Meinung nach nichts bringen wird. Selbst wenn du das resolving irgendwie trennst aber dennoch lokal am selben Server mit den selben Speicherlimitationen laufen lässt, wird der Speicher evt. nicht reichen - eben weil das der aufwändigste Prozess ist.

Zitat:

---

Zitat von FloB

Ja, Toflar hat da an was gebastelt. Spielt aber keine Rolle. Es gibt aber bisher keinen öffentlichen Server dafür, und selbst wenn es einen gibt, wird dieser sich offensichtlich nicht kostenlos betreiben lassen. Und obwohl ich mit Freude für das LiveUpdate zahle (obwohl ich es vergleichsweise selten nutze und es kostenlose Alternativen gibt), sehe ich nicht ein, warum jetzt einige für einen Resolve zahlen sollten, nur weil sie eine Mini-Website mit Contao betreiben.

---

Ich sehe dann in Zukunft auch nicht ein, dass ich yberhaupt an kleine Hoster denken sollte und obendrein sehe ich auch nicht mehr ein warum ich kostenlos yberhaupt was zur Verfygung stellen sollte, bloss weil kleine Seiten das auch brauchen koennten. *scnr* *kopfschyttelnd*

Sorry, aber bei so formulierten postings bin ich leicht pissed... bin ich von Dir aber zum Glyck anders gewoehnt und kann ich als Ausrutscher werten.

Zitat:

---

Zitat von FloB

Egal ob der Resolve jetzt auf einem externen oder dem selben Server ausgeführt wird, klar ist, dass man mit dem Heraustrennen der kritischen Prozesse viele Beschwerden gegenüber Composer lösen kann. Die (lokale) SAT-Auflösung in einem minimalen PHP-Prozess wäre ein erster Schritt, der auch den Weg zu einem externen Resolve-Server ebnen kann, wenn dieser jemals eingerichtet wird. Fakt ist, dass man bereits jetzt schon was tun kann, was nicht allzu kompliziert sein sollte und Einigen helfen kann.

---

Der kritische Prozess IST bereits herausgeloest und frisst genau soviel RAM wie er eben braucht.
Besser wird es erst mit composer 2.0, welcher noch laenger brauchen wird, weil da dann die Internas von Composer anders gebaut sein werden (gibt dazu einen PR, den such ich aber nun nicht kostenlos raus, nichtmal fyr grosse Webseiten).

Zitat:

---

Zitat von xtra

Ich sehe dann in Zukunft auch nicht ein, dass ich yberhaupt an kleine Hoster denken sollte und obendrein sehe ich auch nicht mehr ein warum ich kostenlos yberhaupt was zur Verfygung stellen sollte, bloss weil kleine Seiten das auch brauchen koennten. *scnr* *kopfschyttelnd*

---

Sorry, ich wollte damit keine ich-will-alles-kostenlos-Aktion starten oder gar fordern. Mein Punkt war ja, dass das gar nicht kostenlos geht (und das auch recht so ist). War leicht anders zu verstehen, tut mir Leid.

Allerdings ist ein Auflösen der Abhängigkeiten (rechenintensiv, unregelmäßig und unplanbar) ein ganz anderes Kaliber als alle paar Wochen/Monate ein System-Update einzuspielen (datenintensiv, regelmäßig und gut planbar), dementsprechend mit anderen Anforderungen verknüpft – und nach meiner Einschätzung mit ganz anderen Kosten und Kostenstrukturen verbunden. Damit (und vielen anderen Gründen) macht es aus vielerlei Sicht keinen Sinn Kleinst-Projekte (die entsprechend auch geringste Hosting-Anforderungen besitzen und damit überproportional von der Problematik betroffen sind) zur Kasse zu bitten – ob jetzt durch einen Resolver-Service oder fetteres Hosting oder mehr Administrationsaufwand und Komplexität durch Staging. Es muss also darum gehen die Auswirkungen auf diejenigen Betroffenen[1] bestmöglich abzumildern, z. B. mit der von mir beschriebenen Maßnahme.

[1] Ich möchte nochmal betonen, dass ich nicht zu diesen "Betroffenen" gehöre, mein Server hat mehr als ausreichend Reserven für selbst komplexe Probleme – I've got no horse in this race, wie der Brite so schön sagt, außer dass das Thema Contao als Ganzes betrifft.

Zitat:

---

Der kritische Prozess IST bereits herausgeloest und frisst genau soviel RAM wie er eben braucht.

---

Das ist gut zu hören. Darf ich fragen, wie das konkret in Contao umgesetzt wurde? Ich verheddere mich grade im Sammelsurium der Pakete und komme da nicht weiter.
Nur zum Klarstellen, ich stelle mir den minimalen Prozess bzw. das auszuführende Skript in etwa so vor (Pseudocode – ohne die API oder inneren Vorgänge von Composer zu kennen!):

PHP-Code:

---

// Pseudo-Code!

include('Composer.phar');
$c = new Composer('composer.json');

// Die Daten zur Umgebung wurden bereits vorher gesammelt und werden jetzt nur noch eingelesen.
$env_data = file_get_contents('composer-env.json');

// SAT-Solver aufrufen.
$result_lock_data = $c->resolveDependenciesWith($env_data);

// Der nächste Schritt (separater Prozess) nutzt dann dieses Ergebnis.
file_put_contents('composer.lock', $result); 


---

Das ganze mit abgeleiteten Klassen o.Ä. zu machen wäre natürlich schöner, kostet aber einen Haufen Speicher.

Zitat:

---

Besser wird es erst mit composer 2.0, welcher noch laenger brauchen wird, weil da dann die Internas von Composer anders gebaut sein werden (gibt dazu einen PR, den such ich aber nun nicht kostenlos raus, nichtmal fyr grosse Webseiten).

---

Das ist noch viel besser zu hören, hilft aber (wegen der angesprochenen Umsetzungsdauer) auf absehbare Zeit leider nicht.

Zitat:

---

Zitat von Spooky

Problem ist: wenn das in einem Zug passieren soll, braucht man auch wiederum eine entsprechend lange max_execution_time

---

Darauf hatte ich noch vergessen einzugehen: Angenommen, der reine Solving-Prozess ist mit der max_execution_time abgedeckt, muss dein aufrufendes Skript nicht Solving-Dauer + x lang laufen, Stichwort polling (eben via Redirect bzw. JS).

Zitat:

---

Zitat von FloB

Nur zum Klarstellen, ich stelle mir den minimalen Prozess bzw. das auszuführende Skript in etwa so vor (Pseudocode – ohne die API oder inneren Vorgänge von Composer zu kennen!):

---

In Pseudo code laeuft es in etwa so ab:

PHP-Code:

---

include('Composer.phar');
$c = new Composer('composer.json');
// Die Daten zur Umgebung wurden bereits vorher gesammelt und werden jetzt nur noch eingelesen.
$env_data = file_get_contents('installed.json');
$env_data = file_get_contents('package*.json'); // wobei package* irgend ein referenziertes package im tree ist.
// HIER MACHT ES BEI VIELEN SCHON BUMM, einfach weil der Baum zu gross ist!

// SAT-Solver aufrufen.
$result_lock_data = $c->resolveDependenciesWith($env_data); // HIER MACHT ES BEI DEN MEISTEN DANN ENDGUELTIG BUMM!
// Der nächste Schritt nutzt dann dieses Ergebnis zur installation...
$c->install($result); // Wer bis hier hin kommt, hat kein Problem mehr.
// ...und dumped dann.
file_put_contents('composer.lock', $result); 


---

Das ist echt Müll.
80% der Websites kann ich nicht mehr updaten, da sich wie gesagt kein Kunde einen VServer für eine 10 Seiten Website mit Kontaktformular und bisschen Schnickschnack holt...für ein vielfaches sollte man vielleicht dazu sagen.

Bei HostEurope müsste ich nun z. B. für 256 MB (die sowieso nicht ausreichen) das 5x vom jetzigen Preis bezahlen, das heißt faktisch kann man eine Website mit Composer dort nicht mehr hosten und müsste umgezogen werden...

Ich weiß dass das nicht mit Contao zusammenhängt sondern ausschließlich mit dem Composer - aber wie geht ihr nun damit um? Was sagt ihr euerm Kunden? Gibts Workarounds? (Ich hab hier alle besprochenen schon versucht,...nur stabile Versionen, nur die Quellen die man auch updaten will in der config lassen, auf HTTP umstellen... bringt alles nix!)

Bin gespannt auf Antworten, ich weiß dass ihr da tolle Arbeit leistet und geleistet habt aber so kann man das Teil LEIDER meines Erachtens absolut in die Tonne treten.

Danke schon einmal und viele Grüße,

Christian

Zitat:

---

Zitat von rezico

aber wie geht ihr nun damit um?

---

• Den detached mode verwenden.
• Wenn der detached mode aus irgendeinem Grund nicht funktioniet, dann per SSH auf die Konsole verbinden und das composer update manuell durchführen.
• Wenn kein SSH Zugang besteht, manuell deployen.

Hey Spooky,
danke für deine Antwort!

Kurz zu deinen Punkten:

der detatched-mode: ich denke dass heißt composer als eigenständigen Prozess verwenden in den Einstellungen auswählen?
Bringt bei mir leider nur:

$ /usr/bin/env php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction --profile
Unable to create lock file: Permission denied
Failed to start up concurrent users module!

SSH gibts natürlich auf den wenigsten Standardhostings, in den meisten Fällen die mir bekannt sind kann ich bei nem SSH Zugang auch direkt die Einstellungen vornehmen die ich vornehmen muss....

Was mich jetzt aber am meisten interessiert: Was meinst du mit manuell deployen? Wie kann man sich das vorstellen?

DANKE!

Viele Grüße

Christian

Ich versteh's immer noch nicht - die 80% meiner betreuten Webseiten laufen 1a rauf mit Sternchen im zweitgünstigsten Paket des Feld-Wald-und Wiesen-Hosters Domainfactory. Mit Composer. Mit 128 MB RAM.

Die Projekte, bei denen es auf mehr ankommt und bei denen ich teilweise heftigst Entwicklerfunktionen benötige laufen da nicht, sind da auch noch nie gelaufen und werden auch nie in einem Shared-Hosting landen.

Ich persönlich denke, dass Webhoster ihre Hausaufgaben machen sollten. Das kommuniziere ich auch dem Kunden, und ich hatte gerade heute vormittag wieder einen Fall, bei dem der Kunde neben mir sass und den Unterschied zwischen den Firmen aus Montabaur, Karlsruhe, etc. und Qualitätshosting mitbekommen hat. Der war ganz erstaunt, dass sein System nach 20 Minuten lief, dass ich zwischendrin mit dem Support twitterte, der eine Funktion im relaunchten Backend versteckt hatte und er nun nicht einen halben Tag an mich bezahlen musste sondern nur eine halbe Stunde.

Just my 2 cents.

Zitat:

---

Zitat von rezico

Bringt bei mir leider nur:

Code:

---

$ /usr/bin/env php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction --profile
Unable to create lock file:  Permission denied
Failed to start up concurrent users module!

---

---

Damit könntest du mal bei deinem Hoster nachfragen, warum das so ist. Also im genauen: warum der php Prozess, wenn man ihn mit shell_exec ausführt, nicht genügend Rechte hat. Im genauen lautet der Aufruf dann zB:

PHP-Code:

---

shell_exec('/usr/bin/env php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction --profile') 


---

(im Ordner /composer deiner Contao Installation).

Versuche mal das /usr/bin/env zu entfernen, vielleicht liegt es daran. Das genaue Kommando muss ggf. je nach Umgebung immer angepasst werden.

Zitat:

---

Zitat von rezico

Was mich jetzt aber am meisten interessiert: Was meinst du mit manuell deployen? Wie kann man sich das vorstellen?

---

Die Website bspw. lokal aktualisieren, dann auf den Server deployen.

Praktischer wäre es natürlich, wenn es im composer-client auch einen "Pakete installieren" button gäbe, der anhand des composer.lock Files einfach ein "composer install" ausführt, was viel weniger Speicher beansprucht. Dann könntest du lokal das composer update durchführe, die composer.lock Datei auf den Server spielen und dort dann "Pakete installieren" ausführen.

Okay, danke dafür schon einmal.
Was mich ehrlich gesagt tierisch interessiert: Wieso benötige ich so unheimlich viel Speicher für das updaten von ERweiterungen? Ich meine doch Composer WEIS doch jetzt um welche Erweiterungen es geht und muss doch das ganze Repo nicht mehr durchsuchen (was ja nach meinen kurzen Recherchen vor allem wegen der ganzen Symfony Erweiterungen) dann zum Abschuss führt...

Aber es geht hier sogar nur um Updates, nicht um etwas neues.

Ich schau mal wie weit ich komme, auf "alles lokal" würde ich natürlich ungern wechseln....

Zitat:

---

Zitat von rezico

Was mich ehrlich gesagt tierisch interessiert: Wieso benötige ich so unheimlich viel Speicher für das updaten von ERweiterungen? Ich meine doch Composer WEIS doch jetzt um welche Erweiterungen es geht und muss doch das ganze Repo nicht mehr durchsuchen (was ja nach meinen kurzen Recherchen vor allem wegen der ganzen Symfony Erweiterungen) dann zum Abschuss führt...

---

Erweiterungen haben Abhängigkeiten. Diese Abhängigkeiten können weitere Abhängigkeiten haben. Diese Abghängikeiten können weitere Abhängigkeiten haben, etc. Manche Abhängigkeiten können sehr komplex definiert sein. Dies muss der composer aufschlüsseln. Und diese Operation benötigt, vor allem zum derzeitigen Entiwicklungsstand, je nach Situation, viel Speicher.

Alles klar. Ist schon einleuchtend aber dennoch...
Habe jetzt mit Host Europe gesprochen, das Paket mit 256 MB kostet 20 Euro im Monat,.... (ich glaub aktuell zahlt der Kunde 5)

Zum PHP Prozess...

Code:

---

Nein bei einem Shared Hosting Produkt können Sie nicht auf die einzelnen Prozesse zugreifen. Ist allerdings auch nicht von unserer Systemadministration gewünscht. Sie liegen ja nicht alleine auf diesem Server, sondern auch viele andere Kunden.

---

Das ist alles mal mega kacke. Anders kann ich das nicht ausdrücken ^^

Wie hoch ist die Wahrscheinlichkeit dass das mit direktem SSH Zugriff klappt? Das Paket mit SSH kostet immerhin nur 10 Euro mtl.

Danke!

Hast du den Aufruf mit

Code:

---

php -d memory_limit=1G -d max_execution_time=900

---

nun versucht oder nicht? Auf was für eine Frage bezieht sich die Antwort des Hosters? Ein Zugriff auf einzelne Prozesse ist ja nicht notwendig.

Ja das habe ich bereits versucht wobei

PHP-Code:

---

$ php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction --profile
Unable to create lock file:  Permission denied
Failed to start up concurrent users module! 


---

einen Fehler wird, ich musste es mit

PHP-Code:

---

$ /usr/bin/php php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction --profile
Unable to create lock file: Permission denied
Failed to start up concurrent users module!
Could not open input file: php 


---

Daraufhin habe ich eben gefragt wo das Problem wäre und es kam:

Nein bei einem Shared Hosting Produkt können Sie nicht auf die einzelnen Prozesse zugreifen. Ist allerdings auch nicht von unserer Systemadministration gewünscht. Sie liegen ja nicht alleine auf diesem Server, sondern auch viele andere Kunden.
Sie haben nur die möglichkeit ab einem Webhosting Medium Paket die .htaccess File zu editieren, mit der Sie die PHP.ini des Servers beeinflussen können.

Man würde wohl nicht darum herum kommen auf einen VServer zu wechseln oder auf das große Webhosting Paket.

Ich hatte heute auch wieder mal "Out of Memory".
Das Hosting hat 256MB RAM + SSH Zugang. Hat alles nichts geholfen…
Bevor du also Experimente machst, such dir lieber ein Hosting dass wirklich 512MB oder 1GB anbietet.
Da ich keine Werbung machen will, schick mir einfach ne PN, dann nenn ich dir Hoster.

Ich muss bei dem Kunden jetzt auch die "Lokal" Variante durchziehen, da im Moment ein Umzug nicht in Frage kommt.
Alles keine schöne Lösung…

danke für die antwort!
ich komm darauf zurück wenn ein wechsel wirklich im bereich des möglichen steht :-)

das lokale prozedere darf man sich dann in etwa so vorstellen: man zieht sich die website lokal, macht das update und schiebt es manuell wieder hoch?

ohje.

Zitat:

---

Zitat von rezico

Ja das habe ich bereits versucht wobei

PHP-Code:

---

$ php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction --profile
Unable to create lock file:  Permission denied
Failed to start up concurrent users module! 


---

einen Fehler wird, ich musste es mit

PHP-Code:

---

$ /usr/bin/php php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction --profile
Unable to create lock file: Permission denied
Failed to start up concurrent users module!
Could not open input file: php 


---

---

/usr/bin/php sieht nicht richtig aus. Was genau hast du nun bei PHP-Pfad/Befehl eingetragen? Hast du des nun tatsächlich mit

Code:

---

php -d memory_limit=1G -d max_execution_time=900

---

versucht? Aber es kann natürlich sein, dass dieser Modus auf dem Host einfach nicht funktioniert.

Zitat:

---

Zitat von lucina

Ich versteh's immer noch nicht - die 80% meiner betreuten Webseiten laufen 1a rauf mit Sternchen im zweitgünstigsten Paket des Feld-Wald-und Wiesen-Hosters Domainfactory. Mit Composer. Mit 128 MB RAM.

---

Wohl nur mit detached mode und der wird auch leider nicht von jedem Hoster unterstützt.

Ja, aber dann ist der Hoster halt kacke :).

Ich versteh es einfach nicht, dass von Lucina genannte Paket kostet 7€, das bekommt sogar der Sportverein um die Ecke gestemmt. Warum kleben alle alle an ihren Hosting-Paketen, die einfach noch nicht im Jahr 2016 angekommen sind?

Und anscheinend brauchen einige Hoster mal eine kleine Abwanderung, damit sich etwas ändert...

Gesendet von meinem D5803 mit Tapatalk

Zitat:

---

Zitat von Thraile

Warum kleben alle alle an ihren Hosting-Paketen

---

Das musst du mal den Kunden fragen ;-)

Ich habe einen Kunden, auf den hab ich jetzt fast 2 Jahre eingeredet, bis er endlich gewechselt ist.
Das Hauptproblem ist einfach, dass viele Kunden keine Lust haben E-Mail-Postfächer neu einzurichten und auch nicht die Kosten für den Umzug tragen wollen.

Zitat:

---

Zitat von rezico

Habe jetzt mit Host Europe gesprochen, das Paket mit 256 MB kostet 20 Euro im Monat,.... (ich glaub aktuell zahlt der Kunde 5)
[…] Das Paket mit SSH kostet immerhin nur 10 Euro mtl.

---

Gibt's bei Netcup deutlich billiger ;)

Zitat:

---

Zitat von Fenepedia

Das musst du mal den Kunden fragen ;-)

Ich habe einen Kunden, auf den hab ich jetzt fast 2 Jahre eingeredet, bis er endlich gewechselt ist.
Das Hauptproblem ist einfach, dass viele Kunden keine Lust haben E-Mail-Postfächer neu einzurichten und auch nicht die Kosten für den Umzug tragen wollen.

---

Mal ab von der aktuellen Fragestellung spricht eigentlich niemals etwas dagegen, für Mail und Hosting unterschiedliche Anbieter zu nutzen. Im Gegenteil, man wird unabhängiger und kann Services passgenauer machen. Sieht man hier ja auch wieder.

Dagegen spricht für kleine Unternehmen, dass die meisten günstigen Hosting-Pakete sowieso E-Mail Postfächer mit beinhalten, also der Kunde nicht unbedingt gern nochmal separat dafür bezahlen möchte. Die Kosten für Hosting und Mail sind für viele durchaus ein Argument. Auch wenn WIR wissen und auch glauben, dass "billig" nicht immer "preiswert" ist und Folgekosten produzieren kann, die wesentlich höher liegen als wenn man gleich eine wirklich preiswerte Lösung genommen hätte.

Zitat:

---

Zitat von tab

... Folgekosten produzieren kann, die wesentlich höher liegen als wenn man gleich eine wirklich preiswerte Lösung genommen hätte ...

---

Just an diesem Punkt scheinen dann ja einige angelangt zu sein. #NoMercy

Betrachte den Vorschlag der Trennung doch als Anregung, um mehr Flexibilität zu bekommen und nicht als Argument um jemanden platt zu machen. Ich weiss doch selber, dass viele da nicht sauber arbeiten wenn sie Mailaccounts aufsetzen. Wer sich da an Provider bindet (und sei es nur, indem man den voreingestellten Mailserver nutzt anstatt mal ordentlich einen domaineigenen MX-Record einzurichten, den man ggf auch mal fix umsetzen kann) dem fällt das irgendwann ggf. auf die Füsse. Nicht mehr und nicht weniger.

Ich mache es seit einiger Zeit so.

VServer für das Hosting. Beim gleichen Anbieter ein "günstiges Paket" für Mail und Backup.

So kommen wir meist auf ca 15€ im Monat haben aber beides getrennt und die Mails laufen über den vom Anbieter gewarteten Mailserver. Das Hosting übernehmen wir selbst auf dem VServer und sind hier sehr frei in der Konfiguration.

Für uns die beste Lösung.

Zum Thema Hoster: für jeden Kunden einen vServer aufzusetzen finde ich eher fragwürdig. Da dieser ja auch eine Wartung benötigt und regelmäßig Updates braucht. Gut, es gibt unattended updates (zumindest bei Debian), aber trotzdem muss hier hin und wieder ein Auge drauf geworfen werden. Zudem auch gecheckt werden sollte, ob es u.U. Probleme mit den Backups gibt. Wenn jetzt 100 Kunden-vServer laufen, dann wird das nicht mehr lustig.

Ich persönlich habe eigene Dedicated Server mit vHosts (mit LiveConfig verwaltet) und kann den Composer nach Lust und Laune benutzen.

Ich denke, die Diskussion driftet etwas in die falsche Richtung.

Es gibt unterschiedliche Gründe, den einen oder anderen Hoster zu nutzen, oder auch eine Dedicated Lösung.

Fakt ist, dass die Systemanforderungen durch den Composer momentan unverhältnismäßig hoch sind.
Ich selbst habe auch erhebliche Probleme im Domainfactory Reseller mit 256MB
Grundsätzlich würde ich auch lieber mit der 'alten' Erweiterungsverwaltung arbeiten, mit der ich diese und auch andere Probleme nicht hatte.
Allerdings sind eben einige Erweiterungen (z.B. SyncCTO) nur noch über den Composer verfügbar.

Daher frage ich mich, ob hier eine andere Lösung als "Hoster-Bashing" in Sicht ist?

Zitat:

---

Zitat von Spooky

Hast du den Aufruf mit

Code:

---

php -d memory_limit=1G -d max_execution_time=900

---

nun versucht oder nicht? Auf was für eine Frage bezieht sich die Antwort des Hosters? Ein Zugriff auf einzelne Prozesse ist ja nicht notwendig.

---

Das kam übrigens bei mir als Unterprozess raus...


Failed loading /usr/local/php5/ZendOptimizer.so: /usr/local/php5/ZendOptimizer.so: undefined symbol: zend_opcode_handlers
X-Powered-By: PHP/4.4.9
Content-type: text/html



Warning: main(./system/initialize.php) [function.main]: failed to open stream: No such file or directory in /kunden/xxx/dev/contao/main.php on line 16



Fatal error: main() [function.require]: Failed opening required './system/initialize.php' (include_path='.:/usr/local/lib/php') in /kunden/xxx/dev/contao/main.php on line 16

Das klingt als ob die über die Konsole global verfügbare php executable eine sehr alte wäre. Da müsstest du bei deinem Hoster nachfragen ob und unter welchem Pfad eine neuere verfügbar ist.

Zitat:

---

Zitat von eBlick

Das kam übrigens bei mir als Unterprozess raus...


Failed loading /usr/local/php5/ZendOptimizer.so: /usr/local/php5/ZendOptimizer.so: undefined symbol: zend_opcode_handlers
X-Powered-By: PHP/4.4.9
Content-type: text/html



Warning: main(./system/initialize.php) [function.main]: failed to open stream: No such file or directory in /kunden/xxx/dev/contao/main.php on line 16



Fatal error: main() [function.require]: Failed opening required './system/initialize.php' (include_path='.:/usr/local/lib/php') in /kunden/xxx/dev/contao/main.php on line 16

---

Versuch mal folgendes:

Code:

---

/usr/local/bin/php5.6.16-cli -d memory_limit=1G -d max_execution_time=900

---

bzw.

Code:

---

/usr/local/bin/php5-56LATEST-CLI  -d memory_limit=1G -d max_execution_time=900

---

Code:

---

/usr/local/bin/php5-56STABLE-CLI -d memory_limit=1G -d max_execution_time=900

---

Nachdem ich mir ein neues Arbeitsgerät (=PC) gegönnt habe und somit lokal in XAMPP nun reichlich RAM zur Verfügung stellen kann, kam mir dieser Thread wieder in den Sinn ;) Das wirft bei mir nun einige Fragen auf:

Gibt es aktuell einen funktionierenden Workflow, der es ermöglicht, die RAM-fressenden Teile des Updates lokal auszuführen?

Hier gibt es ja wohl zwei Ansätze. Entweder die komplette Installation auf dem lokalen PC zu duplizieren und nach dem Update dann wieder zurückzuspielen. Oder, die elegantere Lösung wenn sie denn funktioniert, dass nur die json- bzw lock-Datei kopiert wird und das eigentliche Update dann wieder auf dem Webserver durchgeführt wird.

Die zweite Frage wäre dann wohl, ob das - falls es denn funktioniert - auch mit einem lokalen Windows-PC funktioniert oder ob zwingend Linux notwendig ist?

Hat denn schon jemand Erfahrungen damit gesammelt, Composer-Installationen lokal upzudaten und wenn ja mit welcher Methode? Ich werde es jedenfalls nächstes Wochenende mal testen nach dem Motto: Lieber rechtzeitig nach funktionierenden Lösüngen suchen als später irgendwann unter Termindruck vor die Wand zu laufen ...

Ich verwende für solche Deployment Sachen meistens Beyond Compare - also zum vergleichen der lokalen und Remote Installation. Wenn ich das Update lokal durchführe bzw. durchführen muss, dann kann ich so die Änderungen auf den Remote Server deployen. Für solche Dinge kannst du auch SyncCto verwenden, theoretisch.

Zu beachten ist, dass die PHP Version lokal und remote gleich sein sollte - oder zumindest in der composer.json mit dem "platform" Parameter fixiert sein sollte.

Ganz sauber ist diese Variante trotzdem nicht - bspw. könnten durch das Update auch etwaige runonce scripte ausgeführt werden. Am Remote Server würde das allerdings nicht mehr geschehen.

Öch, es wäre vielleicht ganz gut ein paar Infos in der Paketverwaltung einzubauen. So wie es für mich ausschaut, klappt die Generation der JSON-Files immer über die Paketverwaltung. Allerdings muss ich zum Ausführen meistens in die Shell. Für Letzteres sollten einfach ein paar Hinweise in's BE eingefügt werden, dann ist der ganze Prozess vlt. nicht mehr ganz so frustrierend.

Ein weiterer Vorschlag zu Güte wäre vielleicht auch die Extension-Entwickler dazu anzuhalten die Abhängigkeiten genauer zu definieren um den RAM-Verbrauch zu senken.

Zitat:

---

Zitat von Spooky

Zu beachten ist, dass die PHP Version lokal und remote gleich sein sollte - oder zumindest in der composer.json mit dem "platform" Parameter fixiert sein sollte.

---

Ist das zwingend erforderlich? Reicht es da, wenn z.B. beide PHP 5.6.x bzw 5.6.y sind? Sonst muss ich in meinem lokalen Srver auch noch die genaue PHP-Version installieren, die auf dem Webserver läuft. Wie meinst du das mit der "platform"? Soll da der Wert vom Webserver übernommen werden?

Zitat:

---

Zitat von tab

Ist das zwingend erforderlich? Reicht es da, wenn z.B. beide PHP 5.6.x bzw 5.6.y sind?

---

Das kommt auf die Dependencies der Pakete an. Wenn es bei einem Paket im Zusammenhang mit PHP 5.6.x bspw. einen Bug gibt, dieser aber mit einer neuen Version des Paketes ab PHP 5.6.y gelöst ist, dann wird diese Version eben zumindest PHP 5.6.y verlangen. Kommt insgesamt eher selten vor, aber bei Symfony gab es das schon hin und wieder mal.

Was vermehrt vorkommt sind Pakete die Versionen mit PHP ~5.4 und mit PHP ~5.5 als requirement haben. Wenn du lokal PHP >=5.5 verwendest, aber am Server nur PHP 5.4 hast und du lokal das Update machst, dann wird's am Server krachen (ist mir kürzlich bei einem Deployment von einem Symfony Projekt schon mal passiert). Oder dasselbe in Grün mit PHP 5.x und PHP 7.x.

Zitat:

---

Zitat von tab

Wie meinst du das mit der "platform"? Soll da der Wert vom Webserver übernommen werden?

---

Ja, also du gibst in der composer.json dann zB folgendes an:

Code:

---

{
    …
    "config": {
        …
        "platform": {
            "php": "5.4"
        }
    },
    …
}

---

Die PHP Version muss dann zB der geringste gemeinsame Nenner sein.

Zitat:

---

Zitat von Ling

Ein weiterer Vorschlag zu Güte wäre vielleicht auch die Extension-Entwickler dazu anzuhalten die Abhängigkeiten genauer zu definieren um den RAM-Verbrauch zu senken.

---

In wie fern "genauer"?

Hi zusammen,

ich finde, so toll der Composer auch ist: Der Einsatz ist für die allermeisten Websites - zumindest meiner Kunden - wegen des gigantischen Speicherbedarfs nicht praktikabel, da die Standard-Webhoster allesamt nicht genug PHP Speicher zur Verfügung stellen.

Für kleinere Unternehmen, die für ein Web-Hosting vielleicht nicht mehr als 15,00 Euro monatlich ausgeben können oder möchten, kann ich den Composer definitiv nicht einsetzen. Oder aber ich habe einiges an Mehrarbeit, weil ich, falls überhaupt vorhanden, per SSH den Update Prozess anschieben muss und vorher die Aktualisierungen lokal machen muss.

Und auf die Frage mancher Kunden, warum die tolle "Homepage" zum Zusammenklicken aus dem Baukasten nur 1,- im Monat
kostet, ein funktionierendes Webhosting für Contao-Composer wohl ab 20,00 Euro im Monat, ist einem nicht so versierten Kunden auch nicht so leicht zu beantworten ;-)

Daher bleibt mir nichts anderes übrig, als bei 95% meiner Kunden bei der "normalen" Erweiterungsverwaltung" zu bleiben, in der aber nicht mehr alle Erweiterungen aktualisiert werden. Ich finde das wirklich schade, auch für Contao selbst.
Denn hierdurch setzen wahrscheinlich viel weniger Entwickler Contao als CMS ein.

Wenn doch nur, bis der Composer vielleicht eine bessere Performance hat oder es eine andere Lösung gibt, die Erweiterungen parallel auch in der "normalen" Erweiterungsverwaltung gepflegt werden könnten! Aber das ist wahrscheinlich zu viel Arbeit...

Also: keine Ahnung, was jetzt der beste gangbare Weg ist, um Contao weiter zu verwenden.

Zitat:

---

Zitat von joc

ich finde, so toll der Composer auch ist: Der Einsatz ist für die allermeisten Websites - zumindest meiner Kunden - wegen des gigantischen Speicherbedarfs nicht praktikabel, da die Standard-Webhoster allesamt nicht genug PHP Speicher zur Verfügung stellen.

---

Du brauchst nur genug Speicher auf über das CLI.

Zitat:

---

Zitat von joc

Für kleinere Unternehmen, die für ein Web-Hosting vielleicht nicht mehr als 15,00 Euro monatlich ausgeben können oder möchten, kann ich den Composer definitiv nicht einsetzen. Oder aber ich habe einiges an Mehrarbeit, weil ich, falls überhaupt vorhanden, per SSH den Update Prozess anschieben muss und vorher die Aktualisierungen lokal machen muss.

---

Wie gesagt, du brauchst nur genug Speicher über das CLI. Da gibt es auch Hosting Pakete unter € 15,--/Monat wo das möglich ist - oder es zumindest SSH Zugriff gibt.

Zitat:

---

Zitat von joc

oder es eine andere Lösung gibt

---

Lokal updaten und deployen im Notfall.

Nachdem jetzt wirklich alle Standpunkte mehrfach ausgetauscht wurden und das Thema auf vier Seiten nicht einer Lösung zugeführt wurde schliesse ich jetzt diesen Diskussionsstrang, damit man sich wieder der konstruktiven Arbeit zuwenden kann.

Herzlichen Dank für all Eure Meinungen.


Sent from my Nokia 6210 using Tapatalk