Freigeben über

Empfohlene Vorgehensweisen für die Persistenz

Dieses Dokument behandelt bewährte Methoden für workflowdesign und -konfiguration im Zusammenhang mit der Workflowpersistenz.

Entwurf und Implementierung dauerhafter Workflows

Im Allgemeinen arbeiten Workflows in kurzen Zeiträumen, die sich mit Zeiten abwechseln, in denen der Workflow inaktiv ist, weil er auf ein Ereignis wartet. Dieses Ereignis kann z. B. eine Nachricht oder ein Ablaufzeitgeber sein. Damit die Workflowinstanz beim Leerlauf entladen werden kann, muss der Diensthost die Workflowinstanz beibehalten. Dies ist nur möglich, wenn sich die Workflowinstanz nicht in einer Zone ohne Persistenz befindet (z. B. warten, bis eine Transaktion abgeschlossen ist, oder auf einen asynchronen Rückruf warten). Damit eine Leerlauf-Workflowinstanz entladen werden kann, sollte der Workflowautor Transaktionsbereiche und asynchrone Aktivitäten nur für kurzlebige Aktionen verwenden. Insbesondere sollten Verzögerungsaktivitäten in Zonen ohne Persistenz so wenig Zeit wie möglich in Anspruch nehmen.

Ein Workflow kann nur beibehalten werden, wenn alle vom Workflow verwendeten Datentypen serialisierbar sind. Darüber hinaus müssen benutzerdefinierte Typen, die in persistierten Workflows verwendet werden, mit NetDataContractSerializer serialisierbar sein, damit sie von SqlWorkflowInstanceStore beibehalten werden können.

Beim einem Host- oder Computerausfall können Workflowinstanzen, die nicht beibehalten wurden, nicht wiederhergestellt werden. Im Allgemeinen wird empfohlen, eine Workflowinstanz frühzeitig im Lebenszyklus des Workflows beizubehalten.

Bei Workflows, die über einen langen Zeitraum ausgelastet sind, wird empfohlen, die Workflowinstanz in diesem Zeitraum regelmäßig persistent zu speichern. Sie können dies tun, indem Sie Persist Aktivitäten während der gesamten Abfolge von Aktivitäten hinzufügen, um die Workflowinstanz beschäftigt zu halten. Auf diese Weise führen Anwendungsdomänenrecycling, Hostfehler oder Computerfehler nicht dazu, dass das System an den Anfang der intensiven Nutzungsperiode zurückgesetzt wird. Beachten Sie, dass das Hinzufügen von Persist Aktivitäten zu Ihrem Workflow zu einer Beeinträchtigung der Leistung führen kann.

Windows Server App Fabric vereinfacht die Konfiguration und Verwendung von Persistenz erheblich. Weitere Informationen finden Sie unter Windows Server AppFabric-Persistenz.

Konfiguration von Skalierbarkeitsparametern

Skalierbarkeits- und Leistungsanforderungen bestimmen die Einstellungen der folgenden Parameter:

Diese Parameter sollten gemäß dem aktuellen Szenario wie folgt festgelegt werden.

Szenario: Eine kleine Anzahl von Workflowinstanzen, die eine optimale Antwortzeit erfordern

In diesem Szenario sollten alle Workflowinstanzen geladen bleiben, wenn sie im Leerlauf sind. Setzen Sie TimeToUnload auf einen großen Wert. Die Verwendung dieser Einstellung verhindert, dass eine Workflowinstanz zwischen Computern wechselt. Verwenden Sie diese Einstellung nur, wenn mindestens eine der folgenden Bedingungen zutrifft:

  • Eine Workflowinstanz empfängt eine einzelne Nachricht während der gesamten Lebensdauer.

  • Alle Workflowinstanzen werden auf einem einzelnen Computer ausgeführt

  • Alle Nachrichten, die von einer Workflowinstanz empfangen werden, werden von demselben Computer empfangen.

Verwenden Sie Persist-Aktivitäten oder setzen Sie TimeToPersist auf 0, um die Wiederherstellung Ihrer Workflowinstanz nach Diensthost- oder Computerfehlern zu aktivieren.

Szenario: Workflowinstanzen sind für längere Zeit im Leerlauf

Legen Sie TimeToUnload in diesem Szenario auf "0" fest, um Ressourcen so schnell wie möglich freizugeben.

Szenario: Workflowinstanzen empfangen mehrere Nachrichten in kurzer Zeit

Legen Sie TimeToUnload in diesem Szenario auf 60 Sekunden fest, wenn diese Nachrichten von demselben Computer empfangen werden. Dadurch wird eine schnelle Abfolge des Entladens und Ladens einer Workflowinstanz verhindert. Dies sorgt auch dafür, dass die Instanz nicht zu lange im Arbeitsspeicher bleibt.

Setzen Sie TimeToUnload auf "0" und InstanceLockedExceptionAction auf "BasicRetry" oder "AggressiveRetry", wenn diese Nachrichten möglicherweise von verschiedenen Computern empfangen werden. Dadurch kann die Workflowinstanz von einem anderen Computer geladen werden.

Szenario: Workflow verwendet Verzögerungsaktivitäten mit kurzer Dauer

In diesem Szenario fragt SqlWorkflowInstanceStore regelmäßig die Persistenzdatenbank nach Instanzen ab, die aufgrund einer abgelaufenen Delay-Aktivität geladen werden sollen. Wenn SqlWorkflowInstanceStore einen Timer findet, der im nächsten Abrufintervall abläuft, verkürzt der SQL-Workflowinstanzspeicher das Abrufintervall. Die nächste Umfrage erfolgt dann direkt nach Ablauf des Timers. Auf diese Weise erreicht der SQL-Workflowinstanzspeicher eine hohe Genauigkeit für Timer, deren Ausführungsdauer das Abfrageintervall übersteigt, das durch RunnableInstancesDetectionPeriod festgelegt ist. Um eine zeitnahe Verarbeitung kürzerer Verzögerungen zu ermöglichen, muss die Workflowinstanz für mindestens ein Abrufintervall im Arbeitsspeicher bleiben.

