Einschätzen der Leistungs- und Kapazitätsanforderungen für Workflows in SharePoint Server 2010

 

Gilt für: SharePoint Server 2010

Letztes Änderungsdatum des Themas: 2016-11-30

Dieser Artikel zur Leistungs- und Kapazitätsplanung bietet Informationen zu den Auswirkungen, den Workflows auf Topologien haben, in denen Microsoft SharePoint Server 2010 ausgeführt wird.

Allgemeine Informationen zur Kapazitätsplanung für SharePoint Server 2010 finden Sie unter Leistungs- und Kapazitätsverwaltung (SharePoint Server 2010).

Inhalt

  • Testfarmmerkmale

  • Testergebnisse

  • Empfehlungen

  • Problembehandlung

Testfarmmerkmale

In den folgenden Abschnitten werden die Merkmale der Testfarm beschrieben.

  • DataSet

  • Arbeitsauslastung

  • Hardware, Einstellungen und Topologie

DataSet

Zum Erfassen von Bezugswerten wurden die meisten Tests auf eine standardmäßige Teamwebsite in einer einzelnen Websitesammlung in der Farm angewendet. Bei den manuellen Starttests wurden Workflows mithilfe einer Liste mit 8000 Elementen gestartet.

Arbeitsauslastung

Anhand von Tests dieses Szenarios kann eingeschätzt werden, wie unterschiedliche Farmkonfigurationen auf Änderungen an den folgenden Variablen reagieren:

  • Auswirkung der Anzahl der Front-End-Server auf den Durchsatz beim manuellen Starten deklarativer Workflows auf mehreren Computern

  • Auswirkung der Anzahl der Front-End-Server auf den Durchsatz beim automatischen Starten deklarativer Workflows für die Erstellung von Elementen auf mehreren Computern

  • Auswirkung der Anzahl der Front-End-Server auf den Durchsatz beim Ausführen von Aufgaben auf mehreren Computern

Die in diesem Artikel genannten spezifischen Kapazitäts- und Leistungsangaben weichen von den Werten in tatsächlichen Umgebungen ab. Die hier dargestellten Werte sollen einen Ausgangspunkt für die Entwicklung einer ordnungsgemäß skalierten Umgebung bilden. Nachdem Sie den ersten Systementwurf erstellt haben, testen Sie die Konfiguration, um zu ermitteln, ob sie die Faktoren in Ihrer Umgebung unterstützt.

In diesem Abschnitt werden die Testszenarien definiert und der jeweilige Testprozess für jedes Szenario erläutert. Ausführliche Informationen wie Testergebnisse und spezifische Parameter sind nachfolgend in diesem Artikel im jeweiligen Testergebnisabschnitt aufgeführt.

Testname Testbeschreibung

Durchsatz beim manuellen Starten von Workflows

  1. Ordnen Sie den enthaltenen MOSS-Genehmigungsworkflow einer Liste zu, die eine einzelne Aufgabe erstellt.

  2. Füllen Sie die Liste mit Listenelementen auf.

  3. Rufen Sie die Webdienstmethode StartWorkflow in Workflow.asmx für die Elemente in der Liste fünf Minuten lang auf.

  4. Berechnen Sie den Durchsatz, indem Sie die Anzahl der laufenden Workflows untersuchen.

Durchsatz beim automatischen Starten von Workflows, wenn ein Element erstellt wird

  1. Ordnen Sie den enthaltenen MOSS-Genehmigungsworkflow einer Liste zu, die eine Aufgabe erstellt. Legen Sie den automatischen Start fest, wenn ein Element erstellt wird.

  2. Erstellen Sie fünf Minuten lang Elemente in der Liste.

  3. Berechnen Sie den Durchsatz, indem Sie die Anzahl der laufenden Workflows untersuchen.

Durchsatz beim Abschließen von Workflowaufgaben

  1. Ordnen Sie den enthaltenen MOSS-Genehmigungsworkflow einer Liste zu, die eine Aufgabe erstellt. Legen Sie den automatischen Start fest, wenn ein Element erstellt wird.

  2. Erstellen Sie Elemente in der Liste.

  3. Rufen Sie die Webdienstmethode AlterToDo in Workflows.asmx für die Elemente in der Aufgabenliste auf, die von den gestarteten Workflows erstellt wurden.

  4. Berechnen Sie den Durchsatz, indem Sie die Anzahl der abgeschlossenen Workflows untersuchen.

Hardware, Einstellungen und Topologie

