Behandlung von langen laufenden Berichten

Question

Ich arbeite an einer ASP.net-Anwendung in C# mit Sql Server 2000-Datenbank geschrieben. Wir haben mehrere PDF-Berichte, die Kunden für ihre geschäftlichen Anforderungen verwenden. Das Problem ist, dass diese Berichte eine Weile dauern (> 3 Minuten). Was normalerweise passiert, ist, wenn der Benutzer den Bericht anfordert, dass das Anforderungstimeout die Anforderung beendet, bevor der Webserver Zeit hat, die Erstellung des Berichts abzuschließen, so dass der Benutzer nie eine Möglichkeit erhält, die Datei herunterzuladen. Dann aktualisiert der Benutzer die Seite und versucht es erneut. Dadurch wird der gesamte Berichtserstellungsprozess gestartet und endet immer noch. (Nein, wir cachen gerade keine Berichte; das ist etwas, für das ich mich stark mache ...).

Wie gehen Sie mit diesen Szenarien um? Ich habe eine Idee in meinem Kopf, die beinhaltet, eine aynchrone Anfrage zu machen, um den Bericht zu erstellen und dann etwas Javascript zu haben, um den Status regelmäßig zu überprüfen. Sobald der Status anzeigt, dass der Bericht beendet ist, machen Sie eine separate Anfrage für die aktuelle Datei.

Gibt es einen einfacheren Weg, den ich nicht sehe?

Answer 1

Die Verwendung des Dateisystems hier ist wahrscheinlich eine gute Wette. Haben Sie eine Anfrage, die sofort eine URL an den Bericht-PDF-Speicherort zurückgibt. Ihr Server kann dann entweder einen externen Prozess starten oder eine Anforderung an sich selbst senden, um die Berichterstellung durchzuführen. Der Client kann den Server (unter Verwendung von http HEAD) für das PDF unter der angegebenen URL abfragen. Wenn Sie den Dateinamen der PDF-Datei von den Berichtsparametern ableiten, indem Sie entweder einen Hashwert verwenden oder die Parameter direkt in den Namen eingeben, erhalten Sie auch eine sofortige serverseitige Zwischenspeicherung.

Answer 2

Was ist mit E-Mail-Bericht an den Benutzer. Die ASP-Seite sollte nur die Anforderung zum Generieren des Berichts senden und eine Nachricht zurückgeben, dass der Bericht per E-Mail gesendet wird, nachdem die Ausführung beendet wurde.

Answer 3

Ich würde in Betracht ziehen, diesen Bericht aus der Sicht der Verarbeitung ein wenig mehr offline zu machen.

Wie beim Erstellen einer Warteschlange zum Eingeben von Berichtsanforderungen, Verarbeiten der Berichte von dort und nach Abschluss, kann eine Nachricht an den Benutzer gesendet werden.

Vielleicht würde ich sogar einen separaten Windows-Dienst für die Warteschlangenbehandlung erstellen.

Update: Senden an den Benutzer kann per E-Mail sein oder sie können eine "Berichte" -Seite haben, wo sie den Status ihrer Berichte überprüfen und sie herunterladen können, wenn sie bereit sind.

Answer 4

Die Benutzer können diesen Ansatz nicht akzeptieren, aber:

Wenn sie einen Bericht anfordern (durch einen Knopf oder einen Link zu klicken, oder was auch immer), könnten Sie die Reportgenerierung auf einem separaten Thread gestartet und re- Leite den Nutzer auf eine Seite weiter, auf der steht: "Danke, dein Bericht wird dir in ein paar Minuten per E-Mail geschickt".

Wenn der Thread fertig ist, den Bericht zu generieren, können Sie die PDF direkt per E-Mail versenden (wahrscheinlich funktioniert nicht wegen der Größe), oder speichern Sie den Bericht auf dem Server und per E-Mail einen Link an den Benutzer.

Alternativ können Sie in IIS gehen und die Zeitüberschreitung auf> 3 Minuten erhöhen.