Legen Sie TimeToPersist auf 0 fest, um die Ablaufzeit in die Persistenzdatenbank zu schreiben.

Legen Sie TimeToUnload auf RunnableInstancesDetectionPeriod oder einen längeren Zeitraum fest, damit die Instanz mindestens für ein Abfrageintervall im Speicher verbleibt.

Es wird nicht empfohlen, den RunnableInstancesDetectionPeriod Wert zu verringern, da dies zu einer erhöhten Last für die Persistenzdatenbank führt. Jeder Diensthost, der die SqlWorkflowInstanceStore verwendet, pollt die Datenbank einmal pro Erkennungszeitraum. Die Einstellung RunnableInstancesDetectionPeriod auf zu kleine Zeitintervalle kann dazu führen, dass die Leistung ihres Systems verringert wird, wenn die Anzahl der Diensthosts groß ist.

Konfigurieren des SQL-Workflowinstanzspeichers

Der SQL-Workflowinstanzspeicher weist die folgenden Konfigurationsparameter auf:

InstanceEncodingOption
Dieser Parameter weist die SqlWorkflowInstanceStore an, den Status der Workflowinstanz zu komprimieren. Die Komprimierung reduziert die Datenmenge, die in der Persistenzdatenbank gespeichert ist, und verringert den Netzwerkdatenverkehr, falls sich die Persistenzdatenbank auf einem dedizierten Datenbankserver befindet. Wenn die Komprimierung verwendet wird, sind Rechenressourcen erforderlich, um den Instanzstatus zu komprimieren und zu extrahieren. In den meisten Fällen führt die Komprimierung zu einer erhöhten Leistung.

InstanceCompletionAction
Dieser Parameter weist SqlWorkflowInstanceStore an, entweder die abgeschlossenen Instanzen beizubehalten oder zu löschen. Das Beibehalten abgeschlossener Instanzen erhöht die Speicheranforderungen der Persistenzdatenbank und führt zu größeren Tabellen, wodurch die Nachschlagezeiten der Tabelle erhöht werden. Wenn Sie abgeschlossene Instanzen nicht zum Debuggen oder Überwachen benötigen, sollte der SqlWorkflowInstanceStore so konfiguriert sein, dass abgeschlossene Instanzen gelöscht werden. Gelöschte Instanzen sollten nur beibehalten werden, wenn der Benutzer einen Prozess für die schließliche Entfernung herstellt. Beachten Sie, dass Korrelationsschlüssel nicht wiederverwendet werden können, solange sich die abgeschlossene Workflowinstanz im Instanzspeicher befindet.

RunnableInstancesDetectionPeriod
Dieser Parameter definiert das maximale Intervall, mit dem die SqlWorkflowInstanceStore Persistenzdatenbank für Instanzen abgerufen wird, die beim Ablauf einer Delay Aktivität geladen werden sollen. Wenn SqlWorkflowInstanceStore einen Timer findet, der im nächsten Abrufintervall abläuft, verkürzt es das Abrufintervall, sodass die nächste Abfrage direkt nach Ablauf des Timers stattfindet. Auf diese Weise erreicht der SQL-Workflowinstanzspeicher eine hohe Genauigkeit für Zeitgeber, deren Ausführungsdauer die RunnableInstancesDetectionPeriod übersteigt.

Es wird nicht empfohlen, den RunnableInstancesDetectionPeriodWert zu verringern, da dies zu einer erhöhten Auslastung der Persistenzdatenbank führt. Jeder Diensthost, der die SqlWorkflowInstanceStore verwendet, pollt die Datenbank einmal pro Erkennungszeitraum. Die Einstellung von RunnableInstancesDetectionPeriod auf ein zu kleines Intervall kann dazu führen, dass die Leistung Ihres Systems verringert wird, wenn die Anzahl der Diensthosts groß ist.

HostLockRenewalPeriod
Dieser Parameter definiert das Intervall, mit dem der Host seine Sperre in der Persistenzdatenbank erneuert. Durch das Kürzen dieses Intervalls wird eine schnellere Wiederherstellung der Workflowinstanzen ermöglicht, falls ein Host oder Computer fehlschlägt. Allerdings wird durch kurze Erneuerungszeiträume für Sperren die Auslastung der Persistenzdatenbank erhöht. Jeder Diensthost, der SqlWorkflowInstanceStore verwendet, wird einmal pro Verlängerungszeitraum seine Sperren in der Datenbank aktualisieren. Bei Computern mit vielen Diensthosts sollte sichergestellt werden, dass sich die Sperrerneuerungen nicht negativ auf die Systemleistung auswirken. Wenn dies der Fall ist, erwägen Sie, den HostLockRenewalPeriod zu erhöhen.

InstanceLockedExceptionAction
Wenn diese Einstellung aktiviert ist, wird von SqlWorkflowInstanceStore 30 Sekunden lang versucht, eine gesperrte Instanz erneut zu laden. Setzen Sie InstanceLockedExceptionAction auf 'BasicRetry' oder 'AggressiveRetry', wenn der Workflow mehrere Nachrichten in kurzer Zeit empfängt und diese von verschiedenen Computern empfangen werden.

Da der Lade-Wiederholungsmechanismus keinen Leistungsaufwand verursacht, solange keine Lade-Wiederholungen stattfinden, sollte InstanceLockedExceptionAction immer aktiviert sein.