In den Topologien, die für diese Tests verwendet wurden, wurden ein Einzelcomputer für die Inhaltsdatenbank sowie ein bis vier Front-End-Computer mit der Standardinstallation von SharePoint Server 2010 genutzt. Wenngleich die Workflows, die in diesen Tests verwendet wurden, in Microsoft SharePoint Foundation 2010 nicht verfügbar sind, können die Ergebnisse zum Einschätzen ähnliche Szenarien in diesen Bereitstellungen dienen. Das DataSet für diese Tests enthält eine einzelne Websitesammlung mit einer einzelnen Website, die auf der Vorlage Teamwebsite für eine einzelne Inhaltsdatenbank basiert.

Zum Erzielen eines hohen Maßes an detaillierten Testergebnissen wurden verschiedene Farmkonfigurationen für die Tests verwendet. Die Farmkonfigurationen reichten von einem bis zu vier Webservern und einem einzelnen Computer mit Microsoft SQL Server 2008. Die Tests erfolgten mit einem Clientcomputer. Der Datenbankserver und alle Webserver hatten ein 64-Bit-Betriebssystem, der Clientcomputer ein 32-Bit-Betriebssystem.

In der folgenden Tabelle ist die jeweilige Hardware für die Tests aufgelistet.

Webserver Datenbankserver

Prozessor

2px4c@2,33 GHz

4px4c@2,4 GHz

Arbeitsspeicher (RAM)

4 GB

16 GB

Betriebssystem

Windows Server 2008 R2 x64

Windows Server 2008 R2 x64

Speicherkapazität

680 GB

4,2 Terabyte

Anzahl der Netzwerkadapter

2

2

Geschwindigkeit des Netzwerkadapters

1 Gigabit

1 Gigabit

Authentifizierung

NTLM

NTLM

Softwareversion

4747

SQL Server 2008 R1

Anzahl der SQL Server-Instanzen

1

1

Lastenausgleichstyp

Kein Lastenausgleich

Kein Lastenausgleich

Protokollierebene des vereinheitlichten Protokollierungsdiensts (ULS)

Mittel

Mittel

Topologie für die Workflowkapazitätsplanung

Topologie für die Workflowplanung

Testergebnisse

Die folgenden Tabellen enthalten die Testergebnisse für Workflows in SharePoint Server 2010. Bei jeder Testgruppe wurden nur bestimmte Variablen geändert, um die Auswirkungen auf die Farmleistung schrittweise darzulegen.

Alle in diesem Artikel beschriebenen Tests wurden ohne Reaktionszeit, d. h. eine natürliche Verzögerung zwischen aufeinander folgenden Vorgängen durchgeführt. In der Praxis folgt auf jeden Vorgang eine Verzögerung, wenn der Benutzer den nächsten Schritt in der Ausgabe ausführt. Im Gegensatz dazu folgte bei den Tests auf jeden Vorgang unmittelbar der nächste, was zu einer fortlaufenden Last der Farm führte. Diese Last kann zu Datenbankkonflikten und anderen Faktoren führen, die sich negativ auf die Leistung auswirken können.

Auswirkung der Skalierung der Webserver auf den Durchsatz

Die folgenden Durchsatztests wurden mithilfe des Genehmigungsworkflows ausgeführt, der in SharePoint Server 2010 enthalten ist. Die Workflowzuordnung weist eine Aufgabe zu, und alle Instanzen werden für eine einzelne Liste ausgeführt. Jede Instanz dieses Workflows erstellt in der Inhaltsdatenbank Folgendes:

  • Einen Eintrag in der Tabelle Workflows zum Speichern des Workflowstatus

  • Fünf sekundäre Listenelemente (ein Aufgaben- und vier Verlaufselemente)

  • Vier Ereignisempfänger zum Verarbeiten von Ereignissen für das übergeordnete Element und die Aufgabe des Workflows

Der Schwellenwert für Workflowverschiebung wurde auf einen sehr hohen Wert festgelegt, sodass Workflowvorgänge nie in Warteschlangen eingereiht wurden. Jeder Test wurde fünfmal fünf Minuten lang ausgeführt.

Durchsatz bei manuellem Start

Der Test in der folgenden Tabelle veranschaulicht, wie sich das Hinzufügen von Front-End-Servern auf den Durchsatz beim synchronen Starten von Workflows über den Webdienst auswirkt. Dieser Test wurde mit einer Benutzerlast von 25 gleichzeitigen Benutzern, die durchgängig die StartWorkflow-Methode in Workflow.asmx aufriefen, und keiner weiteren Last für die Farm durchgeführt. Die Benutzerlast war die optimale Last, bevor nicht verarbeitete Webanforderungen auftraten. Die Liste wurde vorab mit bis zu 8000 Elementen aufgefüllt.

