Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ppm Worker Anzahl #818

Open
StefanSchoof opened this issue Aug 16, 2020 · 5 comments
Open

ppm Worker Anzahl #818

StefanSchoof opened this issue Aug 16, 2020 · 5 comments

Comments

@StefanSchoof
Copy link
Contributor

Aktuell wird die worker Anzahl auf 8 festgelegt. Mit 8 workern wird doppelt soviel Arbeitsspeicher wie mit einem Worker benötigt. Da die meisten Installationen ja wahrscheinlich von einem vzlogger und höchstens einem Nutzer gleichzeitig genutzt wird, scheint mir 8 zu viel. Wenn man das Arm Image jetzt laufen lässt, wäre es schön sparsamer mit den Ressourcen um zu gehen.

Mögliche Lösungen die mir einfallen:

  • in der middleware.json ändern (sehr einfach, aber kann vorhandene Installation beim Update stören)
  • im docker CMD worker Anzahl setzten (Änderungen nur für docker images)
  • einen Environment Variable für die Workeranzahl einführen und auslesen. (Aufwändiger, frage ob nötig)

Gibt es noch andere Ideen?

@andig
Copy link
Contributor

andig commented Aug 16, 2020

Worker als ENV Variable in Docker ausprägen und an ppm als cmdline Parameter übergeben? Das sollte ohne weitere Änderungen gehen?

@StefanSchoof
Copy link
Contributor Author

Sollte es auch eine Umgebungsvariable geben, die steuert, ob doctrine starten soll?
Also das man statt der Zeile:

(/vz/bin/doctrine orm:schema-tool:update --force || /vz/bin/doctrine orm:schema-tool:create) &&

ein bash script hat was prüft, ob VZ_CREATE_SCHEMA oä da ist. Wenn ja dann doctrine laufen lässt und dann ppm mit der Worker anzahl aus VZ_WORKER_COUNT startet.

Wenn die Idee in Ordnung ist würde ich mal versuchen ein PR dafür zu machen.

Wenn dann Umgebungsvariablen in der Config Klasse Werte aus der config.yaml überschreiben könnten, würde der lange cmd im docker-compose entfallen und nur noch über Umgebungvariablen zu steuern.

@andig
Copy link
Contributor

andig commented Aug 19, 2020

Sollte es auch eine Umgebungsvariable geben, die steuert, ob doctrine starten soll?

Eigentlich nciht. Die Idee ist ja dass der Anwender genau nicht entscheiden muss ob die DB initialisiert werden muß?

@StefanSchoof
Copy link
Contributor Author

Aktuell startet das Dockerfile nicht doctrine

CMD /vz/vendor/bin/ppm start -c /vz/etc/middleware.json --static-directory /vz/htdocs --cgi-path=/usr/local/bin/php

Um das zu erreichen muss in der docker-compose file doctrine als command aufgeführt werden.

Nach meinen Verständnis ist die docker-compose Datei, nur ein Beispiel. z.B. die Datenbank speichert die Daten nur im container, so das beim recreate Daten verloren gehen. Wenn ich nun mein docker-compose baue, muss ich die Zeile aus dem docker-compose kopieren.

Daher würde ich es schöner finden, wenn der doctrine Befehl in dem dockerfile drin wäre. Da ich mir verstellen kann das nicht jeder ein Datenbank Schema Update beim Container start machen will, ist die Idee das über eine Umgebungsvariable beim dockerfile zu machen und nicht im compose.

@andig
Copy link
Contributor

andig commented Aug 20, 2020

Daher würde ich es schöner finden, wenn der doctrine Befehl in dem dockerfile drin wäre. Da ich mir verstellen kann das nicht jeder ein Datenbank Schema Update beim Container start machen will, ist die Idee das über eine Umgebungsvariable beim dockerfile zu machen und nicht im compose.

Kannst Du gerne machen. Da das docker-compose aber nur ein Beispiel ist sollte das Beispiel am Ende so gestrickt sein, dass Doctrine auch ausgeführt wird. Wie wär mir eigentlich egal- aktuell zeit das mehr was passieren müsste.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants