Planen der Softwaregrenzen (Project Server)

Letzte Aktualisierung: Mai 2009

 

Letztes Änderungsdatum des Themas: 2015-02-27

Inhalt dieses Artikels:

• Testumgebung

• Testergebnisse

• Richtlinien für annehmbare Leistung

Dieser Artikel enthält Informationen zum bessseren Verständnis der getesteten Leistungs- und Kapazitätsgrenzen von Microsoft Office Project Server 2007, Informationen über die Testumgebung und die Testergebnisse sowie Richtlinien für eine akzeptable Leistung. Verwenden Sie die Informationen in diesem Artikel, um zu bestimmen, ob die geplante Bereitstellung sich im Rahmen der akzeptablen Leistungs- und Kapazitätsgrenzen befindet.

Die Testergebnisse und Richtlinien in diesem Artikel gelten für eine Einzelinstallation von Office Project Server 2007. Das Hinzufügen von Servercomputern zur Installation erhöht die Kapazitätsgrenzen der in der Tabelle im Abschnitt Richtlinien für eine akzeptable Leistung aufgelisteten Websiteobjekte nicht. Andererseits wird durch das Hinzufügen von Servercomputern der Durchsatz einer Serverfarm erhöht, was bei einer großen Anzahl von Objekten zum Erreichen der akzeptablen Leistung notwendig sein kann. In einigen Fällen muss bei einer großen Anzahl von Objekten innerhalb einer Lösung möglicherweise mehr als eine Serverfarm verwendet werden.

In diesem Artikel werden die Richtlinien von der Leistung festgelegt. Mit anderen Worten, Sie können die bereitgestellten Richtlinien überschreiten, doch es kann sein, dass dadurch die Leistung beeinträchtigt wird.

Beachten Sie, dass viele Faktoren die Leistung in einer bestimmten Umgebung beeinflussen können und jeder dieser Faktoren die Leistung in verschiedenen Bereichen beeinträchtigen kann. Einige Testergebnisse und Empfehlungen in diesem Artikel beziehen sich möglicherweise auf Features oder Benutzervorgänge, die in Ihrer Umgebung nicht vorhanden sind, und gelten daher nicht für Ihre Lösung. Nur durch gründliche Tests erhalten Sie genaue Daten mit Bezug auf Ihre Umgebung.

Da Office Project Server 2007 auf Windows SharePoint Services 3,0 basiert, haben die meisten Faktoren, die sich auf die Leistung und Kapazität von Windows SharePoint Services 3,0 auswirken, auch eine Auswirkung auf Office Project Server 2007. Weitere Informationen zur Kapazitäts- und Leistungsplanung für Windows SharePoint Services 3,0 finden Sie unter Planen der Leistung und Kapazität (Windows SharePoint Services).

Testumgebung

Zum Bereitstellen ausführlicher Testergebnisse wurden für das Testen mehrere Farmkonfigurationen verwendet. Dazu gehörten ein Servercomputer, der Webserver- und Anwendungsserverrollen ausführt, ein oder zwei Clientcomputer und ein einzelner Datenbankservercomputer, auf dem die Microsoft SQL Server 2000-Datenbanksoftware ausgeführt wird. Ein Teil der Tests wurde mit einem separaten Anwendungsservercomputer durchgeführt. In der Testumgebung wurde außerdem ein dedizierter Domänencontrollercomputer eingesetzt. Alle Servercomputer hatten 32-Bit.

In der folgenden Tabelle werden die Spezifikationen der Computer aufgeführt, von denen die einzelnen Rollen in der Testumgebung ausgeführt werden.

Computerrolle	Spezifikationen
Webserver und Anwendungsserver	4 AMD Opteron 2,2 GHz (Gigahertz)-Prozessoren, 2 GB (Gigabytes) RAM
Anwendungsserver	4 AMD Opteron 2,2 GHz-Prozessoren, 2 GB RAM
Datenbankserver	4 Intel Xeon 1,5 GHz-Prozessoren, 4 GB RAM
Client	1 Pentium D 3 GHz-Prozessor, 2 GB RAM
Domänencontroller	2 Pentium III 1 GHz-Prozessoren, 512 MB (Megabytes) RAM Tipp Aufgrund der CPU- und Speicherauslastung während der Tests stellten die relativ niedrigen Spezifikationen des Domänencontrollers keinen wesentlichen Engpass dar.

Für die Farmcomputer wurde ein 100-Megabit-Ethernet-Netzwerk verwendet.

Testergebnisse

In den folgenden Diagrammen und Tabellen sehen Sie, wie die Testumgebung bei einer bestimmten Serverkonfiguration und bei bestimmten Benutzervorgängen und Lastbedingungen abgeschnitten hat. Die bereitgestellten Ergebnisse treffen auf alle ähnlichen Office Project Server 2007-Umgebungen zu.