Topologie Genehmigungsworkflow – Maximale Anzahl der Anforderungen pro Sekunde

1x1

14,35

2x1

24,08

3x1

29,7

4x1

30,77

Die folgende Abbildung zeigt, wie sich der Durchsatz ändert. Das Hinzufügen von Front-End-Servern wirkt sich nicht unbedingt linear auf den Farmdurchsatz aus, sondern weist bei drei bis vier Front-End-Servern Spitzen auf. Zusammenfassend ist der maximale Durchsatz beim manuellen Starten von Workflows ca. 30 Workflows pro Sekunde. Das Hinzufügen von mehr als vier Front-End-Servern hat voraussichtlich keine wesentlichen Auswirkungen.

Durchsatz bei manuellem Start

Durchsatz bei manuellem Start

Durchsatz beim automatischen Starten von Workflows, wenn Elemente erstellt werden

Der Test in der folgenden Tabelle veranschaulicht, wie sich das Hinzufügen von Front-End-Servern auf den Durchsatz beim automatischen Starten von Workflows auswirkt, wenn Elemente erstellt werden. Dieser Test wurde mit einer Benutzerlast von 150 gleichzeitigen Benutzern, die durchgängig den Listenwebdienst zum Erstellen neuer Listenelemente in einer einzelnen Liste aufriefen, und keinen weiteren Vorgängen auf dem Server durchgeführt. Die Liste war anfänglich leer.

Topologie Genehmigungsworkflow – Maximale Anzahl der Anforderungen pro Sekunde

1x1

13,0

2x1

25,11

3x1

32,11

4x1

32,18

Die folgende Abbildung zeigt, wie sich der Durchsatz ändert. Der Durchsatz ist sehr nah an dem bei den manuellen Startvorgängen. Ähnlich wie beim manuellen Starttest liegt der Spitzendurchsatz bei ca. drei bis vier Front-End-Servern bei maximal ca. 32 Workflows pro Sekunde. Das Hinzufügen von mehr als drei oder vier Front-End-Servern hat keine wesentlichen Auswirkungen.

Durchsatz bei automatisch gestarteten Workflows

Durchsatz von automatisch gestarteten Workflows

Durchsatz beim Abschließen von Aufgaben

Der Test in der folgenden Tabelle veranschaulicht, wie sich das Hinzufügen von Front-End-Servern auf den Durchsatz beim Abschließen von Workflowaufgaben auswirkt. Die Aufgabenliste, die von den automatisch gestarteten Workflows im vorherigen Test verwendet wurde, diente zum Abschließen von Aufgaben. Dieser Test wurde mit einer Benutzerlast von 25 gleichzeitigen Benutzern, die durchgängig die AlterToDo-Methode in Workflow.asmx aufriefen, und keinen weiteren Vorgängen auf dem Server durchgeführt. Die Liste war anfänglich leer.

Topologie Genehmigungsworkflow – Maximale Anzahl der Anforderungen pro Sekunde

1x1

13,5

2x1

23,86

3x1

27,06

4x1

27,14

Die folgende Abbildung zeigt, wie sich der Durchsatz ändert. Ähnlich wie beim manuellen Starttest liegt der Spitzendurchsatz bei ca. drei bis vier Front-End-Servern bei maximal ca. 32 Workflows pro Sekunde. Das Hinzufügen von mehr als drei Front-End-Servern hat keine wesentlichen Auswirkungen.

Durchsatz beim Abschließen von Aufgaben

Aufgabenfertigstellungsdurchsatz

Auswirkung der Listengröße und Anzahl der Workflowinstanzen auf den Durchsatz

Der Test in der folgenden Tabelle verdeutlicht, wie sich der Durchsatz ändert, wenn die Listengröße und Anzahl der Workflows zunimmt. Die Datenauffüllung erfolgte durch fortlaufendes Ausführen des Tests des automatischen Startens von Workflows, bis in der Liste eine Million Elemente erstellt wurden. Der Vorgang wurde an verschiedenen Prüfpunkten im Test angehalten, um wie bei den Hauptdurchsatztests Durchsatzmessungen vorzunehmen. Die Tests wurden in einer 4x1-Topologie durchgeführt.

