Umgebung:
Benutzerszenario:
Der Benutzer gibt Suchkriterien für große Datenmengen ein. Nach dem Einleiten der Anfrage werden sie zu einer Ergebnisseite geleitet, auf der sie warten, bis die Daten geladen sind, und dann die Daten verfeinern können.
Technisches Szenario:
Nachdem der Benutzer die Suchkriterien (über den Ajax-Aufruf) gesendet hat, ruft die Benutzeroberfläche den Back-End-Dienst auf. Der Back-End-Dienst fragt Transaktionssystem (e) ab und legt die resultierenden Daten in einen db- "Cache" - eine denormalisierte Tabelle - ein, um die Daten weiter zu verfeinern (d. H. Sortieren, filtern). UI wartet, bis die Daten zwischengespeichert sind, und navigiert zu einer resultierenden Seite, nachdem sie benachrichtigt wurde, dass der Vorgang abgeschlossen ist. Die resultierende Seite ruft dann auf, um die Daten aus der denormalisierten Tabelle abzurufen.
Problem:
Die Suche ist relativ langsam (15-25 Sekunden) für große Abfragen, die letztendlich viele Systeme basierend auf den eingegebenen Kriterien abfragen müssen. Es ist relativ schnell für andere Abfragen (& lt; 4 Sekunden).
Technische Einschränkungen:
Wir können dieses Such- / Ergebnissystem nicht vollständig neu gestalten. Es gibt viel zu viele Komplexitäten zwischen der UI und dem Back-End. Die Seite ist erforderlich (aufgrund von Einschränkungen, die in StackOverflow nicht gelöst werden können), um nach der Ausführung der Suchkriterien zu drehen.
Wir können die Organisation auch nicht bitten, die Daten vor der Suche zu denormalisieren, da die Daten in Echtzeit sein müssen, dh wenn ein Benutzer eine Änderung in anderen Systemen vornimmt, müssen die Daten korrekt angezeigt werden Suche danach.
Prozess, dem ich folgen möchte:
Ich möchte ein bisschen schummeln. Ich möchte die "Cache" -Anfrage über einen asynchronen HttpHandler in einem Fire-Forget-Modell ausgeben.
Nach dem Absetzen der Abfrage möchte ich die Seite auf die resultierende Seite umstellen.
Auf der Übergangsseite möchte ich die "Cache" -Tabelle abfragen, um zu sehen, ob die Daten noch eingefügt wurden.
Der Grund, warum ich diesen Übergang sofort machen möchte, ist, dass die resultierende Seite teuer ist (selbst ohne die Daten zu erhalten) - immer noch 2 Sekunden Ladezeit, bevor man den Dienst anruft, der den Daten aus dem Cache.
Frage:
Wird der ASP.NET-Thread, der über den Async-Handler aufgerufen wird, die Verarbeitung zuverlässig fortsetzen, auch wenn ich mit einem JavaScript-Redirect von der Seite weg navigiere?
Technische Grenzen 2:
Ja, ich weiß ... Dieser Suchvorgang klingt nicht effizient. Daran kann ich momentan nichts ändern. Ich versuche, alles zu tun, um es etwas besser zu machen, während wir weiter nachforschen, wie wir es umgestalten werden.
Wenn Ihre Antwort lautet: "Werfen Sie es weg und beginnen Sie von vorne", antworten Sie bitte nicht. Das ist nicht akzeptabel.
Ja.
Es gibt die Eigenschaft Response.IsClientConnected, die verwendet wird, um zu wissen, ob ein lang andauernder Prozess noch verbunden ist. Der Grund für diese Eigenschaft ist, dass Prozesse auch dann weiter ausgeführt werden, wenn die Verbindung zum Client unterbrochen wird und sie manuell über die Eigenschaft erkannt werden müssen, und manuell heruntergefahren werden muss, wenn eine vorzeitige Unterbrechung auftritt. Es ist nicht standardmäßig, einen laufenden Prozess beim Trennen des Clients zu beenden.
Verweis auf dieses Angebot: Ссылка
update
Zugegeben, das ist eine sehr schlechte Eigenschaft, auf die man sich heutzutage mit Sockets verlassen kann. Ich rate Ihnen dringend, einen Ansatz zu machen, der es Ihnen ermöglicht, schnell eine Anfrage zu vervollständigen, die in einer Datenbank oder einer Warteschlange eine lang andauernde Aufgabe erledigt, wahrscheinlich RabbitMQ oder etwas ähnliches, das wiederum socket.io oder ähnliches verwendet, um zu aktualisieren Die Webseite oder App wird einmal fertiggestellt.
Wie wäre es, wenn Sie die asynchrone Operation in einem ASP.NET-Thread überhaupt nicht ausführen? Lassen Sie den ASP.NET-Code einen Dienst aufrufen, um die Datensuche in die Warteschlange einzureihen, und kehren Sie dann mit einem Token aus dem Dienst zum Browser zurück, wo er dann zur Ergebnisseite umgeleitet wird, die auf das abgeschlossene Ergebnis wartet? Die Ergebnisseite fragt mit dem Token des Dienstes ab.
Auf diese Weise müssen Sie sich keine Gedanken darüber machen, ob ASP.NET irgendwie erfährt, dass der Browser auf eine andere Seite gewechselt ist.
Eine andere Möglichkeit ist das Threading ( System.Threading ).
Wenn der Benutzer die Suchkriterien sendet, beginnt der Server mit der Verarbeitung der Seitenanforderung, erstellt einen neuen Thread, der für die Ausführung der Suche zuständig ist, und beendet die Antwort zurück an den Browser und leitet die Ergebnisseite weiter, während der Thread weiterhin auf dem Server ausgeführt wird Hintergrund.
Die Ergebnisseite würde weiterhin auf dem Server überprüfen, ob die Ausführung der Abfrage abgeschlossen wurde, da der gestartete Thread die Fortschrittsinformationen teilen würde. Wenn dies abgeschlossen ist, werden die Ergebnisse zurückgegeben, wenn der nächste Ajax-Aufruf von der Ergebnisseite ausgeführt wird.
Es könnte auch mit WebSockets in Betracht gezogen werden. In einem Sinne, dass der Webserver selbst dem Browser mitteilen kann, wann die Ausführung der Abfrage durchgeführt wurde, da er Vollduplex-Kommunikationskanäle anbietet.
Tags und Links javascript multithreading asp.net asynchronous httphandler