Answer 5

Hier einige der Dinge, die ich tun würde, wenn ich dieses Problem präsentiert würde:

1- jenen Timeout Stop! Sie sind eine totale Verschwendung von Ressourcen.(Den Zeitüberschreitungswert von ASP-Seiten anzeigen)

2- Zentralisieren Sie alle Datenbankzugriffe in einem einzigen Punkt und sammeln Sie dann Statistiken darüber, welche Berichte wann von wem ausgeführt wurden und wie viel Zeit es gedauert hat. Untersuchen Sie, warum es so lange dauert, ist es wegen Bericht Komplexität? Datenreichweite? Serverlast? (Sie könnten das Ganze tatsächlich in eine CSV-Datei auf dem Server schreiben und diese Datei regelmäßig in den SQL-Server importieren, um sie später zu analysieren).

Schließlich, es wird leichter für Sie zu „Cache“, berichtet, wenn Sie durch diesen einzigen Zugangspunkt gehen (zB gleiche Abfrage gleichen Datum werden gleiche PDF zurückkehren zuvor generierten)

3- Ich weiß, das wirklich war nicht die Frage, aber haben Sie versucht, in diese Fragen einzutauchen, um zu sehen, warum sie so lange laufen müssen? Abfrageabstimmung vielleicht?

4- E-Mail/SMS/auf dem Bildschirm Meldung, wenn der Bericht bereit ist scheint groß ... wenn Ihr Benutzer in der Regel eine Charge von Bericht zu generieren, möglicherweise ein kleines Dashboard, die Progression "ihrer" Warteschlange könnte in der gebaut werden App Ein kleines Ajax-Steuerelement würde den Status regelmäßig aktualisieren. Hinweis: Wenn Sie diesen zentralen Datenbankzugriff verwendet haben und genügend Informationen darüber haben, was wann ausgeführt wird und wie lange Sie möglicherweise die Zeit abschätzen können, die es für einen dauert Bericht zum Ausführen.

Wenn die Reaktionszeit unternehmenskritisch ist, sollten bestimmte Benutzer während einiger Stunden des Tages im Datenbereich eingeschränkt sein (Datumsbereich zum Beispiel)?

Viel Glück und bitte mehr Details zu Ihrem Szenario abgeben Sie genauere Hinweise erhalten möchten ...

Answer 6

zur Abfrageoptimierung ist wahrscheinlich die beste Wahl zu starten. Obwohl ich nicht weiß, dass Sie den Bericht erstellen, sollte dieser Schritt nicht wirklich so lange dauern. Eine schlechte Abfrage auf der anderen Seite könnte Ihre Leistung absolut töten.

Je nachdem, was Sie in der Abfrage finden, müssen Sie möglicherweise einige Indizes hinzufügen oder möglicherweise sogar eine Tabelle einrichten, um die Informationen für Ihren Bericht denormalisiert zu speichern, um sie schneller verfügbar zu machen. Diese denormalisierte Tabelle könnte dann (stündlich) oder mit jeder von Ihnen gewünschten Häufigkeit aktualisiert werden (durch einen SQL Server-Job).

Wenn es ein relativ statischer Bericht ohne variierende Benutzereingabeparameter ist, wäre es auch eine gute Idee, den Bericht früher am Tag zu cachen, aber es ist schwer, mehr darüber zu sagen, ohne Ihre Situation zu kennen.

Für ein Problem wie dieses müssen Sie wirklich in der Datenbank starten, es sei denn, Sie haben Grund zu der Vermutung, dass Ihr Bericht Code des Täters erzeugt. Es gibt verschiedene Band-Hilfen, die Sie verwenden könnten, die für eine Weile helfen können, aber wenn Ihre Db die Grundursache ist, werden diese Lösungen nicht gut skalieren, und Sie werden wahrscheinlich in der Zukunft ähnliche Probleme (oder schlimmer) haben .