search

mittwald / feature-requests

Sammlung von Feature-Ideen.
https://www.mittwald.de/roadmap
16 stars 0 forks source link

Besucher-Tarife im mStudio #93

Open bhuebschmittwald opened 11 months ago

bhuebschmittwald commented 11 months ago

Welches Problem möchtest du lösen? Wann tritt es auf? Als Kunde von mittwald möchte ich auch im mStudio (bzw. basierend auf mittwalds Managed Private Cloud) einen Tarif wählen können, der anhand von Projekt-Zugriffen (aka "Besucher") gebucht wird. Mich als Kunden spricht das derzeitige Tarif-Angebot aus CPU/RAM/Storage-basierten Optionen nicht an und ich wünsche mir ZUSÄTZLICHE Auswahlmöglichkeiten.

Welche Lösungsideen hast du? Einführung einer neuen Generation von Besucher-Tarifen im mStudio, die Bewährtes der CMS/Shop-Hosting Tarife und des Agentur-Servers aus dem Bestandssystem erhalten und trotzdem neue Ansätze enthalten.

aneufeld23 commented 9 months ago

Wir würden uns zusätzlich über Resellertarife analog zum Agenturserver freuen. Der Betrieb eines Servers für mehrere Kunden ist nicht praktikabel

lmrkavogt commented 9 months ago

Wir würden uns zusätzlich über Resellertarife analog zum Agenturserver freuen. Der Betrieb eines Servers für mehrere Kunden ist nicht praktikabel

Frage aus Interesse: wieso nicht? Ich hoste Kleinprojekte von Kunden bis zu 2000 Besuchern alle gemeinsam auf einem Server ohne jegliche Probleme oder Einschränkungen. Zur Trennung gibt es ja die Projekte, Live- und Dev-Versionen lege ich als Apps an.

Dass man potentiell auch mehrere Projekte in einem Server hat ist auch (soweit ich das weiß, Mittwald korrigiere mich) auch die Intention hinter dem mStudio. Ressourcen-intensive Projekte von A-Kunden könnten dann bspw auf dem proSpace liegen

aneufeld23 commented 9 months ago

letztens war ein Projekt out of memory und hat dafür gesorgt, dass der ganze Server neugestartet wird, die anderen Projekte waren in der Zeit nicht erreichbar.

Dann müsste ich die Projekte bzgl. Speicher / CPU / Memory manuell pro Projekt im Auge behalten, damit nicht ein Projekt gemeinsame Ressourcen übermäßig blockiert und andere Projekte darunter leiden.

Ersteres ist wirklich ein Problem, zweiteres ist ok bzw. lässt sich mit leben.

Dev und Live als App fand ich auch interessant, aber auch hier wird der PHP-Prozess für beide Apps genutzt und eben auch bei einem automatisierten Deployment neugestartet. Tägliche Deployments auf Dev würden eben auch immer dafür sorgen, dass der Prozess für Live neugestartet wird. Wäre eigentlich ein Feature-Request wert. Hat jetzt nicht direkt mit ProSpace vs. ProServer zu tun.

patrickhilker commented 9 months ago

Dass man potentiell auch mehrere Projekte in einem Server hat ist auch (soweit ich das weiß, Mittwald korrigiere mich) auch die Intention hinter dem mStudio. Ressourcen-intensive Projekte von A-Kunden könnten dann bspw auf dem proSpace liegen

mittwald sagt: 100% korrekt 👍🏻

Dann müsste ich die Projekte bzgl. Speicher / CPU / Memory manuell pro Projekt im Auge behalten, damit nicht ein Projekt gemeinsame Ressourcen übermäßig blockiert und andere Projekte darunter leiden.

Beim Space-Server passiert das prinzipbedingt, das ist richtig. Für solche Fälle haben wir den proSpace gedacht - da beeinflussen deine Projekte sich nicht gegenseitig.

Dev und Live als App fand ich auch interessant, aber auch hier wird der PHP-Prozess für beide Apps genutzt und eben auch bei einem automatisierten Deployment neugestartet. Tägliche Deployments auf Dev würden eben auch immer dafür sorgen, dass der Prozess für Live neugestartet wird

