Konfigurieren der maximalen Anzahl von Auftragsprozessorthreads für den Project Server-Warteschlangendienst

Letztes Änderungsdatum des Themas: 2015-02-27

Mit dem Microsoft Office Project Server 2007-Warteschlangendient können Sie die maximale Anzahl von Prozessorthreads für jeden Warteschlangentyp konfigurieren.

Auf der Seite Warteschlangeneinstellungen gibt es in den Project Web Access-Servereinstellungen die Einstellung Maximale Anzahl von Auftragsprozessorthreads mit dem Standardwert 4 (für jeden Warteschlangentyp). Beim Anpassen dieser Werte müssen viele Dinge berücksichtigt werden. Zu viele Auftragsprozessorthreads können die Leistung auf dem Anwendungsserver beeinträchtigen und zu Timeout- und Speicherausnahmefehlern führen. Angenommen, ein Administrator versucht, die maximale Anzahl von Auftragsprozessorthreads für die Arbeitszeittabellen- und die Projektwartschlangen von 4 auf 10 zu erhöhen, um eine erwartete Zunahme bei den gesendeten Arbeitszeittabellen und bei den Projektupdates für den Zeitraum am Ende eines Monats zu berücksichtigen. Ohne sorgfältige Planung kann durch eine solche Zunahme die Leistung beeinträchtigt werden.

Die Warteschlange soll die Verarbeitungsgeschwindigkeit begrenzen, damit Spitzenzeiten, in denen der Server überlastet werden könnte, verteilt werden. Im Hinblick auf das Projektmanagement geht es um den Abgleich für den Server, also zu verhindern, dass der Server zu viele Aufgaben gleichzeitig auszuführen versucht.

Warteschlangen-Multithreading

Da es sich um eine Multithread-Warteschlange handelt, ist Folgendes möglich:

• Schnelle Vearbeitung von Aufträgen.

• Vermeidung der vollständigen Unterbrechung der Auftragsverarbeitung, wenn bei einem Auftrag ein Problem auftritt.

In den folgenden Tabellen wird die Reihenfolge beschrieben, in der die Aufträge in einer Singlethread-Warteschlange und einer Multithread-Warteschlange von der Warteschlange verarbeitet würden. In diesem Beispiel wurden drei Projekte in der folgenden Reihenfolge gespeichert und veröffentlicht:

1. Projekt 1 wird gespeichert und veröffentlicht.

2. Projekt 2 wird gespeichert und veröffentlicht.

3. Projekt 3 wird gespeichert.

4. Projekt 2 wird geöffnet, bearbeitet, gespeichert und erneut veröffentlicht.

In der folgenden Tabelle wird beschrieben, wie Aufträge in einer Singlethreadumgebung von der Warteschlange verarbeitet würden. Die Spaltenüberschriften T1 bis T9 bezeichnen Zeitsegmente. Alle Vorgänge würden am Ende des neunten Zeitsegments abgeschlossen. Beachten Sie, dass der erste Veröffentlichungsauftrag für Projekt 2 aus Optimierungsgründen übersprungen wird, da die Warteschlange feststellt, dass ein identischer Veröffentlichungsauftrag für Projekt 2 später ausgeführt wird. Darüber hinaus weisen Berichterstellungsaufträge für Projekt 1 und Projekt 2 eine niedrigere Priorität auf, weshalb sie später verarbeitet werden.

In der folgende Tabelle wird beschrieben, wie die Warteschlange versuchen würde, Aufträge in einer Multithreadumgebung (in diesem Beispiel drei Threads) zu verarbeiten. Mehr als die Hälfte der Zeit würde versucht, dieselben Vorgänge aus dem obigen Beispiel zu verarbeiten. Beachten Sie, dass in dieser Umgebung alle korrelierten Aufträge (z. B. alle Aufträge im Zusammenhang mit dem Speichern und Veröffentlichen für Projekt 1) im selben Thread verarbeitet werden können. Wenn ein Auftrag in der Korrelation fehlschlägt, wird möglicherweise die Verarbeitung anderer Aufträge in derselben Korrelation verhindert. Andere Aufträge in anderen Threads sind jedoch nicht davon betroffen.

Empfohlene Einstellungen

Als Ausgangspunkt empfiehlt es sich, die maximale Anzahl von Prozessorthreads basierend auf der Anzahl verfügbarer Prozessoren (oder Kerne) festzulegen. Wenn beispielsweise der Project Server-Anwendungsserver einen Single-Dual-Core-Prozessor verwendet, ist die Konfiguration von zwei Threads pro Warteschlange ein guter Ausgangspunkt. Wenn der Anwendungsserver einen Quad-Dual-Core-Prozessor verwendet, können Sie möglicherweise acht Threads pro Warteschlange verwenden. Sie können diese Einstellungen nicht nur basierend auf dem Transaktionsumfang, sondern auch basierend auf der durchschnittlichen Größe der Transaktionen entsprechend anpassen (z. B. Veröffentlichen von Projekten mit 10 Zeilen oder 1000 Zeilen).

Sie sollten auch die Farmtopologie und andere Anwendungen, die in der Serverfarm ausgeführt werden, berücksichtigen. Passen Sie beispielsweise die Einstellung entsprechend an, falls der Anwendungsserver auch als Front-End-Webserver dient oder auf dem Anwendungsserver Suchvorgänge oder andere rechenintensive Aktivitäten ausgeführt werden. Darüber hinaus können Sie Leistungsindikatoren, Anwendungsprotokolle sowie ULS-Protokolle überwachen, um Sie bei der Optimierung der Warteschlange für normale Serverlasten zu unterstützen.