Mojolicious/Hypnotoad: Horizontale Delegation zwischen Workern? (Webframeworks, Sonstige Fragen zur Webprogrammierung mit Perl)

[thread]19697[/thread]

Mojolicious/Hypnotoad: Horizontale Delegation zwischen Workern?

Tags: perl5 mojolicious hypnotoad Ähnliche Threads

Leser: 14

Articles: hide open all | hide show old branches

+5 replies
flowdy

2015-06-20 16:09
User since
2012-08-03
45 Artikel
BenutzerIn
Ich suche nach einer Möglichkeit, einem Request in Mojolicious, das betrieben wird mit Mojo::Server::Prefork oder Mojo::Server::Hypnotoad, einen Callback mitzugeben, der dann verwendet wird à la
Code: (dl )

1 2 3 4 5 6 7 8

my $user_id = $self->session("user_id"); my $user = get_user($user_id) // do { my $promise = $delegate_to_worker_that_already_knows_user->( request => $req, user_id => $user_id, otherwise_register_for => $my_worker_id ); $promise ? return : load_user("name"); ...
Zur Klärung, warum ich denke, dass ich das überhaupt benötige. Nicht auszuschließen, dass ich mir einen Knoten ins Hirn gemacht habe und ihr mir helfen könnt, das zu fixen:

Die User-Objekte in meiner Webapplikation enthalten komplizierte Datenstrukturen, deren Berechnung viel CPU-Zeit kostet, ergo für aufeinanderfolgende Requests im Speicher vorgehalten werden sollen. Storable und darauf basierende Module gehen wg. Closures leider nicht – zumindest nicht ohne Klimmzüge, die ich selbst als Code-smell betrachten würde.

Daraus ergibt sich das Problem, dass, so jedenfalls meine Befürchtung, nicht mehrere Worker Requests abarbeiten können. Wenn zwei Requests vom gleichen User nacheinander ausgelöst werden, die Modifikationen im Datenbestand vornehmen, die wiederum dazu führen, dass Teile der Datenstrukturen und Objekte neu berechnet werden müssen, so muss bei der Abarbeitung des zweiten Requests der verantwortliche Worker-Prozess irgendwie mitkriegen, dass er seine Datenstrukturen erst mal auf den aktuellen Stand bringen muss.

Klar sind Workarounds denkbar: So mit Zeitstempeln und entsprechenden Checks, ob irgendwelche Daten veraltet sind.
Aber entweder,
- es gibt nur einen Check für das ganze User-Objekt, das dann mit einer abhängig von der Zahl der Worker wahrscheinlich oft neu aufzubauen ist, was den Nutzen des Cachings im gleichen Maß einschränkt,
- oder ich muss das einzeln in relevanten Teilklassen implementieren, so dass nur veraltete Teilkomponenten des Userobjekts jeweils aktualisiert werden. Das wäre mir zu aufwendig, da der parallelisierte Betrieb nur in einem bestimmten Szenario nötig ist, das bei der Entwicklung eine nachrangige Bedeutung spielt.
Eher würde ich dann ganz auf Nebenläufigkeit verzichten. Die Software wäre dann halt nicht so skalabel, wie ich mir wünschen würde.

Also habe ich bei meinen Recherchen etwas übersehen?

Vielen Dank,
flowdy
package MyClass; sub new {\b\b\b\b\b\b\b\b\buse Moose;
- jan
  
  2015-06-20 20:21
  
  User since
  2003-08-04
  2536 Artikel
  ModeratorIn
  
  Ich kenne leider auch keine Lösung, aber als Tipp auch den IRC-Channel: #mojo on irc.perl.org
  
  Die Devs sind oft da und ansprechbar und können vermutlich am schnellsten sagen, ob irgendwas in die Richtung geht oder eher gar nicht.
- +3 replies
- Gast janus
  
  2015-06-21 19:46
  
  User-Daten haben, nachdem die Response raus ist, nichts mehr im Hauptspeicher zu suchen (Sicherheitsgründe, Privacy).
  Last edited: 2015-06-21 19:55:46 +0200 (CEST)
  - +2 replies
  - flowdy
    
    2015-06-23 20:56
    
    User since
    2012-08-03
    45 Artikel
    BenutzerIn
    
    Hallo janus,
    
    sorry, ich sehe nicht ganz, warum Daten im Hauptspeicher sicherer oder unsicherer sein sollten als auf einer (unverschlüsselten) Festplatte. Nicht zuletzt hat man zumindest bei Linux sowieso nicht die Kontrolle darüber, welche Teile der Festplatte gerade im Speicher abgelegt werden. Und ob Anbieter von In-Memory-Datenbanken verschlüsseln, ist auch nicht garantiert. Wenn das, was du sagst, also irgendwo schwarz auf weiß steht, ich meine in verlässlichen Quellen, würden mich diese durchaus interessieren.
    
    Meine Webapplikation ist in erster Linie auf den Ein-Benutzer-Betrieb ausgerichtet. Technisch folgt sie zwar dem Client/Server-Prinzip, stellt im wesentlichen aber eine lokal und individuell installierte Anwendung dar, die lediglich den Browser als Benutzerinterface verwendet.
    Warum dann überhaupt Mehrbenutzerbetrieb implementieren? Berechtigte Frage, einfache Antwort: Indem man öffentliche Server aufsetzt, gibt man Interessenten die Möglichkeit, die Software (mit Spaßdaten) ganz unverbindlich und ohne Installationsaufwand zu testen. Wer will, kann sie dann für sich betreiben. Das ist für mich echter Datenschutz: Wenn die Daten gar nicht erst verteilt werden.
    
    Gut, dann wende ich mich mal an irc.perl.org#mojo, danke für den Tipp.
    package MyClass; sub new {\b\b\b\b\b\b\b\b\buse Moose;
    - Gast janus
      
      2015-06-25 19:45
      
      Bei fastCGI oder mod_perl halte ich z.B. die Routingtable, Templates, DB-Verbindungen und bestimmte Konfigurations-Hashes im Hauptspeicher.
      
      Das Objekt jedoch, welches für den Request und fürs Ausliefern der Response zuständig ist, wird jedesmal (Req./Resp.) neu erzeugt. An diesem Objekt hängen u.a. Benutzer- sowie Sessiondaten, Letztere sind ebenfalls Benutzerdaten. Im Destroy werden ggf. Daten persistent zurückgeschrieben. Ein weiterer Request vom gleichen Benutzer ist jedoch nicht unbedingt diegleiche Session. Aber auch im Fall, es ist dieselbe Session, werden die Daten neu in den Hauptspeicher gelesen und verschwinden mit dem Destroy.
      
      Was ich mir vorstellen könnte ist, dass Objekte zu Lebzeiten miteinander kommunizieren, denn hierbei lässt sich ja festellen, welcher Benutzer die Instanz ins Leben gerufen hat und ob die Benutzer gleich sind. Bliebe noch die Frage nach Master/Slave ansonsten wirds schwierig mit der Datenkonsistenz.
      
      Nurmalso bischn laut gedacht....
      Last edited: 2015-06-25 19:47:07 +0200 (CEST)

View all threads created 2015-06-20 16:09.