Zum Gewährleisten der Zuverlässigkeit der Datenauffüllung musste das Einreihen von Workflows in Warteschlangen aktiviert bleiben, um zu vermeiden, dass die maximale Anzahl von Verbindungen auf dem Datenbankserver erreicht wurde. Wenn keine Verbindungen verfügbar sind und ein Workflowvorgang keine Verbindung mit der Inhaltsdatenbank herstellen kann, ist das Ausführen des Vorgangs nicht möglich. Weitere Informationen zum Einreihen von Workflows in Warteschlangen finden Sie unter Empfehlungen.

Anzahl der Elemente oder Workflows Basislösung – Maximale Anzahl von Anforderungen pro Sekunde

0

32,18

10

32

1000

28,67

10.000

27,16

100.000

16,98

1.000.000

9,27

Durchsatz bei automatischem Start von Workflows bei ansteigender Anzahl von Elementen und Workflows

Durchsatz bei ansteigender Anzahl von Elementen und Workflows

Bei einer einzelnen Liste, Aufgabe und Verlaufsliste steigt der Durchsatz zwischen 1000 und 100.000 Elementen stetig an. Dahinter nimmt die Verschlechterungsrate jedoch ab. Die Verschlechterung des Durchsatzes ist auf viele Faktoren zurückzuführen.

Ein Faktor ist die Anzahl der Zeilen, die vielen Tabellen in der Inhaltsdatenbank pro Instanz hinzugefügt werden. Wie zuvor erwähnt, erstellen Workflows mehrere Listenelemente zusätzlich zu Ereignisempfängern, die von jeder Workflowinstanz registriert werden. Wenn sich eine Tabelle in verschiedenen Bereichen vergrößert, erfolgt das Hinzufügen immer langsamer, was zu einer wesentlicheren Verschlechterung als bei nur der Erstellung von Listenelementen führt.

Die Größe der Aufgabenliste trägt zum Erhöhen der Verarbeitungslast bei. Beim Vergleich des Durchsatzes für Workflows, die für neue Listen im Gegensatz zu neuen Aufgabenlisten ausgeführt wurden, hatten Aufgabenlisten negativere Auswirkungen auf die Leistung. Der Grund ist, dass für Aufgabenlisten mehr Ereignisempfänger als für die übergeordneten Listenelemente registriert werden. In der folgenden Abbildung werden die Unterschiede veranschaulicht.

Durchsatz bei unterschiedlichen Listenkonfigurationen (pro Sekunde gestartete Workflows) Aufgabenliste mit Millionen Elementen Leere Aufgabenliste

Liste mit Millionen Elementen

9,27

12

Leere Elementliste

9,3

13

Wenn Sie wissen, dass viele Workflows für große Listen ausgeführt werden, und Sie mehr Durchsatz benötigen als anhand Ihrer Tests möglich ist, prüfen Sie, ob Ihre Aufgabenlisten zwischen Workflowzuordnungen aufgeteilt werden können.

Empfehlungen

In diesem Abschnitt finden Sie allgemeine Empfehlungen zu Leistung und Kapazität. Bestimmen Sie anhand dieser Empfehlungen die Kapazitäts- und Leistungsmerkmale der vorhandenen Ausgangstopologie, um zu bestimmen, ob diese horizontal oder vertikal skaliert werden muss.

Spezifische Informationen zu den Mindest- und empfohlenen Systemanforderungen finden Sie unter Hardware- und Softwareanforderungen (SharePoint Server 2010).

Horizontal skalierte Topologien

Sie können den Workflowdurchsatz steigern, indem eine horizontale Skalierung auf bis zu vier Webserver durchgeführt wird. Das Hinzufügen weiterer Webserver führt zu keiner Leistungssteigerung. Der Workflowdurchsatz kann mithilfe leistungsbezogener Workfloweinstellungen eingeschränkt werden. Diese Einstellungen werden unter Einreihen von Workflows in Warteschlangen und leistungsbezogene Einstellungen detailliert beschrieben.

Einschätzen von Durchsatzzielen

Viele Faktoren können sich auf den Durchsatz auswirken. Dazu zählen die Anzahl der Benutzer sowie Typ, Komplexität und Häufigkeit von Benutzervorgängen. Komplexere Workflows, bei denen oft auf die Inhaltsdatenbank zugegriffen wird und mehr Ereignisse registriert werden, erfolgen langsamer als andere Workflows und benötigen mehr Ressourcen.

