Composer möchte 1 GB RAM haben...

[Spooky]

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.

[andreas.schempp]

Jetzt wird's hier aber philosophisch
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.

[Zwergenmeister]

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
Gruß
Zwergenmeister

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

[Spooky]

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.

[dirksche]

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

[MacKP]

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

[Georgi]

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.

[MacKP]

@ 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

[Ulrich]

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

CloudServerStatistik.png

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

[Spooky]

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.

[Ulrich]

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

[Spooky]

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.

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

[Ulrich]

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

[Spooky]

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.

[Ulrich]

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

[Ulrich]

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

[Spooky]

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?

[Spooky]

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.

[tab]

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

[Spooky]

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.

[tab]

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.

[KlausGrenoble]

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.

[Ulrich]

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

[Spooky]

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

[Ulrich]

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.

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

[Ulrich]

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

[speedweb]

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

[Thraile]

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

Gesendet von meinem D5803 mit Tapatalk

[lucina]

FollowUp to SyncCto.

[speedweb]

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.

[Thraile]

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

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.

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.

[andreas.schempp]

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

[Georgi]

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