Opened by flowdy at 2015-06-20 16:09
User since
2012-08-03
45 Artikel
BenutzerIn
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
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,
Also habe ich bei meinen Recherchen etwas übersehen?
Vielen Dank,
flowdy
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.
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;