Der Workflow in diesem Test erstellt mehrere Einträge in der Inhaltsdatenbank, die in die Aufgabenaktivitäten integriert werden. Wenn Workflows mit einer geringen Anzahl von Aufgaben erwartet werden, können Sie ähnliche Durchsatzmerkmale erwarten. Wenn die meisten Workflows Vorgänge aufweisen, die nicht sehr verarbeitungsintensiv sind, kann der Durchsatz gesteigert werden. Sollten Ihre Workflows jedoch viele Aufgaben bzw. verarbeitungsintensive Back-End-Vorgänge enthalten, verschlechtert sich der Durchsatz meist.

Zusätzlich zum Verstehen, welche Aufgaben die Workflows erledigen, prüfen Sie, wo die Workflows ausgeführt und ob sie für große Listen ausgeführt werden, wodurch sich der Durchsatz mit der Zeit verschlechtert.

SharePoint Server 2010 kann auf vielfältige Weise bereitgestellt und konfiguriert werden. Deshalb ist es nicht einfach abzuschätzen, wie viele Benutzer von einer bestimmten Anzahl von Servern unterstützt werden können. Führen Sie deshalb in Ihrer eigenen Umgebung Tests durch, bevor Sie SharePoint Server 2010 in einer Produktionsumgebung bereitstellen.

Einreihen von Workflows in Warteschlangen und leistungsbezogene Einstellungen

Das Workflowsystem arbeitet mit Warteschlangen, um die workflowbezogene Belastung von Farmressourcen und Inhaltsdatenbank zu steuern. Wenn die Anzahl der Workflows, die auf eine Datenbank angewendet werden, einen vom Administrator festgelegten Schwellenwert erreicht, werden nachfolgende Workflowvorgänge der Warteschlange hinzugefügt, die vom Workflowtimerdienst verwaltet wird. Dieser Dienst empfängt über Zeitgeberaufträge minütlich einen Batch von Workflow-Arbeitsaufgaben.

Durch verschiedene sich direkt oder indirekt auf den Warteschlangenmechanismus beziehende Einstellungen können Farmadministratoren die Leistung und Skalierung für den Workflow beeinflussen. In den folgenden Abschnitten wird beschrieben, was diese Einstellungen bewirken und wie sie zum Erfüllen der Leistungsanforderungen angepasst werden können.

Grundlegende Warteschlangeneinstellungen

Farmadministratoren können die folgenden Einstellungen anpassen, um das Warteschlangensystem grundlegend zu konfigurieren:

  • Schwellenwert für Workflowverschiebung (Set-SPFarmConfig –WorkflowPostponeThreshold <ganze Zahl>)

    Die maximale Anzahl von Workflows, die für eine einzelne Inhaltdatenbank ausgeführt werden dürfen, bevor weitere Anforderungen und Vorgänge in die Warteschlange gestellt werden. In die Warteschlange gestellte Workflows haben den Status Wird gestartet. Dies ist eine für die gesamte Farm geltende Einstellung mit dem Standardwert 15. Dabei handelt es sich um die Anzahl der Workflowvorgänge, die gleichzeitig verarbeitet werden und nicht um die maximale Anzahl aktiver Workflows. Sobald Workflowvorgänge abgeschlossen sind, können nachfolgende Vorgänge ausgeführt werden.

  • Batchgröße für die Übermittlung von Workflowereignissen (Set-SPWorkflow –BatchSize <ganze Zahl>)

    Der Workflowtimerdienst unterliegt nicht dem Schwellenwert für Workflowverschiebung und ruft Batches von Arbeitsaufgaben aus der Warteschlange ab, um diese nacheinander auszuführen. Die Größe dieser Batches darf den Schwellenwert für die Verschiebung überschreiten. Die Anzahl von Arbeitsaufgaben, die der Dienst pro Ausführung empfängt, wird mithilfe der Eigenschaft BatchSize festgelegt, die pro Dienstinstanz einmal festgelegt werden kann. Ihr Standardwert ist 100. Bei Ausführung auf Anwendungsservern, die nicht als Front-End-Server konfiguriert sind, müssen für den Workflowtimerdienst in der Datei Web.config in der Konfigurationsdatenbank Workflowkonfigurationseinstellungen festgelegt werden. Dies muss in einem Skript erfolgen, das UpdateWorkflowConfigurationSettings() für das SPWebApplication-Objekt aufruft und die Einstellungen in Web.config von einem Front-End-Server kopiert.

  • Auftragshäufigkeit des Workflowtimers (Set-SPTimerJob job-workflow –schedule <Zeichenfolge>)

    Die Häufigkeit, mit der der Workflowtimerdienst ausgeführt wird, kann über Zeitgeberauftrags-Einstellungen angepasst werden. In der Standardeinstellung wird der Dienst alle fünf Minuten ausgeführt. Dies bedeutet, dass es zu einer fünfminütigen Verzögerung kommen kann, ehe die Arbeitsaufgaben ganz oben in der Warteschlange verarbeitet werden.

    Hinweis

    Geplante Arbeitsaufgaben, z. B. auch das Verstreichen des Ablaufdatums von Aufgaben, werden ebenfalls vom selben Timermechanismus ausgewählt. Deshalb werden sie um dasselbe Zeitintervall verzögert.

