Composer RAM-Fresser

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

Back 2 the Issue...

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