Composer RAM-Fresser

[Spooky]

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.

[FloB]

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.

[Spooky]

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

[chrischnian]

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.

[FloB]

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.

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

[FloB]

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

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

[FloB]

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.

[Spooky]

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.

[xtra]

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.

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

[FloB]

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.

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!):

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

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.

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

[xtra]

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:

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); 

[rezico]

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

[Spooky]

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.