Über die Option Verwaltung der gemeinsamen Dienste in der Zentraladministration kann der Workflowtimerdienst auf allen Servern deaktiviert werden. In der Standardeinstellung wird dieser Dienst auf allen Front-End-Servern in der Farm ausgeführt. Jeder Auftrag durchläuft alle Webanwendungen und Inhaltsdatenbanken in der Farm.

Mithilfe der Kombination aus Schwellenwert für die Verschiebung, Batchgröße und Zeitgeberfrequenz kann die Anzahl der auf die Datenbank angewendeten Workflowvorgänge begrenzt werden. Der maximale Durchsatz hängt davon ab, wie schnell Vorgänge in die Warteschlange eingereiht werden und zur Verarbeitung die Warteschlange wieder verlassen.

Wenn sich beispielsweise bei den Standardeinstellungen, einem einzelnen Zeitgeberdienst und einer einzelnen Inhaltsdatenbank 1000 Elemente in der Warteschlange befinden, sind zehn Zeitgeberaufträge zu deren Ausführung in 50 Minuten erforderlich. Wenn Sie allerdings die Batchgröße auf 1000 und den Zeitgeberauftrag auf eine minütliche Ausführung festlegen, beginnt die Ausführung der Vorgänge nach einer Minute. Wenn Sie den Schwellenwert für Verschiebung höher festlegen, werden mehr Vorgänge synchron ausgeführt. Dadurch verringern sich die Anzahl von Anforderungen, die in die Warteschlange gestellt werden, und die Gesamtdauer der Verarbeitung dieser Workflows.

Hinweis

Es wird empfohlen, den Schwellenwert für Verschiebung nur auf maximal 200 festlegen, da gleichzeitige Workflowinstanzen in eigenen Threads ausgeführt werden und jeweils neue SQL Server-Verbindungen öffnen. Dies kann potenziell dazu führen, dass die Grenzwerte für die maximale Anzahl von Verbindungen mit dem Datenbankserver mit der Zeit erreicht werden.

Wenn Sie Workflows nicht auf Front-End-Servern ausführen möchten und wissen, dass Vorgänge nicht unmittelbar erfolgen müssen, können Sie Folgendes tun: 1.) Den Workflowtimerdienst auf die Ausführung auf ausgewählten Anwendungsservern beschränken, 2.) den Schwellenwert für Verschiebung auf einen sehr niedrigen Wert festlegen, um die Ausführung von Workflows im Timerdienst zu erzwingen, und 3.) die Batchgröße so hoch festlegen, dass Elemente schneller und häufiger empfangen werden. Wenn Sie möchten, dass Workflows im gesamten System synchroner ausgeführt werden, legen Sie den Schwellenwert für Verschiebung so hoch fest, dass Workflows nicht verschoben werden und eine unmittelbarere Auswirkung haben.

Ändern Sie diese Einstellungen zum Optimieren der gewünschten Ausführung von Workflows. Sie sollten mit verschiedenen Einstellungen experimentieren und diese testen, um sie besser an Ihre Umgebungen und Anforderungen anzupassen.

Anpassen von Einstellungen für Warteschlangen