Tipp

Zusätzliche Konfigurationen werden in Zukunft getestet. Testergebnisse werden veröffentlicht, sobald sie verfügbar sind.

Die Leistungsmetriken für verschiedene Vorgänge hängen von Faktoren wie der Größe der Projektdateien, der Anzahl der im entsprechenden Projekt vorhandenen Baselines und dem Durchsatz der Farm ab. Zum Beispiel kann es sein, dass eine kleine Projektdatei (kleiner als 1 MB) in weniger als einer Sekunde gespeichert werden kann. Das Speichern einer 50-MB-Projektdatei dagegen wird je nach Farmkonfiguration und Netzwerklatenz wahrscheinlich mehr als eine Minute erfordern.

Teststandards für die Projektgröße

In der folgenden Tabelle werden die drei verschiedenen Projektdateigrößen beschrieben, die beim Testen verwendet wurden.

Größe	Dateigröße (MB)	Anzahl der Aufgaben	Anzahl der Ressourcen	Anzahl der Zuordnungen
Klein	0,896	10	10	10
Mittel	2,03	1.420	94	1.486 Zuordnungen auf realen Ressourcen, 380 nicht zugewiesen
Groß	8,139	10.422	2	5 Zuordnungen auf realen Ressourcen, 7.693 nicht zugewiesen

Active Directory-Synchronisierung

Mit diesem Test wurde gemessen, wie die Leistung der Active Directory-Verzeichnisdienstsynchronisierung bei steigender Anzahl von Ressourcen abnimmt.

Windows SharePoint Services 3,0 bietet die zugrunde liegende Sicherheits- und Benutzerverwaltungsarchitektur für Office Project Server 2007. Zum Verwalten von Domänenbenutzern als Ressourcen in Office Project Server 2007 müssen Sie Active Directory für die Domäne mit Windows SharePoint Services 3,0 auf einem der Server in der Farm synchronisieren.

Bei der Active Directory-Synchronisierung ist keine lineare Komplexität im Hinblick auf die Anzahl der importierten Ressourcen festzustellen. Die Komplexität ist ungefähr quadratisch, und die Synchronisierung von Windows SharePoint Services 3,0 und Active Directory veranschaulicht dies. Aufgrund der Testergebnisse lässt sich schätzen, dass die Windows SharePoint Services 3,0-Synchronisierung für eine Organisation mit 20.000 Computern etwa 28 Stunden auf der Testhardware erfordern würde. Die Windows SharePoint Services 3,0-Synchronisierung für eine Organisation mit 40.000 Computern wäre in etwa 109 Stunden abgeschlossen (4,6 Tage). Beachten Sie, dass diese Schätzungen auf den für diese Tests verwendeten Hardware- und Netzwerkspezifikationen basieren.

Im Allgemeinen erfordert das Verdoppeln des Ressourcenpools fast das Vierfache der Zeit, die bei der Active Directory-Synchronisierung für eine bestimmte Farmkonfiguration und Netzwerkbandbreite benötigt wird. Unabhängig von der Hardware kann davon ausgegangen werden, dass der anfängliche Active Directory-Synchronisierungsauftrag für eine sehr große Organisation länger als einen Tag dauert.

Im folgenden Diagramm wird die Zeit angegeben, die bei einer steigenden Anzahl von Ressourcen für die Durchführung der Active Directory-Synchronisierung benötigt wird.

Weitere Informationen zur Synchronisierung von Active Directory und Office Project Server 2007 finden Sie unter Verwalten der Active Directory-Synchronisierung in Project Server 2007.

Auswirkungen der Baselines auf die Leistung

In Office Project Server 2007 ist das Speichern von mehr als 11 Baselines innerhalb eines Projekts möglich. Die steigende Anzahl von Baselines in einem Projekt wirkt sich auf verschiedene Weise auf die Leistung aus. Es wurden Tests durchgeführt, um die Auswirkung zu ermitteln, die das Speichern einer steigenden Anzahl von Baselines für kleine, mittlere und große Projekte hat.

In den von uns durchgeführten Tests scheinen die Dateigrößen und die Größenzunahme des virtuellen Speichers im Hinblick auf die Anzahl der in einem Projekt gespeicherten Baselines ungefähr linear zu sein. Die zum Speichern einer Baseline benötigte Zeitspanne nimmt mit der Projektgröße zu. Die für E/A-Dateivorgänge benötigte Zeitspanne hat sich bei kleinen und mittleren Projekten bis zur maximal zulässigen Anzahl von Baselines nicht verlängert. Bei großen Projekten hat sich die für E/A-Dateivorgänge benötigte Zeitspanne nach dem Hinzufügen einer achten Baseline deutlich verlängert.

Grenzwerte für die Projekttiefe und den Projektumfang

