Composer RAM-Fresser

[Spooky]

Ja das habe ich bereits versucht wobei

$ 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

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

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.

[Spooky]

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.

[Thraile]

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

[Contao-Academy]

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.

[FloB]

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

[lucina]

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.

[tab]

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.

[lucina]

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

[chrischnian]

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.

[stefan.sl]

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.

[eBlick]

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?

[eBlick]

Hast du den Aufruf mit

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

[Spooky]

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.

[Thraile]

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:

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

bzw.

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

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

[tab]

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

[Spooky]

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.

[Ling]

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

[tab]

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?

[Spooky]

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.

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:

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

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

[Spooky]

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"?

[joc]

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.

[Spooky]

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.

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.

oder es eine andere Lösung gibt

Lokal updaten und deployen im Notfall.

[lucina]

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