User anlegen via CLI?

[bernhard]

Berechtigte Frage. Bei mir wäre das praktisch, weil ich eine SaaS app entwickle, wo sich user selbst einen Account anlegen und das Produkt testen können.

Im "schlimmsten" Fall bekomme ich also jede Minute einen neuen Kunden und damit jede Minute ein kurzes Timeout auf meinem Server... Außerdem müssen die User diese Minute abwarten. Schöner wäre, wenn die sich anmelden und dann sofort ihr Produkt nutzen können.

[v3ng]

Berechtigte Frage. Bei mir wäre das praktisch, weil ich eine SaaS app entwickle, wo sich user selbst einen Account anlegen und das Produkt testen können.

Im "schlimmsten" Fall bekomme ich also jede Minute einen neuen Kunden und damit jede Minute ein kurzes Timeout auf meinem Server... Außerdem müssen die User diese Minute abwarten. Schöner wäre, wenn die sich anmelden und dann sofort ihr Produkt nutzen können.

Ich habe einen sehr ähnlichen Anwendungsfall.

Keyhelp betreibe ich komplett headless und habe es über die API in ein eigenes Laravel Backend eingebunden.
Da hier ansonsten alles direkt ausgeführt wird, ist der einminütige delay etwas ärgerlich teilweise.

Aber das ist wohl meckern auf hohem Niveau

Allerdings - wenn es dafür eine bessere Lösung gibt, spricht doch nichts dagegen die Optionen abzuwägen und darüber zu diskutieren, das war der Hintergedanke hinter meinen Kommentaren

Aber ich stimme @Tobi voll zu, für die meisten Nutzer ist das wahrscheinlich irrelevant.

[ShortSnow]

Berechtigte Frage. Bei mir wäre das praktisch, weil ich eine SaaS app entwickle, wo sich user selbst einen Account anlegen und das Produkt testen können.

Im "schlimmsten" Fall bekomme ich also jede Minute einen neuen Kunden und damit jede Minute ein kurzes Timeout auf meinem Server... Außerdem müssen die User diese Minute abwarten. Schöner wäre, wenn die sich anmelden und dann sofort ihr Produkt nutzen können.

Und jetzt stelle ich mir vor das wäre ohne die Minute, alle 30 Sekunden ein neuer User. Dann kommen noch mehr Timeouts. Wenn ich nicht selber alles anlegen würde, hätte ich den schon auf 10 Minuten gestellt um den Reload nicht zu häufig zu haben.

Schön wäre natürlich, wenn der Reload nicht die aktiven Verbindungen kappen würde, aber das geht (noch) nicht: https://bugs.php.net/bug.php?id=60961

[Tobi]

Berechtigte Frage. Bei mir wäre das praktisch, weil ich eine SaaS app entwickle, wo sich user selbst einen Account anlegen und das Produkt testen können.

Im "schlimmsten" Fall bekomme ich also jede Minute einen neuen Kunden und damit jede Minute ein kurzes Timeout auf meinem Server... Außerdem müssen die User diese Minute abwarten. Schöner wäre, wenn die sich anmelden und dann sofort ihr Produkt nutzen können.

Das ist genau diese Art von Diskussion welche zu gar nichts führt.
Wenn das von dir skizzierte Szenario dein "schlimmstes" Szenario ist, dann kann ich (SORRY) nur müde grinsen.

Denk doch mal bitte nach.
Das würde bedeuten, dass du jeden Tag 1440 neue Kunden hast. Bereits nach einem Monat hast du 43.200 neue Kunden.
RESPEKT! <== Das meine ich ganz ernst.
Aber dann hast du ein größeres Problem als den minütlichen Refresh.
Und auch genügend Kohle für eine eigene Entwicklungsabteilung welche dir ein optimiertes Serververwaltungstool schreibt.

[v3ng]

@Tobi

Ich kann deine Beiträge gerade absolut nicht nachvollziehen.

Nur weil das dargestellte Szenario für dich uninteressant ist, oder du dahinter keinen Sinn siehst, heißt das doch nicht, dass das bei anderen Nutzern der selbe Fall ist.

Offensichtlich nutzt du Keyhelp in einer komplett anderen Form, als bernhard oder ich.

Also wenn du nichts konkretes beizutragen hast, warum sparst du dir dann nicht die Kommentare?

Der Beitrag kann ja zu OT verschoben werden, wenn das hier so ein Problem darstellt.

[Tobi]

Wie schon mehrmals erwähnt wurde liegt es an php-fpm.
Das hat nix mit KeyHelp primär zu tun.
Shortsnow hat es schon richtig gesagt.
Angenommen „Echtzeit“ wäre möglich und es sind tatsächlich 60 Requests pro Minute, dann kommt php-fpm vor lauter Neustarts gar nicht mehr zu seiner eigentlichen Aufgabe.

Ja. Das ist genauso unrealistisch. Schon klar.

Aber zwischen diesen beiden Welten ist doch eine Minute ein super Kompromiss?

[ShortSnow]

Berechtigte Frage. Bei mir wäre das praktisch, weil ich eine SaaS app entwickle, wo sich user selbst einen Account anlegen und das Produkt testen können.

Im "schlimmsten" Fall bekomme ich also jede Minute einen neuen Kunden und damit jede Minute ein kurzes Timeout auf meinem Server... Außerdem müssen die User diese Minute abwarten. Schöner wäre, wenn die sich anmelden und dann sofort ihr Produkt nutzen können.

Das ist genau diese Art von Diskussion welche zu gar nichts führt.
Wenn das von dir skizzierte Szenario dein "schlimmstes" Szenario ist, dann kann ich (SORRY) nur müde grinsen.

Denk doch mal bitte nach.
Das würde bedeuten, dass du jeden Tag 1440 neue Kunden hast. Bereits nach einem Monat hast du 43.200 neue Kunden.
RESPEKT! <== Das meine ich ganz ernst.
Aber dann hast du ein größeres Problem als den minütlichen Refresh.
Und auch genügend Kohle für eine eigene Entwicklungsabteilung welche dir ein optimiertes Serververwaltungstool schreibt.

Naja, soweit denke ich da gar nicht, da hast Du völlig recht. Ich denke an die einfachen Dinge. Es würde schon reichen, wenn es ab und zu Spitzen gibt und das durchaus realistisch. Und da sollte meiner Meinung nach, der Puffer von einer Minute schon Minimum sein, solange das Timeout Problem besteht.

[Tobi]

Mal noch eine Sichtweise:
Wie wäre es denn wenn ihr eure Realtime-Deployments dahingehend anpasst, dass ihr mit vorbereiteten Leer-Accounts arbeitet?

Dann kann ein selbstgeschriebener Cron bei Bedarf X Leer-Accounts „auf Vorrat“ generieren und gleichzeitig die Anzahl der Reloads auf ein Minimum drücken.

[bernhard]

Danke für den Tipp, das hab ich mir auch schon überlegt!