Lang laufende Workflows in Sharepoint, blockieren sie den w3wp-Prozess

Question

Wir haben eine WSS 3.0-Installation mit Search Server, der zur Suche nach Dokumenten und zum Speichern der Suchdefinition verwendet wird, um die Suche später zu wiederholen. Die Benutzer möchten die Möglichkeit haben, alle Dateien in ihren Suchergebnissen als eine einzige Zip-Datei herunterzuladen.

Ich habe eine sehr einfache Lösung, bei der das Zippen der Dateien im Webpart erfolgt, wenn der Benutzer auf die Schaltfläche klickt, aber wenn die Zip-Datei eine Weile braucht, um zu erstellen, muss der Benutzer warten (und ich vermute, dass alle anderen Benutzer, die auf die Website zugreifen, warten werden, weil ich mir vorstelle, dass die Komprimierung der Dokumente durch den w3wp-Prozess erfolgt).

Ich dachte, ich könnte die Erstellung der Zip-Datei stattdessen als Workflow starten und dem Benutzer erlauben, die Datei herunterzuladen, sobald der Workflow abgeschlossen ist, aber ich habe jetzt erkannt, dass Workflows auch unter dem w3wp-Prozess laufen.

Wenn die Ausführung einer Workflow-Aufgabe viel Zeit in Anspruch nimmt (z. B. wenn der Benutzer eine große Anzahl von Dokumenten zum Herunterladen ausgewählt hat), würde sich dies auf andere Benutzer der Sharepoint-Site auswirken und sie daran hindern, auf irgendwelche Seiten zuzugreifen, bis der Workflow abgeschlossen ist?

Natürlich werden wir die maximale Größe der Dokumente, die der Benutzer herunterladen kann, begrenzen, um den Rechner nicht auszuschalten, aber ich mache mir immer noch Sorgen, dass der Workflow-Prozess, unabhängig von der Begrenzung, andere Benutzer aussperren könnte. Ist dies der Fall? Gibt es bessere Vorschläge für die Erstellung einer solchen Aufgabe, die andere Benutzer nicht beeinträchtigen würde?

Danke

Answer 1

Setzen Sie eine Verzögerungsaktivität in den Arbeitsablauf vor die Aktivität, die die ZIP-Erstellung vornimmt. Dadurch wird der Workflow vom interaktiven W3WP-Prozess zum WSSTimerV3-Dienst verschoben, da er erst zu einem späteren Zeitpunkt ausgeführt werden muss.

Grüß Gott, Paul

http://blogs.msdn.com/pandrew

Answer 2

Selbst als Sie den Reißverschluss im Webpart durchgeführt haben, haben Sie andere Benutzer nicht blockiert. Der w3wp-Worker-Thread, der die Anforderung verarbeitete, war blockiert, während alle anderen Worker-Threads weiterarbeiten konnten.

Dies könnte jedoch zu einem Skalierungsproblem führen, wenn viele Threads auf die Verarbeitung warten: Eingehende Anfragen könnten blockiert werden, während die Worker-Threads warten, bis sie verfügbar werden. Das ist ein Grund für die Verwendung asynchroner Verarbeitung in ASP.NET.

Die Verwendung eines Workflows war hilfreich, da der Workflow gestartet und der Antrag abgeschlossen wurde, so dass andere Anträge bearbeitet werden konnten.

Sie waren besorgt über den in w3wp laufenden Workflow. Ich weiß jedoch nicht, ob er in einem der Worker-Threads von w3wp ausgeführt wurde. Ich weiß nicht, wie SharePoint seinen Workflow-Host konfiguriert, aber ich vermute, dass er einen anderen Satz von Threads verwendet.

Um dies herauszufinden, sollten Sie einige Belastungstests durchführen. Erstellen Sie ein Dummy-Webpart, das einfach ein Zip ausführt, sobald Sie die Seite, die es enthält, aufrufen. Führen Sie einen Lasttest für diese Seite durch und finden Sie heraus, wie viele Anfragen Sie erhalten können, bevor sich eine Warteschlange bildet, die darauf wartet, dass Worker-Threads verfügbar werden. Dann machen Sie dasselbe, aber lassen Sie das Webpart den Workflow starten. Prüfen Sie auch hier, wie viele Anfragen Sie gleichzeitig ausführen können, bevor sich die Anfragen in der Warteschlange stauen.

Answer 3

1. Wenn das Zippen weniger als 5 Sekunden dauert, würde ich es einfach synchron in demselben Thread machen und damit fertig sein. Geringste Komplexität, beste Benutzererfahrung, keine Blockierung anderer Benutzer (begrenzt durch die Größe des ASP.NET-Thread-Pools). Ein Haufen Klicks wird den Server allerdings lahmlegen.

2. Wenn Sie große Dateien oder viel Verkehr haben, könnten Sie eine First In First Out Warteschlange in einer Datenbank und lassen sie von einem Windows-Dienst herausnehmen und ausführen. Auf diese Weise haben Sie die Kontrolle über die Anzahl der Threads, die zum Zippen von Dateien verwendet werden. Diese Lösung bietet eine algorithmische Komplexität von O(1), erhöht aber die Komplexität des Entwurfs erheblich. Sie sollten sich überlegen, ob Sie nicht etwas wie AJAX verwenden wollen, um dem Benutzer mitzuteilen: "Sie sind 4 von 45 in der Warteschlange...".

3. Wenn die Dateigrößen stark variieren, sollten Sie die ersten beiden Lösungen als Strategien implementieren und eine dritte adaptive Strategie anwenden, die eine der zuvor genannten Strategien vorzieht, indem sie Dinge wie die Größe der entpackten Datei und die Verfügbarkeit von Serverressourcen berücksichtigt. Ein guter Kompromiss zwischen Benutzerfreundlichkeit und Ressourcenverfügbarkeit, aber die komplexeste (teuerste) Lösung.

Groete, Hans