Wenn die Farm über längere Zeiträume einer sehr hohen Workflowlast unterliegt oder es im System viele Verzögerungsereignisse gibt, die von Workflows in Warteschlangen gestellt wurden, nimmt die Anzahl von Workflowvorgängen in Warteschlangen zu. Zusätzlich zu den grundlegenden Warteschlangeneinstellungen müssen Sie ggf. die folgenden Einstellungen optimieren, damit die Warteschlange den gewünschten Status hat:

  • Batchgröße für die Übermittlung von Arbeitsaufgabenereignissen

    Die Tabelle, die das Workflowsystem für Ereignisse in Warteschlangen nutzt, ist eine Tabelle mit allgemeinen Arbeitsaufgaben, die mit anderen nicht workflowbezogenen Funktionen in SharePoint Server 2010 gemeinsam genutzt wird. Deshalb gibt es einen weiteren Zeitgeberauftrag, der nicht workflowbezogene Arbeitsaufgaben aus der Warteschlange entfernt. Ähnlich wie die Batchgröße für die Übermittlung von Workflowereignissen gibt die Batchgröße für die Übermittlung von Arbeitsaufgabenereignissen die Anzahl der nicht workflowbezogenen Arbeitsaufgaben an, die jeweils aus der Warteschlange entfernt werden.

  • Häufigkeit des Workflow-Failover-Zeitgeberauftrags

    In den seltenen Fällen, in denen Workflowereignisse nicht an eine Workflowinstanz übermittelt werden können, wird die Ereignisübermittlung für die Warteschlange als eine Failover-Arbeitsaufgabe geplant, die später wiederholt werden soll (beginnend mit 5 Minuten später, dann bei einem erneuten Fehler nach 10 Minuten, dann nach 20 Minuten usw.). Mit einem Workflow-Failover-Zeitgeberauftrag werden Failoverarbeitsaufgaben aus der Warteschlange entfernt. Diese Einstellung passt die Häufigkeit an, mit der der Failoverzeitgeber ausgeführt wird, was standardmäßig alle 15 Minuten erfolgt.

  • Batchgröße für Workflowfailover

    Vergleichbar mit den Batchgrößeneinstellungen für Workflows und Arbeitsaufgaben bestimmt diese Einstellung die Anzahl der Failoverereignisse, die jeder Failover-Zeitgeberauftrag aus der Warteschlange entfernt.

    Da viele Zeitgeberaufträge auf dieselbe Tabelle angewendet werden, können zahlreiche Elemente in Warteschlangen Datenbankkonflikte verursachen und den Durchsatz und die Zuverlässigkeit mindern. Zum Verringern von Konflikten wird Folgendes empfohlen:

    • Stimmen Sie den Schwellenwert für Verschiebung und die Batchgröße von Workflows so aufeinander ab, dass die Batchgröße klein genug bzw. die Häufigkeit von Zeitgeberaufträgen hoch genug ist, dass ein Zeitgeberauftrag ausgeführt werden kann, ehe der nächste Zeitgeberauftrag gestartet wird. Dadurch verhindern Sie das Aufkommen zu vieler paralleler Ausführungen von Zeitgeberaufträgen, die nicht beendet werden können.

    • Legen Sie zum Vermeiden von Tabellensperren die beiden Batchgrößenwerte nicht auf einen höheren Wert als 5000 fest.

Tipp

Versetzen Sie die Ausführung von Workflow-, Arbeitsaufgaben- und Failover-Zeitgeberaufträgen zeitlich, damit diese nicht immer gleichzeitig ausgeführt werden. Zum Erhalten einer großen Liste mit Workflows eigneten sich in unseren Skripts zur Datenauffüllung vier Minuten für den Workflow- und sechs Minuten für den Failover-Zeitgeberauftrag gut.

Optimieren der Skalierung für Aufgaben- und Verlaufslisten

Workflows generieren pro Instanz zahlreiche Aufgaben- und Verlaufselemente. Standardmäßig sind diese Listen indiziert, um die Skalierung zu fördern, doch mit zunehmender Größe dieser Listen lässt die Leistung stets nach. Führen Sie zum Eindämmen der Verschlechterung für verschiedene Workflowzuordnungen getrennte Verlaufs- und Aufgabenlisten, und ändern Sie diese Listen regelmäßig in den Workflowzuordnungseinstellungen, sobald Listen groß geworden sind.

Das Workflowsystem bietet auch einen täglichen Zeitgeberauftrag (job-workflow-autoclean), der Workflowinstanzen und -aufgaben für Instanzen automatisch löscht, die vor mehr als 60 Tagen beendet wurden. Lassen Sie diesen Zeitgeberauftrag aktiviert, damit die Aufgabenlisten und Ereignisse in der Aufgabenliste so bereinigt wie möglich bleiben. Falls Daten aufbewahrt werden müssen, schreiben Sie die Daten in andere Listen oder Archivspeicherorte. Workflowverlaufselemente werden von diesem Zeitgeberauftrag nicht gelöscht. Wenn Sie diese bereinigen müssen, muss dies mithilfe eines Skripts oder manuell über die Listenbenutzeroberfläche erfolgen.

Weitere Aspekte

Das Entfernen von Spalten aus Listen bewirkt einen Datenbankvorgang proportional zur Anzahl der Elemente in der Liste. Bei Entfernen von Workflowzuordnungen wird die Workflowstatusspalte aus der Liste entfernt, was bei großen Listen einen langen Vorgang auslöst. Wenn Sie wissen, dass eine Liste Millionen von Elementen enthält, legen Sie den Workflow auf Keine neuen Instanzen fest, anstatt Workflows zu entfernen.