Das finde ich spannend - bisher haben wir keine Kundenstimmen gehört, bei denen das zu Problemen führt. Wenn du magst, mach wirklich gerne einen Feature Request dazu auf, um ein bisschen mehr dazu zu erzählen, oder schreibs einfach hier rein. :-)

aneufeld23 commented 9 months ago

Probleme direkt haben wir auch nicht bemerkt. Fühlt sich nur falsch an. Um den Opcache und APCU zu leeren haben wir beim Agenturserver beim Deployment mit cachetool gearbeitet. Da wurde direkt die fpm.sock angesprochen

Beim mstudio gibt es laut Support diese Möglichkeit nicht, hier haben wir dann wie auch im Mittwald Developerportal empfohlen 'touch ~/.config/php/php.ini' genutzt. Allerdings laufen da alle Apps des Projects mit der gleichen PHP-Version drüber. Das heißt der FPM Prozess wird komplett neugestartet und die Caches würden sich für den Live neu aufbauen, obwohl das in dem Moment überhaupt nicht nötig wäre.

patrickhilker commented 9 months ago

Also falls es dir wichtig ist, wäre ein kleiner Workaround notwendig (ungetestet):

Zunächst erzwingst du mehrere PHP-FPM-Prozesse: Installiere dir in deine Apps eine beliebige Systemsoftware, die du gar nicht brauchst und für die mindestens zwei Versionen zur Verfügung stehen (z.B. Node.js 18 und 20). Für jede App wählst du eine andere Systemsoftware-Version. In diesem Moment teilen wir im Hintergrund die Environments auf, was zu mehr FPM-Prozessen führt. Benötigt dann allerdings etwas mehr Ressourcen auf deinem Server, da u.a. PHP-FPM dann logischerweise (und gewollt) doppelt läuft.

Nochmal als Beispiel:

Anschließend benötigst du ein kleines PHP-Script, das deinen OPcache und APCu leert. Das führst du während des Deployments über die SSH-Verbindung der App, deren Caches du leeren möchtest, aus (Achtung, ungetestet!):

<?php
opcache_reset();
apcu_clear_cache();

Theoretisch sollte diese Vorgehensweise funktionieren - entscheide selbst, ob es den Aufwand wert ist.

Grundsätzlich versuchen wir durch das Zusammenfassen der Apps Ressourcen einzusparen, wodurch auch mehr Projekte auf dem Server möglich sind. Darum soll das hier bitte explizit nicht als Empfehlung gesehen werden. 😄

martin-helmich commented 9 months ago

Um den Opcache und APCU zu leeren haben wir beim Agenturserver beim Deployment mit cachetool gearbeitet. Da wurde direkt die fpm.sock angesprochen

@aneufeld23 Ich muss mich gerade mal kurz einklinken: Zugriff auf den FPM-Socket gibt es auch in den mStudio-Tarifen; dort läuft FPM allerdings nicht auf einem UNIX-Socket, sondern auf TCP-Port 9000. Mit --fcgi=127.0.0.1:9000 funktioniert cachetool also auch weiterhin wie gewohnt (gerade getestet).

@patrickhilker Vielleicht könnten wir cachetool ja sogar standardmäßig (und dann gleich passig vorkonfiguriert) in die Projektumgebungen werfen; was meinst du?

Der Hinweis im Dev-Portal (mit dem touch auf die php.ini) geht auf meine Kappe -- ehrlicherweise hatte ich cachetool dabei gar nicht auf dem Schirm. Ich erweitere den Artikel mal. 🙂

lmrkavogt commented 9 months ago

Wir sind vom Thema Besucher-Tarife jetzt doch etwas abgewichen wenn ich hier mal Störenfried sein darf 😅😂😂

maikbehring commented 8 months ago

@aneufeld23 Ich frage nochmal nach. Ist der proSpace eine Lösung für dich? Also ein Server pro Kunde? Wobei ich anmerken muss dass CMS Hosting ab 12 Euro startet und der ProSpace ab 32 Euro. Ist das eventuell ein Hinderungsgrund für dich?

aneufeld23 commented 8 months ago

muss ich hier intern abklären. klar prinzipiell schon, nur weicht die preisstruktur dann eben stark zu den agenturserverpreisen ab. und eben das thema, um das es hier am anfang ging. es ist aktuell schlecht für uns vergleichbar. Besucher vs Ram/CPU.