Durch Tests wurde gemessen, welche Auswirkung das Einfügen von Unterprojekten in Hauptprojekten auf die Leistung hat. Es wurden zwei verschiedene Arten von Tests durchgeführt:

• Testen der Tiefe (rekursiv)

• Testen des Umfangs (nicht rekursiv)

Testen der Tiefe

Das Testen der Tiefe beinhaltet das rekursive Einfügen von Unterprojekten. Zum Beispiel wurde Proj01 in Proj02 eingefügt. Diese Verkettung wurde dann in Proj03 eingefügt. Diese Verkettung wiederum wurde in Proj04 eingefügt und so weiter. Jedes Projekt in der Kette war identisch, und mit dem Test sollte festgestellt werden, wie oft ein (kleines, mittleres, großes) Projekt rekursiv eingefügt werden kann und wie die verschiedenen Leistungsmetriken darauf reagieren.

Beim Testen des rekursiven Einfügens war bei praktisch allen wichtigen Parametern eine lineare Skalierung festzustellen. Der Grenzfaktor für die Tiefe ist die Speicherauslastung. Beispielsweise näherte sich das große Projekt, das ungefähr 10.000 Vorgänge enthielt, bei 16 Ebenen dem Grenzbereich des virtuellen 32-Bit-Speichers. Doch sogar bei diesem Beispiel wurden Speichervorgänge sehr schnell ausgeführt. Andere Vorgänge wie das Schließen und erneute Öffnen des Hauptprojekts, das Einfügen neuer Ebenen und das Erzwingen einer Neuberechnung erforderten erheblich mehr Zeit. Bei einer 64-Bit-Serverplattform könnten zwar deutlich mehr Projekte eingefügt werden, doch Projekte, die solch eine Tiefe erfordern, sind selten.

Im folgenden Diagramm wird veranschaulicht, wie die Zeit, die zum Durchführen von E/A-Dateivorgängen benötigt wird, bei einer steigenden Anzahl von rekursiv eingefügten Projekten zunimmt. Beachten Sie, dass große Projekte hier nicht dargestellt werden, da die Leistung mittlerer Projekte nach einer relativ kleinen Anzahl von Rekursionen erheblich beinträchtigt wird.

Testen des Umfangs

Das Testen des Umfangs beinhaltet das Einfügen von Unterprojekten auf derselben Gliederungsebene (d.h. nicht rekursiv) in einem einzelnen Hauptprojekt.

Bei jedem wichtigen Parameter lässt sich eine lineare Anpassung an den Umfang des Projekts feststellen. Die Speicherauslastung wies einen Engpass auf, nachdem etwa 35 mittlere Dateien nicht rekursiv eingefügt wurden. Die Zeit, die zum Speichern und Öffnen benötigt wurde, betrug bei einem Umfang von 20 Projekten ungefähr 400 Sekunden. Wie beim rekursiven Einfügen könnten bei einer 64-Bit-Plattform deutlich mehr Projekte eingefügt werden, doch Projekte, die solch einen Umfang erfordern, sind selten.

Im folgenden Diagramm wird veranschaulicht, wie die Zeit, die zum Durchführen von E/A-Dateivorgängen benötigt wird, bei mittleren Projekten bei einer steigenden Anzahl von nicht rekursiv eingefügten Projekten zunimmt.

Projektserverleistung und Netzwerklatenz

Office Project Server 2007 wird in Umgebungen mit hoher Netzwerklatenz problemlos ausgeführt. Die Änderungen, die am Entwurf von Office Project Server 2007 vorgenommen wurden, bieten wichtige Vorteile in allgemeinen Einzelbenutzer-E/A-Dateiszenarien, insbesondere in WAN-Umgebungen mit hoher Latenz. Das Öffnen einer großen Datei über ein WAN mit hoher Latenz (50 ms) dauert in Project Server 2003 gegebenenfalls 45 Minuten, doch derselbe Vorgang dauerte beim Test auf Office Project Server 2007 weniger als eine Minute. Team Builder in Office Project Professional 2007 weist eine ähnliche Leistungszunahme in WAN-Umgebungen auf. Obwohl das Verwenden einer Netzwerkverbindung mit niedriger Latenz deutliche Vorteile aufweist, hat sich die Leistung von Office Project Server 2007 über WANs gegenüber der Leistung früherer Versionen erheblich verbessert.

Auch wenn die anfängliche Leistung von Office Project Server 2007 beim Start hinter der Leistung von Project Server 2003 liegt, nimmt sie bei nachfolgenden Starts zu und zeigt damit gegenüber der früheren Version ein besseres Ergebnis.

Richtlinien für annehmbare Leistung

Die Kapazität wird direkt von der Skalierbarkeit beeinflusst. In diesem Abschnitt werden die Objekte beschrieben, aus denen sich Microsoft Office Enterprise Project Management-Lösung (EPM) zusammenstellen lässt. Außerdem werden die Richtlinien für die akzeptable Leistung der einzelnen Objekttypen aufgeführt.