Problembehandlung

Engpass Ursache Lösung

Datenbankkonflikte (Sperren)

Datenbanksperren hindern mehrere Benutzer am Anwenden in Konflikt stehender Änderungen an einer Datenmenge. Wenn eine Datenmenge durch einen Benutzer oder Prozess gesperrt ist, kann ein anderer Benutzer oder Prozess diese Datenmenge erst dann ändern, nachdem der erste Benutzer oder Prozess das Ändern der Daten abgeschlossen und die Sperre aufgehoben hat.

Gehen Sie wie folgt vor, um die Häufigkeit von Datenbanksperren zu reduzieren:

  • Verteilen Sie Workflows auf mehr Dokumentbibliotheken.

  • Skalieren Sie den Datenbankserver vertikal.

  • Optimieren Sie die Festplatte des Datenbankservers für Lese-/Schreibvorgänge.

Es gibt Methoden zum Umgehen des Datenbanksperrsystems in SQL Server 2005, z. B. den Parameter NOLOCK. Der Einsatz dieser Methode wird jedoch nicht empfohlen oder unterstützt, da die Möglichkeit von Datenbeschädigungen besteht.

Datenträger-E/A auf dem Datenbankserver

Wenn die Anzahl der E/A-Anforderungen an die Festplatte deren Kapazität übersteigt, werden Anforderungen in Warteschlangen gestellt. Dadurch verlängert sich die Ausführung der einzelnen Anforderungen.

Das Verteilen von Datendateien auf mehrere physische Laufwerke ermöglicht eine parallele E/A. Der englischsprachige Blog SharePoint Disk Allocation and Disk I/O (https://go.microsoft.com/fwlink/?linkid=129557&clcid=0x407) enthält nützliche Informationen zum Beheben von Problemen mit der Datenträger-E/A.

CPU-Auslastung von Webservern

Wenn ein Webserver mit Benutzeranforderungen überlastet ist, erreicht die durchschnittliche CPU-Auslastung nahezu 100 %. Dies hindert den Webserver an der schnellen Reaktion auf Anforderungen und kann auf Clientcomputern zu Timeouts und Fehlermeldungen führen.

Sie haben zwei Möglichkeiten, dieses Problem zu beheben. Sie können zum Verteilen der Benutzerlast der Farm Webserver hinzufügen oder den Webserver durch Hinzufügen schnellerer Prozessoren vertikal skalieren.

Webserver

Die folgende Tabelle enthält Leistungsindikatoren und Prozesse zum Überwachen von Webservern in einer Farm.

Leistungsindikator Betreffende Objekte Hinweise

Prozessorzeit

Alle

Zeigt den Prozentsatz der verstrichenen Zeit, den dieser Thread den Prozessor zum Ausführen von Anweisungen genutzt hat.

Arbeitsspeichernutzung

Anwendungspool

Zeigt die durchschnittliche Nutzung des Systemspeichers für den Anwendungspool. Sie müssen den zu überwachenden Anwendungspool bestimmen.

Die grundlegende Richtlinie lautet, die Spitzen bei der Arbeitsspeichernutzung für eine bestimmte Webanwendung zu bestimmen und diesen Wert plus 10 dem dazugehörigen Anwendungspool zuzuweisen.

Datenbankserver

Die folgende Tabelle enthält Leistungsindikatoren und Prozesse zum Überwachen von Datenbankservern in einer Farm.

Leistungsindikator Betreffende Objekte Hinweise

Durchschnittliche Länge der Datenträgerwarteschlange

Festplatte mit SharedServices.mdf

Durchschnittswerte größer als 1,5 pro Spindel bedeuten, dass die Schreibzeiten für diese Festplatte unzureichend sind.

Prozessorzeit

SQL Server-Prozess

Durchschnittswerte größer als 80 % bedeuten, dass die Prozessorkapazität des Datenbankservers unzureichend ist.

Prozessorzeit

Alle

Zeigt den Prozentsatz der verstrichenen Zeit, den dieser Thread den Prozessor zum Ausführen von Anweisungen genutzt hat.

Arbeitsspeichernutzung

Alle

Zeigt die durchschnittliche Nutzung des Systemspeichers.

See Also

Other Resources

Skalierbarkeit und Leistung von Workflows in Windows SharePoint Services 3.0 (https://go.microsoft.com/fwlink/?linkid=207353&clcid=0x407)