Wenn Ihre Lösung die empfohlenen Richtlinien um ein oder mehr Objekte überschreitet, führen Sie einen der folgenden Aktionen durch.

• Auswerten der Lösung, um sicherzustellen, dass ein Ausgleich in anderen Bereichen erfolgt.

• Kennzeichnen dieser Bereiche für Tests und Überwachung beim Erstellen und Bereitstellen der Lösung.

• Ändern des Entwurfs der Lösung, um sicherzustellen, dass die Kapazitätsrichtlinien nicht überschritten werden.

In der folgenden Liste werden die Office Project Server 2007-Objekte, auf die Grenzwerte zutreffen, und die empfohlenen Richtlinien für eine akzeptable Leistung aufgelistet. Eine akzeptable Leistung bedeutet, dass das System im getesteten Zustand die entsprechende Anzahl von Objekten unterstützen kann, dass die Anzahl jedoch nicht ohne eine Leistungsbeeinträchtigung überschritten werden kann. Ein Sternchen (*) zeigt eine harte Grenze an. Fehlt das Sternchen, zeigt dies eine getestete oder unterstützte Grenze an.

Objekt	Richtlinien für annehmbare Leistung	Hinweise
Ressourcen pro Webfarm	40.000	Dies ist der getestete Grenzwert.
Baselines pro Projekt	7 ist der empfohlene Wert. 11 ist der Höchstwert*.	Bei den Tests wurde eine Leistungsbeeinträchtigung für bestimmte an großen Projektdateien durchgeführte Vorgänge festgestellt, wenn mehr als sieben Baselines generiert wurden. Weitere Informationen hierzu finden Sie im Abschnitt "Auswirkungen der Baselines auf die Leistung" weiter oben in diesem Artikel.
Tiefe der eingefügten Projekte (rekursiv)	16	Die Leistungsbeeinträchtigung auf dieser Ebene ist beachtlich.
Umfang der eingefügten Projekte (nicht rekursiv)	20	Die Leistungsbeeinträchtigung auf dieser Ebene ist beachtlich.
Vorgänge pro Projekt	5.000	Dies ist der getestete Grenzwert.
Dauer der Vorgänge in Monaten	300	Die für die Veröffentlichung eines Projekts benötigte Zeit hängt von der Dauer des Vorgangs ab, wenn die Arbeitsprofile auf die Vorgänge angewendet werden. Diese Auswirkung kann beachtlich sein, vor allem wenn mit EPM-Lösung Projekte erstellt werden, die sich über mehrere Jahre erstrecken. Dies ist der getestete Grenzwert.
Zuordnungen pro Vorgang	16.000	Dies ist der getestete Grenzwert. Obwohl mehr als 16.000 Zuordnungen pro Vorgang vorgenommen werden können, dauerte es mehr als sieben Sekunden, einem Vorgang, der bereits 16.000 Zuordnungen enthielt, eine Zuordnung zuzuweisen.
Lokale benutzerdefinierte Formelfelder	10-30	Die Anzahl der pro Vorgang zulässigen lokalen benutzerdefinierten Formelfelder hängt vom Typ des benutzerdefinierten Felds ab. In der folgenden Liste werden die Typen der benutzerdefinierten Felder und ihre Grenzwerte aufgeführt: Vorgangstext: 30 Vorgangskosten: 10 Vorgang – Datum/Anfang/Ende: 10 Vorgangsdauer: 10 Vorgangskennzeichnung: 20 Vorgangszahl: 20 Vorgangsgliederungscode: 10 Ressourcentext: 30 Ressourcenkosten: 10 Ressource – Datum/Anfang/Ende: 10 Ressourcendauer: 10 Ressourcenkennzeichen: 20 Ressourcennummer: 20 Ressourcengliederungscode: 10
Benutzerdefinierte Enterprise-Formelfelder pro Server	32.000	Dies ist ein theoretischer Grenzwert. Er ist für jeden Typ von Entität gültig, auf den Sie ein Feld anwenden können. Beim Testen der Leistung wurden jedoch nicht mehr als ungefähr 1.000 benutzerdefinierte Enterprise-Felder verwendet.
Ressourcengrenzwerte für Team Builder	10.000 Ressourcen	Das Dialogfeld Team Builder wird in weniger als fünf Sekunden angezeigt, auch wenn auf dem Server 10.000 Ressourcen vorhanden sind. Obwohl 10.000 Ressourcen den getesteten Grenzwert darstellen, kann Team Builder mit mehr Ressourcen verwendet werden, wenn es akzeptabel ist, dass die Anzeige des Dialogfelds dementsprechend länger dauert.

Siehe auch

Konzepte

Verwalten der Active Directory-Synchronisierung in Project Server 2007