Kapazitätsplanung für Microsoft SharePoint

Kapazitätsplanung für Microsoft SharePoint
Server 2010
Microsoft Corporation
Veröffentlicht: Januar 2011
Autor: Microsoft Office System and Servers Team ([email protected])
Zusammenfassung
Dieses Buch enthält Informationen zum Planen der Kapazität und der
Leistungsanforderungen für die Bereitstellung von Microsoft SharePoint Server 2010. Zu
den Themen gehören Größenanpassung, Leistungstests, Softwarebeschränkungen und
Kapazitätsfallstudien. Zielgruppe sind Geschäftsanwendungsspezialisten,
Branchenanwendungsspezialisten, Informationsarchitekten, IT-Universalisten,
Programmverwalter und Infrastrukturspezialisten, die eine Lösung basierend auf
SharePoint Server 2010 planen. Das Buch ist Teil einer Reihe aus vier
Planungshandbüchern, die umfassende IT-Planungsinformationen für SharePoint Server
enthalten.
Weitere Informationen zum Planen der Architektur einer SharePoint Server 2010Bereitstellung finden Sie unter Planungshandbuch für Serverfarmen und Umgebungen
für Microsoft SharePoint Server 2010
(http://go.microsoft.com/fwlink/?linkid=189513&clcid=0x407).
Weitere Informationen zum Planen von Websites und Lösungen, die mit SharePoint
Server erstellt werden, finden Sie unter Planungshandbuch für Websites und Lösungen
für Microsoft SharePoint Server 2010, Teil 1
(http://go.microsoft.com/fwlink/?linkid=196150&clcid=0x407) and Planungshandbuch
für Websites und Lösungen für Microsoft SharePoint Server 2010, Teil 2
(http://go.microsoft.com/fwlink/?linkid=208024&clcid=0x407).
Bei dem Inhalt dieses Buches handelt es sich um eine Kopie von ausgewählten Inhalten
der technischen Bibliothek für SharePoint Server 2010
(http://go.microsoft.com/fwlink/?linkid=181463&clcid=0x407) zum
Veröffentlichungsdatum. Der aktuelle Inhalt befindet sich in der technischen Bibliothek im
Web.
Dieses Dokument wird ―wie besehen‖ bereitgestellt. Die in diesen Unterlagen enthaltenen
Angaben und Daten, einschließlich URLs und anderen Verweisen auf Internetwebsites,
können ohne vorherige Ankündigung geändert werden. Sie tragen das volle Risiko der
Verwendung.
Einige Beispiele sind frei erfunden, soweit nichts anderes angegeben ist. Jede
Ähnlichkeit mit der Realität ist rein zufällig.
Mit diesem Dokument erhalten Sie keine Rechte an geistigem Eigentum in einem
beliebigen Microsoft-Produkt. Sie können dieses Dokument als Kopie für eigene interne
Referenzzwecke verwenden.
© 2011 Microsoft Corporation. Alle Rechte vorbehalten.
Microsoft, Access, Active Directory, Backstage, Excel, Groove, Hotmail, InfoPath,
Internet Explorer, Outlook, PerformancePoint, PowerPoint, SharePoint, Silverlight,
Windows, Windows Live, Windows Mobile, Windows PowerShell, Windows Server und
Windows Vista sind entweder eingetragene Marken oder Marken der Microsoft
Corporation in den Vereinigten Staaten und/oder anderen Ländern.
Inhalt
Kapazitätsplanung für Microsoft SharePoint Server 2010............................................... 1
Abrufen von Hilfe................................................................................................................. 7
Leistungs- und Kapazitätsverwaltung (SharePoint Server 2010) ....................................... 8
Capacity management and sizing for SharePoint Server 2010 (in englischer Sprache) .. 10
Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht) ... 11
Glossar........................................................................................................................... 11
Wer sollte Artikel zur Kapazitätsverwaltung lesen? ....................................................... 12
Die Vier Grundkonzepte der Leistung ........................................................................... 15
Kapazitätsverwaltung und Kapazitätsplanung ............................................................... 19
Über- und Unterdimensionierung .................................................................................. 21
Softwaregrenzwerte und -beschränkungen ................................................................... 23
Wichtige Unterschiede zwischen SharePoint Server 2010 und Office SharePoint
Server 2007 ................................................................................................................ 24
Wichtige Unterscheidungsmerkmale bei Bereitstellungen von SharePoint Server 2010
.................................................................................................................................... 32
Referenzarchitekturen ................................................................................................... 35
Siehe auch ..................................................................................................................... 39
Kapazitätsplanung für SharePoint Server 2010 ................................................................ 40
Schritt 1: Modellierung ................................................................................................... 40
Schritt 2: Entwurf ........................................................................................................... 50
Schritt 3: Pilot-, Test- und Optimierungsphase .............................................................. 55
Schritt 4: Bereitstellung .................................................................................................. 56
Schritt 5: Überwachung und Wartung ............................................................................ 57
Siehe auch ..................................................................................................................... 57
Testen der Leistung für SharePoint Server 2010 ............................................................. 59
Erstellen eines Testplans............................................................................................... 60
Erstellen der Testumgebung ......................................................................................... 60
Erstellen von Tests und Tools ....................................................................................... 62
Siehe auch ..................................................................................................................... 67
Überwachen und Verwalten von SharePoint Server 2010 ............................................... 68
Konfigurieren der Überwachung .................................................................................... 68
Beseitigen von Engpässen ............................................................................................ 79
Siehe auch ..................................................................................................................... 82
SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und -grenzen
....................................................................................................................................... 83
Übersicht über Beschränkungen und Grenzen ............................................................. 84
Beschränkungen und Grenzen ...................................................................................... 87
Performance and capacity technical case studies (SharePoint Server 2010) (in englischer
Sprache) ...................................................................................................................... 128
Microsoft SharePoint Server 2010-Veröffentlichungsumgebung mit
Unternehmensintranet: Technische Fallstudie ............................................................ 130
Vorabinformationen ..................................................................................................... 130
Einführung in diese Umgebung ................................................................................... 131
Spezifikationen ............................................................................................................ 132
Arbeitsauslastung ........................................................................................................ 136
Dataset......................................................................................................................... 136
Integritäts- und Leistungsdaten ................................................................................... 137
Enterprise intranet collaboration environment technical case study (SharePoint Server
2010) (in englischer Sprache) ..................................................................................... 140
Prerequisite information ............................................................................................... 140
Introduction to this environment .................................................................................. 141
Specifications ............................................................................................................... 141
Health and Performance Data ..................................................................................... 147
Enterprise intranet collaboration environment lab study (SharePoint Server 2010) (in
englischer Sprache) ..................................................................................................... 150
Introduction to this environment .................................................................................. 150
Glossary ....................................................................................................................... 151
Overview ...................................................................................................................... 152
Specifications ............................................................................................................... 153
Results and Analysis ................................................................................................... 159
Departmental collaboration environment technical case study (SharePoint Server 2010)
(in englischer Sprache) ................................................................................................ 171
Prerequisite information ............................................................................................... 171
Introduction to this environment .................................................................................. 171
Specifications ............................................................................................................... 172
Workload ...................................................................................................................... 178
Dataset......................................................................................................................... 178
Health and Performance Data ..................................................................................... 179
Divisional portal environment lab study (SharePoint Server 2010) (in englischer Sprache)
..................................................................................................................................... 182
Introduction to this environment .................................................................................. 182
Glossary ....................................................................................................................... 183
Overview ...................................................................................................................... 184
Specifications ............................................................................................................... 185
Results and analysis .................................................................................................... 191
About the authors ........................................................................................................ 205
Social environment technical case study (SharePoint Server 2010) (in englischer
Sprache) ...................................................................................................................... 206
Prerequisite information ............................................................................................... 206
Introduction to this environment .................................................................................. 206
Specifications ............................................................................................................... 207
Workload ...................................................................................................................... 212
Dataset......................................................................................................................... 213
Health and Performance Data ..................................................................................... 213
Ergebnisse der Leistungs- und Kapazitätstests und Empfehlungen (SharePoint Server
2010) ............................................................................................................................ 217
Estimate performance and capacity requirements for Access Services in SharePoint
Server 2010 (in englischer Sprache) ........................................................................... 220
Test farm characteristics.............................................................................................. 220
Test results .................................................................................................................. 223
Recommendations ....................................................................................................... 234
Troubleshooting ........................................................................................................... 239
Estimate performance and capacity requirements for Excel Services in SharePoint Server
2010 (in englischer Sprache) ....................................................................................... 241
Test farm characteristics.............................................................................................. 241
Test Results ................................................................................................................. 244
Recommendations ....................................................................................................... 254
Schätzen der Leistungs- und Kapazitätsanforderungen für PerformancePoint-Dienste 260
Testfarmmerkmale ....................................................................................................... 260
Testszenarien und Prozesse ....................................................................................... 261
Hardwareeinstellungen und -topologie ........................................................................ 263
Testergebnisse ............................................................................................................ 264
Topologien mit 2M und 3M .......................................................................................... 266
Ergebnisse von 4M+ für die Authentifizierung über das unbeaufsichtigte Dienstkonto
.................................................................................................................................. 270
Ergebnisse von 4M+ für die Einzelbenutzerauthentifizierung ..................................... 271
Empfehlungen .............................................................................................................. 272
Analysis Services ......................................................................................................... 274
Häufige Engpässe und ihre Ursachen ......................................................................... 274
Leistungsüberwachung ................................................................................................ 277
Siehe auch ................................................................................................................... 278
Capacity requirements for Web Analytics Shared Service in SharePoint Server 2010 (in
englischer Sprache) ..................................................................................................... 279
Introduction .................................................................................................................. 279
Hardware specifications and topology ......................................................................... 282
Capacity requirements ................................................................................................. 286
Siehe auch ................................................................................................................... 290
Schätzen der Leistungs- und Kapazitätsanforderungen für Web Content Management in
SharePoint Server 2010 .............................................................................................. 291
Voraussetzungen ......................................................................................................... 292
Testdetails und Ansatz ................................................................................................ 292
Web Content Management-Bereitstellungen............................................................... 295
Optimierung ................................................................................................................. 296
Testergebnisse und Empfehlungen ............................................................................. 300
Informationen zu den Autoren ..................................................................................... 323
Estimate performance and capacity planning for workflow in SharePoint Server 2010 (in
englischer Sprache) ..................................................................................................... 324
Test farm characteristics.............................................................................................. 324
Test results .................................................................................................................. 328
Recommendations ....................................................................................................... 334
Troubleshooting ........................................................................................................... 337
Siehe auch ................................................................................................................... 340
Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server
2010) ............................................................................................................................ 341
Entwurfs- und Konfigurationsprozess für die Speicher- und Datenbankschicht der
SharePoint 2010-Produkte ....................................................................................... 341
Erfassen der Speicher- und SQL Server-Kapazität und der E/A-Anforderungen ....... 342
Auswählen der SQL Server-Version und -Edition ....................................................... 352
Entwerfen der Speicherarchitektur auf der Basis von Kapazität und E/A-Anforderungen
.................................................................................................................................. 353
Prognostizieren der Arbeitsspeicheranforderungen .................................................... 355
Grundlegendes zu den Anforderungen an die Netzwerktopologie .............................. 356
Konfigurieren von SQL Server ..................................................................................... 356
Überprüfen von Speicherleistung und -zuverlässigkeit ............................................... 361
Abrufen von Hilfe
Das Dokument wurde sorgfältig auf Korrektheit überprüft. Der Inhalt ist ebenfalls online
verfügbar in der Office System-TechNet-Bibliothek. Falls es zu Unstimmigkeiten
kommen sollte, so können Sie nach Update suchen unter:
http://technet.microsoft.com/de-de/office/bb267342
Sollten Sie keine Lösung im Onlineinhalt gefunden haben, können Sie eine E-MailNachricht an das Team von Microsoft Office System and Servers Content senden unter:
[email protected]
Betrifft Ihre Frage Microsoft Office-Produkte und nicht den Inhalt dieses Buches,
durchsuchen Sie das Microsoft-Hilfe- und Supportcenter oder die Microsoft Knowledge
Base unter:
http://support.microsoft.com/?ln=de-de
7
Leistungs- und Kapazitätsverwaltung
(SharePoint Server 2010)
Die Leistungs- und Kapazitätsplanung ist der Vorgang der Zuordnung Ihres
Lösungsentwurfs für Microsoft SharePoint Server 2010 zu einer Farmgröße und der
Hardware, die Ihre Unternehmensanforderungen unterstützen.
Relevante Artikel zur Leistungs- und Kapazitätsplanung für Project Server 2010 sind
in der Project Server-Dokumentbibliothek unter Plan for performance and capacity
(Project Server 2010) verfügbar.
Dieser Abschnitt enthält die folgenden Artikel:
 Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht)
In diesem Artikel erhalten Sie einen Überblick über die Konzepte, die im Rahmen der
Kapazitätsverwaltung und Größengestaltung von SharePoint 2010-Farmen erläutert
werden, sowie über den Planungsvorgang.
 Kapazitätsplanung für SharePoint Server 2010
Dieser Artikel enthält ausführliche Schritte und Verfahren für die Planung der
Kapazität von SharePoint 2010-Farmen.
 Überwachen und Verwalten von SharePoint Server 2010
Dieser Artikel enthält Informationen zum Verwalten und Überwachen der Leistung
von SharePoint 2010-Farmen.
 Testen der Leistung für SharePoint Server 2010
Dieser Artikel enthält Richtlinien für das Testen der Leistung von SharePoint 2010Farmen.
 SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und grenzen
Dieser Artikel bietet einen Ausgangspunkt für die Planung der Leistung und Kapazität
Ihres Systems. Dieser Artikel umfasst Ergebnisse von Leistungs- und Kapazitätstests
sowie Richtlinien für eine akzeptable Leistung.
 Performance and capacity technical case studies (SharePoint Server 2010) (in
englischer Sprache)
In diesem Artikel werden Links zu wichtigen technischen Fallstudien bereitgestellt,
die Details zur Leistung und Kapazität für bestimmte Umgebungen mit SharePoint
Server 2010 enthalten.
 Ergebnisse der Leistungs- und Kapazitätstests und Empfehlungen (SharePoint
Server 2010)
In diesem Artikel werden Links zu Artikeln bereitgestellt, die Testergebnisse und
Empfehlungen für bestimmte Featuregruppen in SharePoint Server 2010 enthalten.
 Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server
2010)
8
In diesem Artikel wird ein Vorgang für die Planung der Speicherkapazität und der
SQL Server-Kapazität für eine SharePoint Server 2010-Bereitstellung beschrieben.
Die folgenden Ressourcen können bei der Kapazitätsplanung ebenfalls hilfreich sein:
 Determine hardware and software requirements (SharePoint Server 2010)

Technische Diagramme:

Topologien für SharePoint Server 2010

Sucharchitekturen für Microsoft SharePoint Server 2010

Entwerfen von Sucharchitekturen für Microsoft SharePoint Server 2010

Planen einer Suchumgebung für Microsoft SharePoint Server 2010
Informationen zum Herunterladen dieser Modelle finden Sie unter Technical
diagrams (SharePoint Server 2010).
9
Capacity management and sizing for
SharePoint Server 2010 (in englischer
Sprache)
The articles in this section help you to make the following decisions regarding the
appropriate capacity for your Microsoft SharePoint Server 2010 environment:
 Understand the concepts behind effective capacity management.

Define performance and capacity targets for your environment.

Select the appropriate data architecture.

Choose hardware to support the number of users and the features you intend to
deploy.

Test, validate, and adjust your environment to achieve your performance and
capacity targets.
 Monitor and adjust your environment to match demand.
In this section:
 Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht)

Kapazitätsplanung für SharePoint Server 2010

Testen der Leistung für SharePoint Server 2010

Überwachen und Verwalten von SharePoint Server 2010
10
Kapazitätsverwaltung und
Größengestaltung für SharePoint Server
2010 (Übersicht)
Dieser Artikel bietet eine Übersicht über die effektive Planung und Verwaltung der
Kapazität von Microsoft SharePoint Server 2010-Umgebungen. In diesem Artikel wird
außerdem beschrieben, wie Sie sich solide Kenntnisse der Kapazitätsanforderungen und
der Möglichkeiten Ihrer Bereitstellung aneignen, indem Sie die Leistung und den
Datenumfang analysieren. Darüber hinaus werden die wichtigsten Auswirkungen auf
Anwendungen erörtert, die die Kapazität beeinflussen, einschließlich Inhalts- und
Nutzungsmerkmalen.
Kapazitätsverwaltung ist ein kontinuierlicher Prozess, da keine Implementierung
hinsichtlich Inhalt und Nutzung statisch bleibt. Sie müssen Wachstum und Änderungen
einplanen, damit Ihre SharePoint Server 2010-basierte Umgebung auch in Zukunft eine
effektive Geschäftslösung darstellt.
Kapazitätsplanung ist nur ein Teil des Kapazitätsverwaltungszyklus. Hierunter versteht
man die Aktivitäten zu Beginn, mit denen der Lösungsarchitekt eine Ausgangsarchitektur
erstellt, die seiner Meinung nach am besten für die SharePoint Server 2010Bereitstellung geeignet ist. Das Kapazitätsverwaltungsmodell beinhaltet weitere Schritte
zum Überprüfen und Optimieren der Ausgangsarchitektur sowie einen Feedbackprozess
für die erneute Planung und Optimierung der Produktionsumgebung, bis die
Entwurfsziele mit einer optimalen Auswahl an Hardware, Topologie und Konfiguration
unterstützt werden.
Inhalt dieses Artikels:
 Glossar

Wer sollte Artikel zur Kapazitätsverwaltung lesen?

Die Vier Grundkonzepte der Leistung

Kapazitätsverwaltung und Kapazitätsplanung

Über- und Unterdimensionierung

Softwaregrenzwerte und -beschränkungen

Wichtige Unterschiede zwischen SharePoint Server 2010 und Office SharePoint
Server 2007

Wichtige Unterscheidungsmerkmale bei Bereitstellungen von SharePoint
Server 2010

Referenzarchitekturen
Glossar
Die folgenden Spezialbegriffe werden in der Dokumentation zur Kapazitätsverwaltung
von SharePoint Server 2010 verwendet.
11

RPS Anforderungen pro Sekunde (Requests per Second). Die Anzahl der
Anforderungen, die von einer Farm oder einem Server in einer Sekunde empfangen
werden. Dies ist ein gängiges Maß für die Auslastung von Servern und Farmen. Die
Anzahl der von einer Farm verarbeiteten Anforderungen ist höher als die Anzahl der
Seitenladevorgänge und Endbenutzerinteraktionen. Dies liegt daran, dass jede Seite
mehrere Komponenten enthält, von denen beim Laden der Seite jeweils mindestens
eine Anforderung erstellt wird. Manche Anforderungen sind im Hinblick auf die
Transaktionskosten weniger anspruchsvoll als andere Anforderungen. In unseren
Labortests und Dokumenten mit Fallstudien haben wir 401 Anforderungen und
Antworten (Authentifizierungshandshakes) aus den Anforderungen entfernt, mit
denen die Anforderungen pro Sekunde berechnet wurden, da sie praktisch keine
Auswirkungen auf die Farmressourcen haben.

Spitzenzeiten Die Tageszeiten, zu denen die Farm am stärksten ausgelastet ist.

Spitzenauslastung Die durchschnittliche tägliche maximale Auslastung in der Farm,
gemessen in RPS.

Auslastungsspitzen Vorübergehende Auslastungsspitzen außerhalb der
gewöhnlichen Spitzenzeiten. Sie können durch ungeplante Zunahmen des
Benutzerdatenverkehrs, reduzierten Farmdurchsatz aufgrund administrativer
Vorgänge oder einer Kombination dieser Faktoren verursacht werden.

Vertikales Skalieren Vertikales Skalieren bedeutet, einem Server Ressourcen wie
z. B. Prozessoren oder Arbeitsspeicher hinzuzufügen.

Horizontales Skalieren Horizontales Skalieren bedeutet, einer Farm weitere Server
hinzuzufügen.
Wer sollte Artikel zur Kapazitätsverwaltung
lesen?
Bestimmen Sie anhand der folgenden Fragen, ob Sie diese Artikel lesen sollten.
Auswerten von SharePoint Server 2010
Ich bin ein IT-Spezialist oder Entscheidungsträger im Unternehmen und suche nach einer
Lösung für spezielle Geschäftsprobleme. SharePoint Server 2010 ist eine Option für
meine Bereitstellung. Können damit die für meine speziellen Anforderungen benötigten
Features und Skalierbarkeitsmöglichkeiten bereitgestellt werden?
Informationen zum Skalieren von SharePoint Server 2010 entsprechend den
Anforderungen bestimmter Lösungen sowie zum Bestimmen der für Ihre Anforderungen
benötigten Hardware finden Sie weiter unten in diesem Artikel in den folgenden
Abschnitten:
 Wichtige Unterschiede zwischen SharePoint Server 2010 und Office SharePoint
Server 2007
 Softwaregrenzwerte und -beschränkungen
Informationen zum Auswerten von SharePoint Server 2010 für Ihre speziellen
Geschäftsanforderungen finden Sie in den folgenden Artikeln:
 Product evaluation for SharePoint Server 2010

SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und grenzen
12
Upgraden von Office SharePoint Server 2007
Ich verwende derzeit Microsoft Office SharePoint Server 2007. Welche Änderungen gibt
es bei SharePoint Server 2010, und was muss ich bei einem Upgrade berücksichtigen?
Welche Auswirkungen hat das Upgrade auf die Leistung und Skalierung meiner
Topologie?
Informationen zu den Unterschieden bei Leistungs- und Kapazitätsfaktoren zwischen
Microsoft Office SharePoint Server 2007 und SharePoint Server 2010 finden Sie weiter
unten in diesem Artikel im folgenden Abschnitt:
 Wichtige Unterschiede zwischen SharePoint Server 2010 und Office SharePoint
Server 2007
Informationen zu allgemeineren Überlegungen und Anweisungen für ein Upgrade sowie
zum Planen und Ausführen eines Upgrades von Microsoft Office SharePoint Server 2007
finden Sie im folgenden Artikel:
 Upgrading to SharePoint Server 2010
Optimieren einer SharePoint-basierten Live-Umgebung
Ich habe SharePoint Server 2010 bereitgestellt und möchte sicherstellen, dass die
entsprechende Hardware und Topologie vorhanden sind. Wie werte ich meine Architektur
aus und warte sie ordnungsgemäß?
Informationen zur Überwachung und zu Leistungsindikatoren für Microsoft SharePoint
Server 2010-Farmen finden Sie im folgenden Artikel:
 Überwachen und Verwalten von SharePoint Server 2010
Informationen zur Verwendung der in die Benutzeroberfläche der Zentraladministration
integrierten Systemüberwachungstools finden Sie im folgenden Artikel:
 Health Monitoring (SharePoint Server 2010)
Ich habe SharePoint Server 2010 bereitgestellt, aber es treten Leistungsprobleme auf.
Wie kann ich für meine Umgebung eine Problembehandlung vornehmen und sie
optimieren?
Informationen zur Überwachung und zu Leistungsindikatoren für Microsoft SharePoint
Server 2010-Farmen finden Sie im folgenden Artikel:
 Überwachen und Verwalten von SharePoint Server 2010
Informationen zur Problembehandlung mithilfe der in die Benutzeroberfläche der
Zentraladministration integrierten Systemüberwachungstools finden Sie im folgenden
Artikel:
 Solving Problems and Troubleshooting (SharePoint Server 2010)
Eine Liste mit Artikeln zur Kapazitätsverwaltung, die für viele spezielle Dienste und
Features von SharePoint Server 2010 verfügbar sind (weitere Artikel werden im Laufe
der Zeit hinzugefügt), finden Sie im folgenden Artikel:
 Ergebnisse der Leistungs- und Kapazitätstests und Empfehlungen (SharePoint
Server 2010)
Informationen zur Größenanpassung und zur Leistung von Datenbanken finden Sie im
folgenden Artikel:
 Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server
2010)
Informationen zum Remote-BLOB-Speicher (RBS) finden Sie im folgenden Artikel:
13

Plan for remote BLOB storage (RBS) (SharePoint Server 2010)
Vom Anfang bis zum Ende
Ich möchte alles über die Kapazitätsverwaltung für SharePoint Server 2010 wissen. Wo
beginne ich?
Informationen zu den allgemeinen Konzepten bei der Kapazitätsverwaltung sowie Links
zu zusätzlicher Dokumentation und zusätzlichen Ressourcen finden Sie im folgenden
Artikel:
 Leistungs- und Kapazitätsverwaltung (SharePoint Server 2010)
Weitere Informationen zur Kapazitätsverwaltung finden Sie in den folgenden
Begleitartikeln zu diesem Übersichtsartikel:
 Kapazitätsplanung für SharePoint Server 2010

Testen der Leistung für SharePoint Server 2010
 Überwachen und Verwalten von SharePoint Server 2010
Sie sollten nun einen gutes Verständnis der Konzepte haben. Informationen zu den
Grenzwerten und Beschränkungen von SharePoint Server 2010 finden Sie im folgenden
Artikel:
 SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und grenzen
Wenn Sie bereit sind, eine Ausgangstopologie für Ihre SharePoint Server 2010-basierte
Umgebung zu definieren, können Sie in der Bibliothek mit den verfügbaren technischen
Fallstudien nach der Topologie suchen, die am ehesten Ihren Anforderungen entspricht.
Eine Liste mit Fallstudien (weitere Fallstudien werden im Laufe der Zeit hinzugefügt)
finden Sie im folgenden Artikel:
 Performance and capacity technical case studies (SharePoint Server 2010) (in
englischer Sprache)
Eine Liste mit Artikeln zur Kapazitätsverwaltung, die für viele spezielle Dienste und
Features von SharePoint Server 2010 verfügbar sind (weitere Artikel werden im Laufe
der Zeit hinzugefügt), finden Sie im folgenden Artikel:
 Ergebnisse der Leistungs- und Kapazitätstests und Empfehlungen (SharePoint
Server 2010)
Informationen zur Größenanpassung und zur Leistung von Datenbanken finden Sie im
folgenden Artikel:
 Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server
2010)
Informationen zum Remote-BLOB-Speicher (RBS) finden Sie im folgenden Artikel:
 Plan for remote BLOB storage (RBS) (SharePoint Server 2010)
Informationen zur Systemüberwachung und Problembehandlung mithilfe der in die
Benutzeroberfläche der Zentraladministration integrierten Systemüberwachungstools
finden Sie in den folgenden Artikeln:
 Health Monitoring (SharePoint Server 2010)
 Solving Problems and Troubleshooting (SharePoint Server 2010)
Informationen zu allgemeinen Richtlinien für die Leistungsoptimierung und zu einer Reihe
von speziellen Leistungs- und Kapazitätsthemen (weitere Artikel werden im Laufe der
Zeit hinzugefügt) finden Sie im folgenden Artikel:
14
 Use search administration reports (SharePoint Server 2010)
Weitere Informationen zum Virtualisieren von SharePoint Server 2010-basierten Servern
finden Sie im folgenden Artikel:
 Virtualization planning (SharePoint Server 2010)
Die Vier Grundkonzepte der Leistung
Die Kapazitätsverwaltung befasst sich mit den folgenden vier Hauptaspekten der
Größenanpassung Ihrer Lösung:
 Wartezeit Im Zusammenhang mit der Kapazitätsverwaltung wird Wartezeit definiert
als der Zeitraum zwischen dem Starten einer Aktion (z. B. das Klicken auf einen
Hyperlink) durch einen Benutzer und dem Zeitpunkt der Übertragung des letzten
Bytes an die Clientanwendung oder den Webbrowser.

Durchsatz Der Durchsatz ist definiert als die Anzahl gleichzeitiger Anforderungen,
die von einem Server oder einer Serverfarm verarbeitet werden kann.

Datenvolumen Das Datenvolumen wird definiert als die Inhaltsgröße und der
Datenkorpus, die bzw. der vom System gehostet werden kann. Die Struktur und
Verteilung der Inhaltsdatenbanken hat erhebliche Auswirkungen auf den Zeitaufwand
für die Verarbeitung von Anforderungen durch das System (Wartezeit) sowie die
unterstützte Anzahl gleichzeitiger Anforderungen (Durchsatz).

Zuverlässigkeit Die Zuverlässigkeit ist ein Maß für die Einhaltung der Zielvorgaben
für die Wartezeit und den Durchsatz über einen bestimmten Zeitraum.
Bei der Kapazitätsverwaltung für die Umgebung soll in erster Linie ein System
eingerichtet und verwaltet werden, das die Zielvorgaben Ihrer Organisation für Wartezeit,
Durchsatz, Datenvolumen und Zuverlässigkeit erfüllt.
Wartezeit
Wartezeit, die auch als vom Endbenutzer wahrgenommene Wartezeit bezeichnet wird,
besteht aus den folgenden drei Hauptkomponenten:
 Der Zeit, die der Server zum Empfangen und Verarbeiten der Anforderung benötigt.

Der Zeit, die die Übertragung der Anforderung und der Serverantwort im Netzwerk
benötigt.
 Der Zeit, die das Rendern der Antwort in der Clientanwendung benötigt.
Organisationen definieren basierend auf Geschäftsanforderungen und
Benutzererwartungen unterschiedliche Zielvorgaben für die Wartezeit. Manche
Organisationen können sich eine Wartezeit von mehreren Sekunden leisten, während
andere Organisationen sehr schnelle Transaktionen benötigen. Die Optimierung für sehr
schnelle Transaktionen ist gewöhnlich teurer und erfordert in der Regel leistungsfähigere
Clients und Server, neuere Browser- und Clientanwendungsversionen,
Netzwerklösungen mit hoher Bandbreite sowie möglicherweise Investitionen in die
Entwicklung und Optimierung von Seiten.
Einige wichtige Faktoren, die zu längeren vom Endbenutzer wahrgenommenen
Wartezeiten führen, sowie Beispiele für einige häufig auftretende Probleme werden in der
folgenden Liste beschrieben. Diese Faktoren sind besonders relevant für Szenarien, bei
denen die Clients weit entfernt von der Serverfarm sind oder über eine
Netzwerkverbindungen mit niedriger Bandbreite auf die Farm zugreifen.
15

Nicht optimierte Features, Dienste oder Konfigurationsparameter können die
Verarbeitung von Anforderungen verzögern und Auswirkungen auf die Wartezeit für
Remoteclients und lokale Clients haben. Weitere Informationen finden Sie unter
Durchsatz und Zuverlässigkeit weiter unten in diesem Artikel.

Webseiten, die für den Server unnötige Anforderungen zum Herunterladen
erforderlicher Daten und Ressourcen generieren. Die Optimierung würde das
Herunterladen der Mindestanzahl von Ressourcen zum Darstellen der Seite, das
Reduzieren der Bildgrößen, das Speichern der statischen Ressourcen in Ordnern,
die den anonymen Zugriff ermöglichen, das Gruppieren von Anforderungen und das
Aktivieren der Seiteninteraktivität während des asynchronen Herunterladens der
Ressourcen vom Server beinhalten. Diese Optimierungen spielen eine wichtige
Rolle, um eine akzeptable erstmalige Browseerfahrung zu erzielen.

Die Übertragung sehr großer Datenmengen im Netzwerk trägt zu längeren
Wartezeiten und zur Beeinträchtigung des Durchsatzes bei. Beispielsweise sollten
Bilder und andere Binärobjekte auf einer Seite nach Möglichkeit ein komprimiertes
Format wie z. B. PNG oder JPG anstelle von Bitmaps verwenden.

Webseiten, die nicht für Zweitzugriff-Seitenladevorgänge optimiert sind. Die
Seitenladezeit (Page Load Time, PLT) wird für Zweitzugriff-Seitenladevorgänge
verbessert, da manche Seitenressourcen auf dem Client zwischengespeichert sind,
und der Browser muss nur nicht zwischengespeicherten dynamischen Inhalt
herunterladen. Nicht akzeptable Wartezeiten bei Zweitzugriff-Seitenladevorgängen
werden oft durch die falsche Konfiguration des BLOB-Caches (Binary Large Object)
oder durch die Deaktivierung der lokalen Browserzwischenspeicherung auf
Clientcomputern verursacht. Optimierungen würden die korrekte
Zwischenspeicherung von Ressourcen auf dem Client beinhalten.

Webseiten mit nicht optimiertem benutzerdefiniertem JavaScript-Code. Dadurch kann
das Rendern der Seite auf dem Client verlangsamt werden. Die Optimierung würde
die Verarbeitung von JavaScript-Code auf dem Client verzögern, bis der Rest der
Seite geladen wurde, und nach Möglichkeit würden Skripts aufgerufen, anstatt
JavaScript inline hinzuzufügen.
Durchsatz
Der Durchsatz wird beschrieben als die Anzahl von Anforderungen, die von einer
Serverfarm in einer Zeiteinheit verarbeitet werden können, und wird oft zum Messen des
Vorgangsvolumens verwendet, das vom System basierend auf der Größe der
Organisation und deren Nutzungsmerkmalen unterstützt werden soll. Für jeden Vorgang
fallen bestimmte Kosten bei den Serverfarmressourcen an. Die Kenntnis des Bedarfs und
die Bereitstellung einer Farmarchitektur, durch die der Bedarf kontinuierlich erfüllt werden
kann, erfordert das Bestimmen der erwarteten Auslastung und das Testen der Architektur
mit einer Auslastung. Dadurch soll sichergestellt werden, dass die Wartezeit nicht unter
die Zielvorgabe sinkt, wenn viele gleichzeitige Anforderungen vorhanden sind und das
System stark beansprucht wird.
Es folgen einige gängige Beispiele für Situationen mit niedrigem Durchsatz:
 Ungeeignete Hardwareressourcen Wenn die Farm mehr Anforderungen empfängt,
als gleichzeitig verarbeitet werden können, werden der Warteschlange
Anforderungen hinzugefügt. Dadurch wird die Verarbeitung jeder nachfolgenden
Anforderung kumulativ verzögert, bis der Bedarf ausreichend reduziert wurde, dass
16
die Warteschlange geleert werden kann. Für die Optimierung einer Farm zur
Unterstützung eines höheren Durchsatzes gibt es folgende Beispiele:



Stellen Sie sicher, dass die Prozessoren auf Farmservern nicht übermäßig
beansprucht werden. Wenn z. B. die CPU-Auslastung zu Spitzenzeiten oder
Auslastungsspitzen 80 % überschreitet, fügen Sie weitere Server hinzu, oder
verteilen Sie Dienste auf andere Farmserver.

Stellen Sie sicher, dass auf Anwendungsservern und Webservern ausreichend
Arbeitsspeicher für den kompletten Cache vorhanden ist. Dadurch werden
Aufrufe für die Datenbank zum Verarbeiten von Anforderungen für nicht
zwischengespeicherte Inhalte vermieden.

Stellen Sie sicher, dass es bei den Datenbankservern keine Engpässe gibt. Falls
die insgesamt verfügbare Datenträgergeschwindigkeit (IOPS) zur Unterstützung
von Spitzenbedarf nicht ausreicht, fügen Sie weitere Datenträger hinzu, oder
verteilen Sie Datenbanken auf nicht ausgelastete Datenträger. Weitere
Informationen finden Sie im Abschnitt zum Beseitigen von Engpässen des
Artikels zur Überwachung und Wartung von SharePoint Server 2010-Produkten
und -Technologien.

Wenn das Hinzufügen von Ressourcen zu bestehenden Computern nicht
ausreicht, um Durchsatzproblem zu beseitigen, fügen Sie Server hinzu, und
verteilen Sie betroffene Features und Dienste auf die neuen Server.
Nicht optimierte benutzerdefinierte Webseiten Das Hinzufügen von
benutzerdefiniertem Code zu häufig verwendeten Seiten in einer
Produktionsumgebung ist eine häufige Ursache für Durchsatzprobleme. Durch das
Hinzufügen von benutzerdefiniertem Code können für die Verarbeitung von
Datenanforderungen zusätzliche Roundtrips zu den Datenbankservern oder
Webdiensten generiert werden. Die Anpassung selten verwendeter Seiten hat zwar
geringe Auswirkungen auf den Durchsatz, aber selbst gut optimierter Code kann den
Farmdurchsatz reduzieren, falls er Tausende Male am Tag angefordert wird.
SharePoint Server-Administratoren können das Entwicklerdashboard aktivieren, um
benutzerdefinierten Code zu identifizieren, der optimiert werden muss. Für die
Optimierung von benutzerdefiniertem Code gibt es folgende Beispiele:

Minimieren Sie die Anzahl von Webdienstanforderungen und SQL-Abfragen.

Rufen Sie die mindestens erforderlichen Daten bei jedem Roundtrip zum
Datenbankserver ab, und reduzieren Sie gleichzeitig die Anzahl notwendiger
Roundtrips.

Vermeiden Sie das Hinzufügen von benutzerdefiniertem Code zu häufig
verwendeten Seiten.

Verwenden Sie Indizes, wenn Sie eine gefilterte Datenmenge abrufen.
Nicht vertrauenswürdige Lösungen Durch die Bereitstellung von
benutzerdefiniertem Code in bin-Ordnern kann die Serverleistung beeinträchtigt
werden. Bei jeder Anforderung einer Seite, die nicht vertrauenswürdigen Code
enthält, müssen vor dem Laden der Seite von SharePoint Server 2010
Sicherheitsprüfungen ausgeführt werden. Wenn es keinen triftigen Grund für die
Bereitstellung von nicht vertrauenswürdigem Code gibt, sollten Sie benutzerdefinierte
Assemblys im globalen Assemblycache (GAC) installieren, um unnötige
Sicherheitsprüfungen zu vermeiden.
17
Datenvolumen
Das Datenvolumen ist der Datenumfang, der vom Server oder der Serverfarm
gespeichert werden kann, sodass die Zielvorgaben für Wartezeit und Durchsatz erfüllt
werden können. Im Allgemeinen gilt, je größer das Datenvolumen in der Farm ist, desto
größer sind die Auswirkungen insgesamt auf den Durchsatz und die Benutzererfahrung.
Die zum Verteilen von Daten auf Datenträger und Datenbankserver verwendete Methode
kann ebenfalls Auswirkungen auf die Wartezeit und den Durchsatz der Farm haben.
Die Größenanpassung der Datenbank, die Datenarchitektur und ausreichend
Datenbankserverhardware spielen eine sehr wichtige Rolle für eine optimale
Datenbanklösung. Bei einer idealen Bereitstellung wird die Größe von
Inhaltsdatenbanken gemäß den Größenvorgaben angepasst, und die
Inhaltsdatenbanken werden auf physikalische Datenträger verteilt, sodass Anforderungen
aufgrund der übermäßigen Beanspruchung der Datenträger nicht der Warteschlange
hinzugefügt werden. Und Datenbankserver unterstützen Spitzenauslastungen und
unerwartete Auslastungssitzen, ohne die Schwellenwerte für die Ressourcenverwendung
zu überschreiten.
Außerdem können bestimmte Tabellen bei der Ausführung bestimmter Vorgänge
gesperrt werden. Ein Beispiel hierfür ist das Löschen einer umfangreichen Website.
Dabei kann es sein, dass die zugehörigen Tabellen in der Inhaltsdatenbank, in der die
Website gespeichert ist, bis zum Abschluss des Löschvorgangs gesperrt sind.
Für das Optimieren der Daten- und Speicherleistung einer Farm gibt es folgende
Beispiele:
 Stellen Sie sicher, dass die Datenbanken ordnungsgemäß auf die Datenbankserver
verteilt sind und dass die Datenbankserverressourcen für die Unterstützung des
Datenvolumens und der Datenverteilung ausreichend sind.

Teilen Sie die Datenbanken auf eindeutige logische Einheiten (LUN) auf, die aus
eindeutigen physikalischen Datenträgerspindeln bestehen. Verwenden Sie mehrere
Datenträger mit schnellen Suchzeiten und geeigneten RAID-Konfigurationen, um die
Speicheranforderungen der Datenbankserver zu erfüllen.

Sie können Remote-BLOB-Speicher (RBS) verwenden, wenn der Datenkorpus viele
BLOB-Daten (Binary Large Objects) enthält. RBS kann die folgenden Vorteile bieten:

BLOB-Daten können auf kostengünstigeren Speichergeräten gespeichert
werden, die für eine einfache Speicherung konfiguriert sind.

Die Verwaltung der BLOB-Speicherung wird von einem System gesteuert, das
speziell für das Arbeiten mit BLOB-Daten entwickelt wurde.

Datenbankserverressourcen werden für Datenbankvorgänge freigegeben.
Diese Vorteile sind mit Kosten verbunden. Bevor Sie RBS mit SharePoint Server
2010 implementieren, müssen Sie prüfen, ob diese potenziellen Vorteile mit den
Kosten und Einschränkungen der Implementierung und Wartung von RBS in
Einklang zu bringen sind.
Weitere Informationen finden Sie unter Plan for remote BLOB storage (RBS)
(SharePoint Server 2010).
Weitere Informationen zur Planung des Datenvolumens finden Sie unter Speicher- und
SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010).
Zuverlässigkeit
18
Die Zuverlässigkeit ist das Maß für die Einhaltung der Zielvorgaben für die Wartezeit, den
Durchsatz und die Datenkapazität der Serverfarm über einen bestimmten Zeitraum. Eine
Farm gilt dann als zuverlässig, wenn die Betriebszeit, die Reaktionszeit, die Fehlerrate
sowie die Häufigkeit und der Ausschlag von Wartezeitspitzen innerhalb der Zielvorgaben
und der betrieblichen Anforderungen liegen. Eine zuverlässige Farm unterstützt
außerdem kontinuierlich die Zielvorgaben für Wartezeit und Durchsatz zu
Spitzenauslastungs- und Spitzenzeiten oder beim Ausführen von Systemvorgängen wie
z. B. Durchforstungen oder täglichen Sicherungen.
Ein wichtiger Faktor bei der Unterstützung der Zuverlässigkeit sind die Auswirkungen
allgemeiner administrativer Vorgänge auf die Leistungszielvorgaben. Bei bestimmten
Vorgängen, wie z. B. der Neuerstellung der Datenbankindizes,
Wartungszeitgeberaufträgen oder dem Löschen von mehreren Websites mit viel Inhalt,
können Benutzeranforderungen möglicherweise nicht so schnell verarbeitet werden. In
diesem Fall können sowohl die Wartezeit als auch der Durchsatz von
Endbenutzeranforderungen beeinträchtigt werden. Die Auswirkungen auf die Farm sind
abhängig von der Häufigkeit und den Transaktionskosten solcher seltenerer Vorgänge
sowie der Tatsache, ob sie während der üblichen Betriebszeit ausgeführt werden.
Für die Unterstützung eines zuverlässigeren Systems gibt es folgende Beispiele:
 Planen Sie ressourcenintensive Zeitgeberauträge und administrative Aufgaben für
Nebenzeiten ein.

Nehmen Sie eine vertikale Skalierung der Hardware auf den bestehenden
Farmservern vor, oder nehmen Sie durch Hinzufügen von Webservern,
Anwendungsservern oder zusätzlichen Datenbankservern eine horizontale
Skalierung vor.

Verteilen Sie ressourcenintensive Dienste und Features auf dedizierte Server. Sie
können auch mit einem hardwarebasierten Lastenausgleichsmodul
featurespezifischen Datenverkehr an einen Webserver umleiten, der ausschließlich
für bestimmte Features oder Dienste vorgesehen ist.
Kapazitätsverwaltung und Kapazitätsplanung
Mit der Kapazitätsverwaltung wird die Kapazitätsplanung erweitert, um einen zyklischen
Ansatz zu formulieren, bei dem die Kapazität einer SharePoint Server 2010Bereitstellung fortlaufend überwacht und optimiert wird, um auf sich ändernde
Bedingungen und Anforderungen einzugehen.
SharePoint Server 2010 bietet eine höhere Flexibilität und kann für die Unterstützung von
Verwendungsszenarien einer Vielzahl unterschiedlicher Skalierungspunkte konfiguriert
werden. Es gibt nicht eine einzelne Bereitstellungsarchitektur. Deshalb müssen SystemDesigner und Administratoren die Anforderungen für ihre speziellen Umgebungen
kennen.
SharePoint Server 2010-Kapazitätsverwaltungsmodell
19

Schritt 1: Modellierung Bei der Modellierung bestimmen Sie die wichtigen
Lösungen, die von Ihrer Umgebung unterstützt werden sollen, und richten alle
wichtigen Metriken und Parameter ein. Das Resultat der Modellierungsübung sollte
eine Liste mit allen wichtigen Daten sein, die Sie zum Entwerfen der Umgebung
benötigen.

Analysieren Sie die erwartete Arbeitsauslastung und das Dataset.
20



Legen Sie Zielvorgaben für die Leistung und Zuverlässigkeit der Farm fest.

Analysieren Sie die SharePoint Server 2010-IIS-Protokolle.
Schritt 2: Entwurf Nachdem Sie in Schritt die Daten erfasst haben, können Sie die
Farm entwerfen. Das Resultat dieses Schritts sind eine detaillierte Datenarchitektur
sowie physikalische und logische Topologien.

Bestimmen Sie die Ausgangsarchitektur.

Wählen Sie die Hardware aus.
Schritt 3: Pilot-, Test- und Optimierungsphase Wenn Sie eine neue Bereitstellung
entworfen haben, müssen Sie eine Pilotumgebung zum Testen anhand Ihrer
Arbeitsauslastung und der erwarteten Nutzungsmerkmale bereitstellen. Für eine
bestehende Farm ist das Testen ratsam, wenn größere Änderungen an der
Infrastruktur vorgenommen werden, aber die regelmäßige Optimierung basierend auf
Überwachungsergebnissen erforderlich ist, um die Leistungsvorgaben einzuhalten.
Das Resultat dieser Phase ist eine Analyse der Testergebnisse anhand der
Zielvorgaben sowie eine optimierte Architektur, die die Zielvorgaben für Leistung und
Kapazität unterstützt.

Pilotphase Stellen Sie eine Pilotumgebung bereit.

Testphase Testen Sie anhand der Zielvorgaben für Wartezeit und Durchsatz.

Optimierungsphase Sammeln Sie Testergebnisse, und nehmen Sie
erforderliche Änderungen an den Farmressourcen und der Topologie vor.

Schritt 4: Bereitstellung Dieser Schritt beschreibt das Implementieren der Farm
oder das Bereitstellen von Änderungen einer vorhandenen Farm. Das Resultat eines
neuen Entwurfs ist die abgeschlossene Bereitstellung in der
Liveproduktionsumgebung, einschließlich aller Inhalte und Benutzermigrationen. Das
Resultat für eine vorhandene Farm sind überarbeitete Farmzuordnungen und
aktualisierte Wartungspläne.

Schritt 5: Überwachung und Wartung Dieser Schritt beschreibt, wie Sie die
Überwachung einrichten, wie Sie Engpässe vorhersehen und erkennen sowie wie
Sie eine regelmäßige Wartung und Aktivitäten zur Vermeidung von Engpässen
ausführen.
Über- und Unterdimensionierung
Überdimensionierung beschreibt einen Farmentwurf, bei dem die Zielvorgaben erreicht
werden, ohne Hardware voll zu nutzen, und die Ressourcen in der SharePoint ServerFarm sind in erheblichem Maß und beständig nicht ausgelastet. In einer
überdimensionierten Bereitstellung zeigen Arbeitsspeicher, CPU und sonstige
Indikatoren der Farmressourcen, dass der Bedarf mit weniger Ressourcen problemlos
bewältigt werden kann. Der Nachteil der Überdimensionierung sind erhöhte Ausgaben für
Hardware und Wartung sowie ein höherer Strom- und Speicherplatzverbrauch.
Unterdimensionierung beschreibt einen Farmentwurf, bei dem die Leistungs- und
Kapazitätsvorgaben nicht erreicht werden, da Hardwareressourcen in der SharePoint
Server-Farm übermäßig beansprucht werden. Die Unterdimensionierung einer Farm wird
manchmal verwendet, um Hardwarekosten zu senken, führt aber im Allgemeinen zu
langen Wartezeiten und damit zu einer geringen Benutzerfreundlichkeit, geringer
21
Zufriedenheit, häufigen Eskalationen, hohen Supportkosten und unnötigen Ausgaben für
die Problembehandlung und Optimierung der Umgebung.
Stellen Sie beim Entwerfen Ihrer Farm sicher, dass die Farm die festgelegten Leistungsund Kapazitätsvorgaben erfüllen kann, und zwar sowohl bei regulärer Spitzenauslastung
als auch bei unerwarteten Spitzen. Durch das Entwerfen, Testen und Optimieren können
Sie sicherstellen, dass in der Farm die richtige Hardware verwendet wird.
Zur Erfüllung der Leistungsvorgaben und zur Berücksichtigung des Wachstums sollten
stets mehr Ressourcen vorhanden sein, als zur Erfüllung der Zielvorgaben erforderlich
sind. Die Kosten für die überhöhten Investitionen in Hardware sind gewöhnlich viel
niedriger als die Ausgaben im Laufe der Zeit für die Behandlung von Problemen, die
durch die Unterdimensionierung verursacht wurden.
Sie sollten die Größe eines Systems immer so gestalten, dass es zu Spitzenzeiten
angemessen reagiert, was für bestimmte Dienste zu verschiedenen Zeiten
unterschiedlich sein kann. Für eine effektive Schätzung der Kapazitätsanforderungen
müssen Sie für alle Ressourcen den Zeitraum mit dem höchsten Bedarf ermitteln.
Möglicherweise sind verschiedene Features und Dienste zu bestimmten Tageszeiten
stärker ausgelastet, wie z. B. am Morgen oder nach dem Mittagessen.
Die Farm muss außerdem ungeplante Spitzenzeiten unterstützen. Beispielsweise wenn
bei Ankündigungen im gesamten Unternehmen ungewöhnlich viele Benutzer gleichzeitig
auf eine Website zugreifen. In solchen Zeiten mit hohem Bedarf treten für die Benutzer
lange Wartezeiten auf, oder sie erhalten nur eine Antwort von der Farm, wenn
ausreichend Farmressourcen für die erhöhte Auslastung in der Farm verfügbar sind.
Die Farmkapazität sollte ebenfalls überprüft werden, wenn dem Unternehmen zusätzliche
Benutzer hinzugefügt werden. Situationen wie z. B. eine Firmenfusion oder eine
Firmenübernahme sind dadurch gekennzeichnet, dass durch den Zugriff neuer
Mitarbeiter auf die Farm möglicherweise die Leistung beeinträchtigt wird, wenn dies nicht
vorher entsprechend geplant wurde.
Betriebsstatus: Grüner Bereich und roter Bereich
Bei der Beschreibung der Auslastung eines Produktionssystems werden zwei
Hauptbetriebsstatus verwendet. Einerseits der Status Grüner Bereich, in dem das
System im normalen, erwarteten Auslastungsbereich arbeitet. Und andererseits der
Status Rote Zone, in dem in der Farm ein sehr hoher temporärer Ressourcenbedarf
auftritt, der nur für einen begrenzten Zeitraum unterstützt werden kann, bevor Fehler und
sonstige Leistungs- und Zuverlässigkeitsprobleme auftreten.
Grüner Bereich In diesem Status arbeitet der Server bzw. die Farm unter normalen
Auslastungsbedingungen, bis hin zu erwarteten täglichen Spitzenauslastungen. Eine
Farm sollte unter diesen Umständen in der Lage sein, akzeptable Reaktionszeiten und
Wartezeiten zu ermöglichen.
Roter Bereich Der Betriebsbereich, in dem die Auslastung höher als die normale
Spitzenauslastung ist, aber Serviceanforderungen weiterhin für einen begrenzten
Zeitraum erfüllt werden können. Dieser Status ist gekennzeichnet durch eine Wartezeit
über dem üblichen Wert sowie durch mögliche Fehler aufgrund der Überlastung durch
Systemengpässe.
Ziel des Farmentwurfs ist letztlich die Bereitstellung einer Umgebung, von der eine
Auslastung im roten Bereich ohne Servicefehler und innerhalb akzeptabler Zielvorgaben
für Wartezeit und Durchsatz kontinuierlich unterstützt wird.
22
Softwaregrenzwerte und -beschränkungen
In SharePoint Server 2010 gibt es bestimmte Grenzwerte, die entwurfsbedingt sind und
nicht überschritten werden können, während es sich bei anderen Grenzwerten um
Standardwerte handelt, die von einem Farmadministrator geändert werden können.
Außerdem gibt es bestimmte Grenzwerte, die nicht durch einen konfigurierbaren Wert
dargestellt werden, beispielsweise die Anzahl von Websitesammlungen pro
Webanwendung.
Bei Beschränkungen handelt es sich um absolute Grenzwerte, die entwurfsbedingt nicht
überschritten werden können. Es ist wichtig, diese Grenzwerte zu kennen, um
sicherzustellen, dass Sie beim Entwerfen Ihrer Farm nicht von falschen Voraussetzungen
ausgehen.
Ein Beispiel für eine Beschränkung ist die Beschränkung der Dokumentgröße auf 2 GB.
Sie können SharePoint Server 2010 nicht so konfigurieren, dass Dokumente mit einer
Größe von über 2 GB gespeichert werden. Es handelt sich hierbei um einen integrierten
absoluten Wert, der entwurfsbedingt nicht überschritten werden kann.
Bei Schwellenwerten handelt es sich um Standardwerte, die nur durch Ändern dieses
Werts überschritten werden können. Unter bestimmten Bedingungen können
Schwellenwerte überschritten werden, um Abweichungen im Farmentwurf Rechnung zu
tragen. Es ist jedoch wichtig zu wissen, dass sich dies auf die Leistung der Farm und auf
den geltenden Wert anderer Grenzwerte auswirken kann.
Der Standardwert bestimmter Schwellenwerte kann nur bis zu einem absoluten
Maximalwert überschritten werden. Ein gutes Beispiel hierfür ist wiederum die
Beschränkung der Dokumentgröße. Standardmäßig ist der Schwellenwert für die
Dokumentgröße auf 50 MB festgelegt, kann jedoch in einen Wert von maximal 2 GB
geändert werden.
Unterstützte Grenzwerte definieren den getesteten Wert für einen bestimmten
Parameter. Die Standardwerte für diese Grenzwerte wurden durch Tests festgelegt und
stellen die bekannten Einschränkungen des Produkts dar. Ein Überschreiten dieser
unterstützten Grenzwerte kann zu unerwarteten Ergebnissen, signifikanten
Leistungseinbußen und anderen negativen Folgen führen.
Bei einigen unterstützten Grenzwerten handelt es sich um konfigurierbare Parameter, die
standardmäßig auf den empfohlenen Wert festgelegt sind, während andere Grenzwerte
sich auf Parameter beziehen, die nicht durch einen konfigurierbaren Wert dargestellt
werden.
Ein Beispiel für einen unterstützten Grenzwert ist die Anzahl von Websitesammlungen
pro Webanwendung. Der unterstützte Grenzwert liegt bei 500.000. Dabei handelt es sich
um die größte Anzahl von Websitesammlungen pro Webanwendung, die beim Testen die
Leistungsbenchmarks erfüllt hat.
Es ist wichtig zu wissen, dass viele der in diesem Dokument angegebenen Grenzwerte
einen Punkt in einer Kurve darstellen, die eine wachsende Ressourcenauslastung und
einen damit einhergehenden Leistungsverlust bei Zunahme des Werts beschreibt.
Deshalb kann das Überschreiten bestimmter Grenzwerte, wie beispielsweise der Anzahl
von Websitesammlungen pro Webanwendung, nur zu einem anteiligen Verlust der
Farmleistung führen. In den meisten Fällen empfiehlt es sich jedoch, am oder zumindest
nah am festgelegten Grenzwert zu operieren, da akzeptable Leistungs- und
Zuverlässigkeitsvorgaben sich am ehesten erreichen lassen, wenn der Entwurf einer
Farm ein ausgewogenes Verhältnis zwischen Grenzwerten bietet.
23
Richtlinien für Schwellenwerte und unterstützte Grenzwerte werden auf Leistungsbasis
bestimmt. Mit anderen Worten, Sie können die Standardwerte für diese Grenzwerte
überschreiten, doch kann es dann zu einer Beeinträchtigung der Farmleistung und zu
Auswirkungen auf andere geltende Grenzwerte kommen, wenn Sie den Grenzwert
heraufsetzen. Viele Grenzwerte in SharePoint Server 2010 können geändert werden. Es
ist jedoch wichtig zu wissen, wie sich die Änderung eines bestimmten Grenzwerts auf
andere Teile der Farm auswirkt.
Wenn Sie Kontakt zu Microsoft Customer Support Services aufnehmen und es um ein
Produktionssystem geht, das die im Dokument Hardware and software requirements
(SharePoint Server 2010) aufgeführten Mindesthardwareanforderungen nicht erfüllt, kann
Ihnen erst dann ein vollständiger Support geboten werden, nachdem ein Systemupgrade
durchgeführt wurde, sodass die Mindestanforderungen erfüllt sind.
Festlegen von Grenzwerten
In SharePoint Server 2010 werden Schwellenwerte und unterstützte Grenzwerte durch
Tests festgelegt sowie durch Beobachten des Farmverhaltens bei zunehmenden
Auslastungen bis zu dem Punkt, an dem Farmdienste und -operationen ihren effektiven
Betriebsgrenzwert erreichen. Einige Farmdienste und -komponenten können eine höhere
Auslastung unterstützen als andere. Deshalb müssen Sie in einigen Fällen einen
Grenzwert zuweisen, der auf einem Durchschnittswert aus mehreren Faktoren beruht.
So weisen beispielsweise Beobachtungen des Farmverhaltens unter Last beim
Hinzufügen von Websitesammlungen darauf hin, dass bestimmte Funktionen eine
inakzeptabel lange Wartezeit aufweisen, während andere Funktionen weiterhin innerhalb
akzeptabler Parameter arbeiten. Aus diesem Grund ist der Maximalwert, der der Anzahl
von Websitesammlungen zugewiesen wird, nicht absolut, sondern beruht auf einer
vorhergesehenen Reihe von Nutzungsmerkmalen, bei der die allgemeine Farmleistung
beim festgelegten Grenzwert unter den meisten Umständen akzeptabel ist.
Wenn einige Dienste mit Parametern arbeiten, die über denen liegen, die zum Testen der
Grenzwerte verwendet werden, werden die effektiven Maximalgrenzwerte anderer
Dienste verringert. Deshalb sind eine strikte Kapazitätsverwaltung sowie Skalierungstests
für bestimmte Bereitstellungen erforderlich, um effektive Grenzwerte für die jeweilige
Umgebung aufzustellen.
Weitere Informationen zu Beschränkungen und Grenzwerten und deren Auswirkungen
auf den Kapazitätsverwaltungsprozess finden Sie unter SharePoint Server 2010Kapazitätsverwaltung: Softwarebeschränkungen und -grenzen.
Wichtige Unterschiede zwischen SharePoint
Server 2010 und Office SharePoint
Server 2007
SharePoint Server 2010 bietet mehr Features und ein flexibleres Topologiemodell als
frühere Versionen. Bevor Sie mit dieser komplexeren Architektur den Benutzern
leistungsfähigere Features und Funktionalität bereitstellen, müssen Sie deren
Auswirkungen auf die Kapazität und Leistung Ihrer Farm sorgfältig überprüfen.
In Microsoft Office SharePoint Server 2007 gab es vier Hauptdienste, die Sie in Anbietern
für gemeinsame Dienste (Shared Services Provider, SSP) aktivieren konnten:
Suchdienst, Dienste für Excel-Berechnungen, Benutzerprofildienst und
24
Geschäftsdatenkatalog-Dienst. Darüber hinaus gab es relativ wenige Clients mit einer
direkten Schnittstelle zu Microsoft Office SharePoint Server 2007.
In SharePoint Server 2010 gibt es mehr verfügbare Dienste, die als SharePointDienstanwendungen (SharePoint Service Application, SSA) bezeichnet werden.
Außerdem gibt es in SharePoint Server 2010 wesentlich mehr Clientanwendungen, die
mit der Farm interagieren können, einschließlich mehrerer neuer Office-Anwendungen,
mobiler Geräte, Designertools und Browsern. Im Folgenden finden Sie einige Beispiele,
wie sich erweiterte Clientinteraktionen auf die Kapazitätsaspekte auswirken:
 SharePoint Server 2010 enthält Anwendungen für thematische Kategorien, die in
Outlook integriert sind. Hiermit können Outlook 2010-Clients Informationen zu E-MailEmpfängern anzeigen, die aus der SharePoint Server-Farm abgerufen werden, wenn
E-Mail-Nachrichten im Outlook-Client angezeigt werden. Dies ermöglicht neue
Datenverkehrsmuster und Serverauslastungen, die Sie berücksichtigen sollten.

Mit einigen neuen Microsoft Office 2010-Clientfunktionen werden Daten automatisch
für die SharePoint Server-Farm aktualisiert, selbst wenn die Clientanwendungen
geöffnet sind, aber nicht aktiv verwendet werden. Solche Clients wie etwa SharePoint
Workspace und OneNote ermöglichen auch neue Datenverkehrsmuster und
Serverauslastungen, die Sie berücksichtigen sollten.

Die neuen Webinteraktivitätsfunktionen von SharePoint Server 2010, wie z. B. Office
Web Apps, ermöglichen die direkte Bearbeitung von Office-Dateien im Browser. Sie
verwenden AJAX-Aufrufe, welche neue Datenverkehrsmuster und
Serverauslastungen ermöglichen, die Sie berücksichtigen sollten.
In Microsoft Office SharePoint Server 2007 war der primäre Client für die Interaktion mit
dem Server der Webbrowser. Angesichts des umfangreicheren Featuresatzes in
SharePoint Server 2010 nehmen die Anforderungen pro Sekunde (RPS) insgesamt
voraussichtlich zu. Darüber hinaus ist der Prozentsatz an Anforderungen vom Browser
voraussichtlich niedriger als in Microsoft Office SharePoint Server 2007, was Platz für
den wachsenden Prozentsatz an neuem Datenverkehr von anderen Clients schafft, wenn
sie in der gesamten Organisation auf breiter Basis verwendet werden.
Darüber hinaus gibt es in SharePoint Server 2010 neue Funktionen wie z. B. die
systemeigene Unterstützung von eingebetteten Videos, was eine starke Belastung für die
Farm bedeuten kann. Einige Funktionen wurden außerdem erweitert, um eine bessere
Unterstützung als frühere Versionen zu bieten.
Im folgenden Abschnitt werden diese Clientinteraktionen, Dienste und Features sowie
deren allgemeine Leistungs- und Kapazitätsauswirkungen auf das System, die Sie beim
Entwerfen einer Lösung berücksichtigen sollten, beschrieben.
Weitere Informationen zum Ausführen eines Upgrades auf SharePoint Server 2010
finden Sie unter Upgrading to SharePoint Server 2010.
Dienste und Features
Die folgende Tabelle enthält eine vereinfachte allgemeine Beschreibung der
Ressourcenanforderungen für die verschiedenen Dienste auf jeder Ebene. Leere Zellen
bedeuten, dass der Dienst auf dieser Ebene nicht ausgeführt wird oder keine
Auswirkungen auf diese Ebene aus.
X – Bedeutet minimale oder unerhebliche Kosten für die Ressource. Der Dienst kann
diese Ressource gemeinsam mit anderen Diensten verwenden.
XX – Bedeutet mittlere Kosten für die Ressource. Der Dienst könnte diese Ressource
gemeinsam mit anderen Diensten verwenden, die minimale Auswirkungen haben.
25
XXX – Bedeutet hohe Kosten für die Ressource. Der Dienst sollte im Allgemeinen diese
Ressource nicht gemeinsam mit anderen Diensten verwenden.
Weitere Informationen zum Planen von SQL Server-Datenbanken finden Sie unter
Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server
2010).
Eine Liste mit Artikeln zur Kapazitätsverwaltung, die für viele spezielle Dienste und
Features von SharePoint Server 2010 verfügbar sind (weitere Artikel werden im Laufe
der Zeit hinzugefügt), finden Sie unter Ergebnisse der Leistungs- und Kapazitätstests und
Empfehlungen (SharePoint Server 2010).
Dienstanwendung
Webser Webser Anwendungs Anwendungs SQL Ser SQL Ser SQL Ser
ververserver-CPU
server-RAM ver-CPU ververCPU
RAM
IOPS
Speiche
r
SharePoint
XXX
Foundation-Dienst
XXX
Zentraladministrati
onsdienst
XX
XX
XX
XXX
XXX
X
X
X
XX
XXX
XXX
XXX
XXX
XXX
Protokollierungsdie XX
nst *
XX
SharePointSuchdienst
XXX
XXX
XXX
WordX
Anzeigedienstanwe
ndung *
X
XXX
XX
PowerPoint
Services *
XX
XXX
XX
Dienste für Excel- XX
Berechnungen
X
XX
XXX
Visio Services *
X
X
XXX
XXX
X
X
X
Access Services * X
X
XXX
XX
X
X
X
Benutzerprofildiens X
t
XX
XX
XX
XXX
XXX
XX
Verwalteter
X
Metadatendienst *
XX
XX
XX
X
X
XX
Web AnalyticsDienst *
X
X
XXX
XXX
XXX
Business
Connectivity
Service *
XX
XX
XXX
XX
XXX
XXX
26
Dienstanwendung
Webser Webser Anwendungs Anwendungs SQL Ser SQL Ser SQL Ser
ververserver-CPU
server-RAM ver-CPU ververCPU
RAM
IOPS
Speiche
r
InfoPath Forms
Services
XX
XX
XX
XX
X
X
X
Word Automation
Services
X
X
XXX
XX
X
X
X
PerformancePoint- XX
Dienstanwendung *
XX
XXX
XXX
X
X
X
Project-Dienst *
X
X
X
X
XXX
XXX
XX
Sandkastenlösung X
en *
X
XXX
XXX
Workflowfunktione XXX
n*
XXX
Timerdienst
XX
XX
XX
XX
PowerPivot *
X
X
XXX
XXX
XX
XX
XXX
Hinweis:
Ein Sternchen (*) steht für einen neuen Dienst in SharePoint Server 2010.

SharePoint Foundation-Dienst Der SharePoint-Basisdienst für die
Zusammenarbeit bei Inhalten. Bei großen Bereitstellungen von SharePoint Server
wird empfohlen, redundante Webserver basierend auf der erwarteten Auslastung
durch Datenverkehr zuzuordnen, die Größe der SQL Server-basierten Computer, von
denen die Inhaltsdatenbanken bereitgestellt werden, entsprechend anzupassen, und
Speicherplatz basierend auf der Farmgröße entsprechend zuzuordnen.

Zentraladministrationsdienst Der Administrationsdienst. Dieser Dienst stellt relativ
geringe Kapazitätsanforderungen. Es wird empfohlen, diesen Dienst auf mehreren
Farmservern zu aktivieren, um die Redundanz sicherzustellen.

Protokollierungsdienst Der Dienst, mit dem Verwendungs- und
Integritätsindikatoren zu Überwachungszwecken aufgezeichnet werden. Hierbei
handelt es sich um einen Dienst mit vielen Schreibvorgängen, der in Abhängigkeit
von der Anzahl von Indikatoren und der Häufigkeit, mit der sie protokolliert werden,
relativ viel Speicherplatz erfordern kann. Bei großen Bereitstellungen von SharePoint
Server 2010 wird empfohlen, die Verwendungsdatenbank getrennt von den
Inhaltsdatenbanken auf anderen SQL Server-basierten Computern zu speichern.

SharePoint-Suchdienstanwendung Die freigegebene Dienstanwendung mit
Indizierungs- und Abfragefunktionen. Im Allgemeinen handelt es sich dabei um einen
relativ ressourcenintensiven Dienst, der für sehr umfangreiche Inhaltsbereitstellungen
27
skaliert werden kann. Bei großen Bereitstellungen von SharePoint Server, in denen
die Suche in Unternehmen eine wichtige Rolle spielt, wird empfohlen, eine separate
"Dienstfarm" mit dedizierten Datenbankressourcen zum Hosten von
Suchdienstanwendungen, mehrere Anwendungsserver zur Bereitstellung bestimmter
Suchfunktionen (Durchforsten oder Abfragen) sowie dedizierte Zielwebserver in den
Inhaltsfarmen zu verwenden, um einen akzeptablen Durchsatz zum Durchforsten und
Abfragen sicherzustellen. Darüber hinaus können Sie die FAST-Dienstanwendungen
als Suchdienstanwendung aktivieren. Erstellen Sie einen oder mehrere FASTSuchconnector zum Indizieren von Inhalt mit FAST Search Server 2010 for
SharePoint, und erstellen Sie eine weitere FAST-Suchabfrage (SSA) zum Abfragen
von Inhalt, der von den FAST-Suchconnectors durchforstet wird.

Word-Anzeigedienstanwendung Durch Aktivieren dieses Diensts können Sie
Word-Dokumente direkt im Browser anzeigen. Dieser Dienst wird hinzugefügt, wenn
Sie Office Web Apps zusätzlich zu SharePoint Server 2010 installieren. Für diesen
Dienst muss ein Anwendungsserver die ursprünglichen Dateien für das Anzeigen im
Browser vorbereiten. Bei großen Bereitstellungen von SharePoint Server wird
aufgrund der Redundanz und des Durchsatzes die horizontale Skalierung dieses
Dienst auf mehrere Anwendungsserver empfohlen.
Hinweis:
Die Bearbeitung im Browser für Word und OneNote wird aktiviert, wenn Sie Office Web
Apps in der SharePoint Server 2010-Farm installieren. Dieses Feature wird auf den
Farmwebservern ausgeführt und verwendet keine Dienstanwendungen.

PowerPoint-Dienstanwendung Mit diesem Dienst können Benutzer PowerPointDateien anzeigen und direkt im Browser bearbeiten. Außerdem können damit
PowerPoint-Livepräsentationen übertragen und freigegeben werden. Dieser Dienst
wird hinzugefügt, wenn Sie Office Web Apps in SharePoint Server 2010 installieren.
Für diesen Dienst muss ein Anwendungsserver die ursprünglichen Dateien für das
Anzeigen im Browser vorbereiten. Bei großen Bereitstellungen von SharePoint
Server, wo dieser Dienst häufig verwendet wird, wird empfohlen, mehrere
Anwendungsserver bereitzustellen, um eine akzeptable Redundanz und einen
akzeptablen Durchsatz sicherzustellen, und weitere Webserver hinzuzufügen, wenn
auch die PowerPoint-Übertragung häufig verwendet wird.

Dienste für Excel-Berechnungen Mit diesem Dienst werden Excel-Arbeitsblätter
direkt im Browser angezeigt und Excel-Berechnungen auf dem Server ausgeführt.
Hiermit können Sie außerdem Arbeitsblätter direkt im Browser bearbeiten, wenn Sie
Office Web Apps in SharePoint Server 2010 installieren. Bei großen Bereitstellungen
von SharePoint Server, wo dieser Dienst häufig verwendet wird, wird empfohlen, eine
ausreichende Anzahl von Anwendungsservern mit genügend RAM zuzuordnen, um
eine akzeptable Leistung und einen akzeptablen Durchsatz sicherzustellen.

PowerPivot für SharePoint Mit diesem Dienst können PowerPivot-fähige ExcelArbeitsblätter direkt im Browser angezeigt werden. Bei großen Bereitstellungen von
SharePoint Server, wo dieser Dienst häufig verwendet wird, wird empfohlen, eine
ausreichende Anzahl von Anwendungsservern mit genügend RAM und CPU
zuzuordnen, um eine akzeptable Leistung und einen akzeptablen Durchsatz
sicherzustellen. Weitere Informationen finden Sie unter Hardware- und
Softwareanforderungen (PowerPivot für SharePoint).
28

Visio Services Mit diesem Dienst können Sie dynamische Visio-Diagramme direkt
im Browser anzeigen. Dieser Dienst ist vom Sitzungsstatusdienst abhängig, der eine
relativ kleine SQL Server-Datenbank benötigt. Für Visio Services muss ein
Anwendungsserver die ursprünglichen Visio-Dateien für das Anzeigen im Browser
vorbereiten. Bei großen Bereitstellungen von SharePoint Server, wo dieser Dienst
häufig verwendet wird, wird die horizontale Skalierung dieses Diensts auf mehrere
Anwendungsserver mit genügend CPU und RAM empfohlen, um eine akzeptable
Leistung und einen akzeptablen Durchsatz sicherzustellen.

Access-Dienstanwendung Mit diesem Dienst werden Access-Lösungen in
SharePoint Server 2010 gehostet. Bei großen Bereitstellungen von SharePoint
Server, wo dieser Dienst häufig verwendet wird, wird die horizontale Skalierung
dieses Diensts auf mehrere Anwendungsserver mit genügend RAM empfohlen, um
eine akzeptable Leistung und einen akzeptablen Durchsatz sicherzustellen. Der
Access-Dienst verwendet SQL Reporting Services, wofür eine SQL ServerDatenbank erforderlich ist, die mit anderen Datenbanken zusammengefasst werden
kann.

Benutzerprofildienst-Anwendung Dieser Dienst unterstützt die Szenarien für
soziale Netzwerke in SharePoint Server 2010 und ermöglicht Websites vom Typ
Meine Website, thematische Kategorien, Notizen, Profilsynchronisierung mit
Verzeichnissen und weitere Funktionen für soziale Netzwerke. Der Profildienst
erfordert drei relativ ressourcenintensive Datenbanken, nämlich die
Synchronisierungsdatenbank, die Profildatenbank und die Datenbank für
thematische Kategorien. Dieser Dienst ist abhängig von der Dienstanwendung für
verwaltete Metadaten. Bei großen Bereitstellungen von SharePoint Server sollten Sie
diesen Dienst eventuell auf eine Farm für gemeinsame Dienste verteilen und die
Größe der Datenbankserverserverebene ordnungsgemäß anpassen, um eine
akzeptable Leistung von häufigen Transaktionen und
Verzeichnissynchronisierungsaufträgen sicherzustellen.

Dienstanwendung für verwaltete Metadaten Der Dienst, mit dem der zentrale
Metadatenspeicher bereitgestellt wird und der die Veröffentlichung von Inhaltstypen
im gesamten Unternehmen ermöglicht. Dieser Dienst kann einer dedizierten Farm für
Dienste zugeteilt werden. Er erfordert eine Datenbank, die mit anderen Datenbanken
zusammengefasst werden kann.

Web Analytics-Dienstanwendung Mit diesem Dienst werden Statistiken zu den
Nutzungsmerkmalen der Farm erfasst und gespeichert. Für diesen Dienst gelten
relativ hohe Anforderungen bezüglich SQL Server-Ressourcen und Speicher. Dieser
Dienst kann einer dedizierten Farm für Dienste zugeteilt werden. Bei großen
Bereitstellungen von SharePoint Server wird empfohlen, die Web AnalyticsDatenbanken von anderen sehr wichtigen oder ressourcenintensiven Datenbanken
zu trennen, indem Sie sie auf unterschiedlichen Datenbankservern hosten.

Business Connectivity Service Dieser Dienst ermöglicht die Integration
verschiedener Unternehmensbranchenanwendungen in SharePoint Server 2010. Für
diesen Dienst müssen mit einem Anwendungsdienst Datenverbindungen zu externen
Ressourcen verwaltetet werden. Bei großen Bereitstellungen von SharePoint Server,
wo dieser Dienst häufig verwendet wird, wird empfohlen, eine ausreichende Anzahl
von Anwendungsservern mit genügend RAM zuzuordnen, um eine akzeptable
Leistung sicherzustellen.
29

InfoPath Forms Services Dieser Dienst ermöglicht browserbasierte Formulare in
SharePoint Server 2010 sowie die Integration in die InfoPath-Clientanwendung zum
Erstellen von Formularen. Dieser Dienst erfordert einen Anwendungsserver und ist
vom Sitzungsstatusdienst abhängig, der eine relativ kleine Datenbank benötigt.
Dieser Dienst kann mit anderen Diensten zusammengefasst werden und stellt relativ
geringe Kapazitätsanforderungen, die in Abhängigkeit davon, wie oft dieser Dienst
verwendet wird, erweitert werden können.

Word Automation Services-Anwendung Dieser Dienst ermöglicht die
Konvertierung von Word-Dateien von einem Format wie z. B. DOC in ein anderes
Format wie z. B. DOCX oder PDF. Für diesen Dienst ist ein Anwendungsserver
erforderlich. Bei großen Bereitstellungen von SharePoint Server, wo dieser Dienst
häufig verwendet wird, wird die horizontale Skalierung dieses Diensts auf mehrere
Anwendungsserver mit genügend CPU-Ressourcen empfohlen, um einen
akzeptablen Konvertierungsdurchsatz zu erzielen. Darüber hinaus benötigt dieser
Dienst eine relativ kleine Datenbank zum Verwalten der Warteschlange mit
Konvertierungsaufträgen.

PerformancePoint-Dienstanwendung Dieser Dienst ermöglicht PerformancePoint
Business Intelligence-Funktionen in SharePoint Server 2010 sowie das Erstellen
analytischer Visualisierungen. Für diesen Dienst sind ein Anwendungsserver und
eine Datenbank erforderlich. Bei großen Bereitstellungen von SharePoint Server, wo
dieser Dienst häufig verwendet wird, wird empfohlen, den Anwendungsservern
ausreichend RAM zuzuordnen, um eine akzeptable Leistung und einen akzeptablen
Durchsatz sicherzustellen.

Project Service Application Dieser Dienst ermöglicht neben SharePoint Server
2010 alle Planungs- und Nachverfolgungsfunktionen von Microsoft Project Server
2010. Für diesen Dienst sind ein Anwendungsserver und eine relativ
ressourcenintensive Datenbank erforderlich. Bei großen Bereitstellungen von
SharePoint Server, wo dieser Dienst häufig verwendet wird, sollten Sie für die Project
Server-Datenbank einen dedizierten Datenbankserver und eventuell sogar eine
dedizierte SharePoint Server-Farm für die Project Server-Verwaltungslösungen
verwenden.

Timerdienst Dieser Dienst ist für die Ausführung der verschiedenen geplanten
Aufgaben auf den unterschiedlichen Servern in der Farm zuständig. Vom System
werden verschiedene Zeitgeberaufträge ausgeführt. Einige dieser Zeitgeberaufträge
werden auf allen Farmservern ausgeführt, während andere Zeitgeberaufträge in
Abhängigkeit von der Serverrolle nur auf bestimmten Servern ausgeführt werden.
Manche Zeitgeberaufträge sind ressourcenintensiv und können in Abhängigkeit von
ihrer Aktivität und vom betroffenen Datenvolumen eine potenzielle Auslastung sowohl
auf dem lokalen Server als auch auf den Datenbankservern verursachen. Bei großen
Bereitstellungen von SharePoint Server, wo sich Zeitgeberaufträge potenziell auf die
Wartezeit für Endbenutzer auswirken können, wird empfohlen, einen dedizierten
Server zu verwenden, um die Ausführung der ressourcenintensiveren Aufträge zu
trennen.

Workflow Diese Funktion ermöglicht integrierte Workflows in SharePoint Server
2010 und führt Workflows auf dem Webserver aus. Die Ressourcenverwendung ist
abhängig von der Komplexität der Workflows und der Gesamtanzahl der
verarbeiteten Ereignisse. Bei großen Bereitstellungen von SharePoint Server, wo
30
dieser Dienst häufig verwendet wird, sollten Sie eventuell Webserver hinzufügen
oder einen dedizierten Server nur für den Workflowtimerdienst verwenden, um
sicherzustellen, dass der Datenverkehr von Endbenutzern nicht beeinträchtig wird
und dass Workflowvorgänge nicht verzögert werden.

Sandkastenlösungen Dieser Dienst ermöglicht die Verwendung dedizierter
Farmressourcen für benutzerdefinierten Code. Bei großen Bereitstellungen von
SharePoint Server, wo dieser Dienst häufig verwendet wird, sollten Sie eventuell
weitere dedizierte Webserver bereitstellen, falls die Serverleistung allmählich durch
benutzerdefinierten Code beeinträchtigt wird.
Neue Interaktionsmöglichkeiten von Clientanwendungen mit
SharePoint Server 2010
In diesem Abschnitt werden einige neue Interaktionsmöglichkeiten von
Clientanwendungen, die von SharePoint Server 2010 unterstützt werden, und die
Auswirkungen auf die Kapazitätsplanung beschrieben.
Die folgende Tabelle enthält eine vereinfachte allgemeine Beschreibung der typischen
Auslastung für das System aufgrund dieser neuen Funktionen:
X – Bedeutet eine minimale oder unerhebliche Auslastung für die Systemressourcen.
XX – Bedeutet eine mittlere Auslastung für die Systemressourcen.
XXX – Bedeutet eine hohe Auslastung für die Systemressourcen.
Client
Datenverkehr
Nutzlast
Office Web Apps
XXX
XX
PowerPoint-Übertragung
XXX
X
Word und PowerPoint 2010Clientanwendung
XX
X
OneNote-Clientanwendung
XXX
XXX
Outlook Connector für soziale
Netzwerke
XX
XX
SharePoint Workspace
XXX
XX

Office Web Apps Das Anzeigen und Bearbeiten im Web von Word-, PowerPoint-,
Excel- und OneNote-Dateien ist Teil der Browseranforderungen mit geringfügig
unterschiedlichen Datenverkehrsmerkmalen. Diese Art von Interaktion bedeutet eine
relativ hohe Auslastung mit Datenverkehr, um Funktionen wie etwa die gemeinsame
Dokumenterstellung zu ermöglichen. Bei großen Bereitstellungen von SharePoint
Server, wo diese Funktionalität aktiviert ist, sollten Sie von zusätzlicher Auslastung
auf den Webservern ausgehen.

PowerPoint-Übertragung Die Anforderungen im Zusammenhang mit dem
Anzeigen von PowerPoint-Livepräsentationen im Webbrowser sind ebenfalls Teil der
Browseranforderungen. Während PowerPoint-Liveübertragungen fordern die
beteiligten Clients Änderungen vom Dienst an. Bei großen Bereitstellungen von
31
SharePoint Server, wo diese Funktion häufig verwendet wird, sollten Sie von
zusätzlicher Auslastung auf den Webservern ausgehen.

Word und PowerPoint 2010-Clientanwendung Die Word- und PowerPoint 2010Clients weisen neue Features auf, die die SharePoint Server-Farm nutzen. Ein
Beispiel hierfür ist die gemeinsame Dokumenterstellung, bei der von allen an einer
Sitzung für die gemeinsame Dokumenterstellung beteiligten Clientanwendungen
häufig Updates zum Server hochgeladen und vom Server heruntergeladen werden.
Bei großen Bereitstellungen von SharePoint Server, wo diese Funktion häufig
verwendet wird, sollten Sie von zusätzlicher Auslastung auf den Webservern
ausgehen.

OneNote 2010-Clientanwendung Der OneNote 2010-Client interagiert mit der
SharePoint Server-Farm auf ähnliche Weise wie in der vorherigen OneNote-Version
und verwendet SharePoint Server 2010 für die Freigabe und gemeinsame Erstellung
von OneNote-Notizbüchern. Dieses Szenario bedeutet eine höhere Auslastung von
SharePoint Server 2010, selbst wenn die Client geöffnet ist, aber nicht aktiv
verwendet wird. Bei großen Bereitstellungen von SharePoint Server, wo diese
Funktion häufig verwendet wird, sollten Sie von zusätzlicher Auslastung auf den
Webservern ausgehen.

Outlook 2010-Clientanwendung In Outlook 2010 gibt es ein neues Feature – den
Outlook Connector für soziale Netzwerke –, der die SharePoint Server-Farm nutzt
(diese Komponente kann auch früheren Versionen von Outlook hinzugefügt werden).
Mithilfe dieses Features können Sie von der SharePoint Server-Farm angeforderte
Aktivitäten für soziale Netzwerke direkt in E-Mails anzeigen. Bei großen
Bereitstellungen von SharePoint Server, wo diese Funktionalität aktiviert ist, sollten
Sie von zusätzlicher Auslastung auf den Webservern ausgehen.

SharePoint Workspace SharePoint Workspace 2010-Clients weisen neue
Features auf, die die SharePoint Server-Farm nutzen und mit der Sie Websites,
Listen und Dokumentbibliotheken mit dem Client für die Offlineverwendung
synchronisieren können. SharePoint Workspace 2010 wird regelmäßig mit den
angefügten Serverobjekten synchronisiert, wenn der Client ausgeführt wird, und zwar
unabhängig davon, ob er aktiv verwendet wird. Bei großen Bereitstellungen von
SharePoint Server, wo diese Funktion häufig verwendet wird, sollten Sie von
zusätzlicher Auslastung auf den Webservern ausgehen.
Wichtige Unterscheidungsmerkmale bei
Bereitstellungen von SharePoint Server 2010
Jede Bereitstellung von SharePoint Server 2010 weist wichtige
Unterscheidungsmerkmale auf, durch die sie einzigartig wird und sich von anderen
Farmen unterscheidet. Diese wichtigen Unterscheidungsmerkmale können mithilfe der
folgenden vier Hauptkategorien beschrieben werden:
 Spezifikation Beschreibt die Hardware der Farm sowie die Topologie und
Konfiguration der Farm.

Arbeitsauslastung Beschreibt die Anforderungen an die Farm, einschließlich der
Anzahl von Benutzern und der Nutzungsmerkmale.

Dataset Beschreibt Inhaltsgrößen und die Inhaltsverteilung.
32

Integrität und Leistung Beschreibt die Leistung der Farm bezüglich der
Zielvorgaben für Wartezeit und Durchsatz.
Spezifikationen
Hardware
Bei der Hardware handelt es sich um die physikalischen Ressourcen des Computers wie
z. B. Prozessoren, Arbeitsspeicher und Festplatten. Hardware beinhaltet auch
physikalische Netzwerkkomponenten wie z. B. Netzwerkschnittstellenkarten (Network
Interface Card, NIC), Kabel, Switches, Router und Hardwarelastenausgleichsmodule.
Viele Leistungs- und Kapazitätsprobleme können dadurch behoben werden, dass Sie die
Verwendung der ordnungsgemäßen Hardware sicherstellen. Hingegen kann durch die
falsche Verwendung einer einzigen Hardwareressource, wie z. B. nicht genügend
Arbeitsspeicher auf einem Server, die Leistung der gesamten Farm beeinträchtigt
werden.
Topologie
Die Topologie bezeichnet die Verteilung und die gegenseitigen Beziehungen von
Farmhardware und -komponenten. Es gibt zwei Arten von Topologien:
 Logische Topologie Die Zuordnung von Softwarekomponenten wie z. B. Dienste
und Features in einer Farm.

Physikalische Topologie Die Zuordnung von Servern und physikalischen
Ressourcen.
In der Regeln bestimmen die Anzahl von Benutzern und die Nutzungsmerkmale die
physikalische Topologie einer Farm. Und Geschäftsanforderungen wie z. B. die
Notwendigkeit der Unterstützung bestimmter Features für die erwartete Auslastung
bestimmen die logische Topologie.
Konfiguration
Der Begriff "Konfiguration" bezeichnet Softwareeinstellungen und die Einstellungen für
Parameter. Darüber hinaus bezieht sich die Konfiguration auf die Zwischenspeicherung,
RSP, die Einstellungen für konfigurierbare Grenzwerte sowie alle Komponenten der
Softwareumgebung, die zur Erfüllung spezieller Anforderungen festgelegt oder geändert
werden können.
Arbeitsauslastung
Die Arbeitsauslastung definiert die operativen Hauptmerkmale der Farm, einschließlich
Benutzerbasis, Parallelität, verwendeten Features sowie Benutzer-Agents oder
Clientanwendungen, die zum Herstellen einer Verbindung mit der Farm verwendet
werden.
Den verschiedenen SharePoint Server-Features sind für die Farmressourcen
unterschiedliche Kosten zugeordnet. Durch die Beliebtheit von Features mit höheren
Kosten können die Leistung und die Integrität des Systems potenziell stark beeinträchtigt
werden. Wenn Sie die erwartete Auslastung und die erwarteten Nutzungsmerkmale
kennen, können Sie die Größe der Implementierung ordnungsgemäß anpassen und das
Risiko reduzieren, dass das System ständig in einem instabilen Zustand ausgeführt wird.
Benutzerbasis
Die Benutzerbasis einer SharePoint Server-basierten Anwendung ist eine Kombination
aus der Gesamtanzahl von Benutzern und deren geografische Verteilung. Darüber
hinaus gibt es innerhalb der Gesamtbenutzerbasis Untergruppen von Benutzern, die
bestimmte Features oder Dienste intensiver als andere Benutzergruppen verwenden. Die
33
Parallelität von Benutzern wird definiert als der Gesamtprozentsatz von Benutzern, die
das System zu einem bestimmten Zeitpunkt aktiv verwenden. Zu den Indikatoren für die
Definition der Benutzerbasis gehören die Gesamtanzahl eindeutiger Benutzer und die
Anzahl gleichzeitiger Benutzer.
Nutzungsmerkmale
Die Leistung einer Farm kann nicht nur durch die Anzahl der Benutzer, die mit dem
System interagieren, sondern auch durch die Nutzungsmerkmale beeinträchtigt werden.
In zwei Organisationen mit der gleichen Anzahl von Benutzern kann es erheblich
unterschiedliche Anforderungen geben bezüglich der Tatsache, wie oft Benutzer auf
Farmressourcen zugreifen und ob ressourcenintensive Features und Dienste in der Farm
aktiviert sind. Zu den Indikatoren zur Beschreibung der Nutzungsmerkmale gehören die
Häufigkeit eindeutiger Vorgänge, die allgemeine Mischung von Vorgängen (das
Verhältnis von Lese- und Schreibvorgängen und administrativen Vorgängen) sowie die
Verwendungsmuster und die Auslastung bei neuen Features, die in der Farm aktiviert
sind (z. B. Websites vom Typ Meine Website, Suche, Workflows und Office Web Apps).
Dataset
Das auf dem System gespeicherte Inhaltsvolumen und die Merkmale der Architektur, in
der dieser Inhalt gespeichert ist, können erhebliche Auswirkungen auf die allgemeine
Integrität und Leistung des Systems haben. Wenn Sie die Größe, die Zugriffshäufigkeit
und die Verteilung der Daten kennen, können Sie die Größe des Speichers im System
ordnungsgemäß anpassen und verhindern, dass ein Engpass entsteht, durch den
Benutzerinteraktionen mit Farmdiensten verlangsamt werden und die Benutzererfahrung
negativ beeinflusst wird.
Wenn Sie die Speicherarchitektur einer SharePoint Server-basierten Lösung
ordnungsgemäß schätzen und entwerfen möchten, müssen Sie wissen, welches
Datenvolumen Sie in dem System speichern werden, und wie viele Benutzer Daten aus
unterschiedlichen Datenquellen anfordern. Das Datenvolumen ist eine wichtige
Komponente beim Anpassen der Datenträgerkapazität, da dadurch die Leistung anderer
Features beeinflusst sowie potenziell die Netzwerklatenz und die verfügbare Bandbreite
beeinträchtigt werden kann. Zu den Indikatoren für die Definition des Datasets gehören
die Gesamtgröße des Inhalts, die Gesamtanzahl von Dokumenten, die Gesamtanzahl
von Websitesammlungen sowie die durchschnittliche und maximale Größe von
Websitesammlungen.
Integrität und Leistung
Die Integrität einer SharePoint Server-Farm ist im Grunde ein vereinfachtes Maß oder
eine vereinfachte Bewertung für die Zuverlässigkeit, Stabilität und Leistung des Systems.
Das Leistungsverhalten der Farm hinsichtlich der Zielvorgaben hängt im Prinzip von den
ersten drei Faktoren ab. Die Bewertung der Integrität und Leistung kann mithilfe
bestimmter Indikatoren nachverfolgt und beschrieben werden. Weitere Informationen
finden Sie unter Überwachen und Verwalten von SharePoint Server 2010. Zu diesen
Indikatoren zählen die Betriebszeit des Systems, die vom Endbenutzer wahrgenommene
Wartezeit, die Seitenfehlerrate und Ressourcenverwendungsindikatoren (CPU, RAM).
Jede signifikante Änderung bei Hardware, Topologie, Konfiguration, Arbeitsauslastung
oder Dataset kann zu erheblichen Abweichungen bei der Zuverlässigkeit und beim
Reaktionsverhalten des Systems führen. Mithilfe der Integritätsbewertung kann die
Leistung über einen bestimmten Zeitraum nachverfolgt werden, um festzustellen, welche
Auswirkungen geänderte Betriebsbedingungen oder Systemänderungen auf die
Zuverlässigkeit der Farm haben.
34
Referenzarchitekturen
SharePoint Server 2010 ist ein komplexes und leistungsfähiges Produkt, und es gibt
keine einheitliche Lösung für alle Architekturen. Jede SharePoint Server-Bereitstellung ist
einmalig und durch die Nutzungs- und Datenmerkmale definiert. Jede Organisation muss
einen gründlichen Kapazitätsverwaltungsprozess vornehmen und die Flexibilität des
SharePoint Server 2010-Systems effektiv nutzen, um eine Lösung mit der richtigen
Größe zu erstellen, die die Anforderungen der Organisation am besten erfüllt.
Mit dem Konzept der Referenzarchitekturen sollen die wichtigsten Kategorien von
SharePoint Server-Bereitstellungen beschrieben und veranschaulicht werden. Damit soll
jedoch Systemarchitekten kein Rezept zum Entwerfen von Lösungen angeboten werden.
Dieser Abschnitt befasst sich mit der Beschreibung der Vektoren für die Skalierung von
SharePoint Server.
Die hier aufgelisteten Architekturen sollen die allgemeinen Unterschiede zwischen diesen
allgemeinen Kategorien anhand grundlegender Kostenfaktoren und
Skalierungsbemühungen verdeutlichen.
Einzelserverbereitstellung
Die Architektur der Einzelserverbereitstellung besteht aus einem Server mit SharePoint
Server 2010 und einer unterstützten Version von SQL Server. Diese Architektur kann zu
Evaluierungszwecken, für Entwickler oder für eine isolierte, nicht kritische
Abteilungsimplementierung mit ein paar wenigen Benutzern geeignet sein. Von der
Verwendung für eine Produktionsumgebung wird jedoch abgeraten.
Kleine Farmbereitstellung
Eine kleine Farmbereitstellung besteht aus einem einzelnen Datenbankserver oder cluster und einem oder zwei SharePoint Server 2010-basierten Computern. Zu den
wichtigsten Merkmalen dieser Architektur zählen begrenzte Redundanz und begrenztes
Failover sowie ein minimales aktiviertes SharePoint Server-Funktionsspektrum.
Eine kleine Farm ist nur für begrenzte Bereitstellungen geeignet, mit wenigen aktivierten
Dienstanwendungen, einer relativ kleinen Benutzerbasis, einer relativ geringen
Auslastung (ein paar Anforderungen pro Minute bis zu sehr wenigen Anforderungen pro
Sekunde) und einem relativ geringen Datenvolumen (10 oder mehr GB).
35
Mittlere Farmbereitstellung
Bei dieser Architektur wird die Topologie in drei Ebenen unterteilt: dedizierte Webserver,
dedizierte Anwendungsserver und mindestens ein Datenbankserver oder -cluster. Die
Trennung der Ebene der Front-End-Server und der Ebene der Anwendungsservers
ermöglicht eine größere Flexibilität bei der Dienstisolierung und das Verteilen der
Auslastung im System.
Dies ist die gängigste Architektur, und sie weist ein breites Spektrum an Diensttopologien
und Farmgrößen auf. Eine mittlere Farmbereitstellung eignet sich für Umgebungen, die
Folgendes aufweisen:
 Mehrere Dienstanwendungen, die auf mehrere Server verteilt sind. Zu einer
typischen Featuregruppe können der Office Web Apps-Dienst, der
Benutzerprofildienst, der verwaltete Metadatendienst und die Dienste für ExcelBerechnungen zählen.

Eine Benutzerbasis von Zehntausenden von Benutzern und eine Auslastung von 10
bis 50 Anforderungen pro Sekunde.

Ein Datenspeicher mit einem oder zwei Terabyte.
36
Große Farmbereitstellung
Bei großen Farmbereitstellungen werden Dienste und Lösungen auf mehrere Farmen
verteilt, und außerdem erfolgt die horizontalt Skalierung der Ebenen in einer einzelnen
Farm. Mehrere SharePoint Server-Dienste können in einer dedizierten Farm für Dienste
bereitgestellt werden, von der Anforderungen mehrerer Farmen, die die Dienste in
Anspruch nehmen, verarbeitet werden. Bei diesen großen Architekturen gibt es in der
Regel Webserver, mehrere Anwendungsserver, in Abhängigkeit von den
Nutzungsmerkmalen der einzelnen lokalen (nicht gemeinsamen) Dienste, sowie mehrere
SQL Server-basierte Server oder SQL Server-Cluster, in Abhängigkeit von der
Inhaltsgröße und den Datenbanken für Anwendungsdienste, die in der Farm aktiviert
sind. Große Farmarchitekturen sind für Bereitstellungen gedacht, die Folgendes
aufweisen:
 Mehrere Dienstanwendungen, die in einer dedizierten Farm für Dienste
zusammengefasst und genutzt werden. In der Regel handelt es sich dabei um den
Benutzerprofildienst, den verwalteten Metadatendienst und Web Analytics.

Die meisten anderen Dienstanwendungen werden lokal aktiviert.

Eine Benutzerbasis mit Hunderttausenden von Benutzern.

Eine Auslastung mit Hunderten von Anforderungen pro Sekunde.
37

Ein Dataset mit mindestens 10 Terabyte.
38
Siehe auch
Konzepte
Kapazitätsplanung für SharePoint Server 2010
Testen der Leistung für SharePoint Server 2010
Überwachen und Verwalten von SharePoint Server 2010
SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und -grenzen
Ergebnisse der Leistungs- und Kapazitätstests und Empfehlungen (SharePoint Server
2010)
Performance and capacity technical case studies (SharePoint Server 2010) (in englischer
Sprache)
Weitere Ressourcen
Hardware and software requirements (SharePoint Server 2010)
39
Kapazitätsplanung für SharePoint Server
2010
In diesem Artikel wird die Kapazitätsplanung für eine Microsoft SharePoint Server 2010Farm beschrieben. Wenn Sie mit der Kapazitätsplanung und -verwaltung vertraut sind,
können Sie Ihr Wissen auf die Systemgrößenanpassung anwenden. Die
Größenanpassung bezeichnet die Auswahl und Konfiguration einer entsprechenden
Datenarchitektur, einer logischen und physikalischen Topologie sowie der Hardware für
eine Lösungsplattform. Es gibt eine Reihe von Aspekten bei der Kapazitätsverwaltung
und -verwendung, die Auswirkungen darauf haben, wie Sie die geeignetsten Hardwareund Konfigurationsoptionen festlegen sollten.
Bevor Sie diesen Artikel lesen, sollten Sie Kapazitätsverwaltung und Größengestaltung
für SharePoint Server 2010 (Übersicht) lesen.
In diesem Artikel werden die Schritte beschrieben, die Sie für eine effektive
Kapazitätsverwaltung für Ihre Umgebung ausführen sollten. Jeder Schritt erfordert
bestimmte Informationen für die erfolgreiche Ausführung und weist eine Reihe von
Resultaten auf, die Sie im nächsten Schritt verwenden werden. Für jeden Schritt werden
diese Anforderungen und Resultate in Tabellen aufgelistet.
Inhalt dieses Artikels:
 Schritt 1: Modellierung

Schritt 2: Entwurf

Schritt 3: Pilot-, Test- und Optimierungsphase

Schritt 4: Bereitstellung

Schritt 5: Überwachung und Wartung
Schritt 1: Modellierung
Die Modellierung Ihrer SharePoint Server 2010-basierten Umgebung beginnt mit der
Analyse der vorhandenen Lösungen und der Bestimmung des erwarteten Bedarfs und
der Zielvorgaben für die geplante Bereitstellung. Zunächst erfassen Sie Informationen zu
Benutzerbasis, Datenanforderungen und Zielvorgaben für Wartezeit und Durchsatz und
dokumentieren die SharePoint Server-Features, die Sie bereitstellen möchten. Anhand
dieses Abschnitts sollten Sie sich damit vertraut machen, welche Daten Sie sammeln
sollten, wie Sie sie sammeln sollten, und wie diese Daten in nachfolgenden Schritten
verwendet werden können.
Analysieren der erwarteten Arbeitsauslastung und des Datasets
Für die geeignete Größenanpassung einer SharePoint Server 2010-Implementierung
müssen Sie den Bedarf, den Ihre Lösung bewältigen soll, analysieren und kennen.
Hierfür müssen Sie in der Lage sein, sowohl die Arbeitsauslastungsmerkmale wie etwa
die Anzahl der Benutzer und die am häufigsten verwendeten Vorgänge als auch die
Datasetmerkmale wie etwa Inhaltsgröße und Inhaltsverteilung zu beschreiben.
40
In diesem Abschnitt werden bestimmte Metriken und Parameter, die Sie erfassen sollten,
sowie Mechanismen zu deren Erfassung behandelt.
Arbeitsauslastung
Die Arbeitsauslastung beschreibt den durch das System zu unterstützenden Bedarf, die
Benutzerbasis und die Nutzungsmerkmale. In der folgenden Tabelle finden Sie einige
wichtige Metriken, die beim Bestimmen der Arbeitsauslastung hilfreich sind. Mithilfe
dieser Tabelle können Sie diese Metriken beim Erfassen aufzeichnen.
Arbeitsauslastungsmerkmale
Wert
Durchschnittliche tägliche
Anforderungen pro Sekunde
Durchschn. Anforderungen pro
Sekunde zu Spitzenzeiten
Gesamtanzahl eindeutiger
Benutzer pro Tag
Durchschnittliche tägliche Anzahl
gleichzeitiger Benutzer
Höchstwert gleichzeitiger Benutzer
zu Spitzenzeiten
Gesamtanzahl der Anforderungen
pro Tag
Erwartete Arbeitslastverteilung
Anzahl der Anforderungen pro Tag %
Webbrowser – Suchdurchforstung
Webbrowser – Allgemeine
Zusammenarbeitsinteraktion
Webbrowser – Allgemeine soziale
Interaktion
Webbrowser – Allgemeine
Interaktion
Webbrowser – Office Web Apps
Office-Clients
OneNote-Client
SharePoint Workspace
Outlook-RSS-Synchronisierung
Outlook Connector für soziale
Netzwerke
41
Arbeitsauslastungsmerkmale
Wert
Andere Interaktionen
(Benutzerdefinierte
Anwendungen/Webdienste)

Gleichzeitige Benutzer – Die Gleichzeitigkeit von Vorgängen, die in der Serverfarm
ausgeführt werden, wird in der Regel gemessen als die Anzahl eindeutiger Benutzer,
die Anforderungen in einem bestimmten Zeitraum generieren. Die wichtigen Metriken
sind der tägliche Durchschnittswert und die gleichzeitigen Benutzer zu Spitzenzeiten.

Anforderungen pro Sekunde (Requests per Second, RPS) – RPS ist ein häufig
verwendeter Indikator zur Beschreibung des Bedarfs in der Serverfarm, ausgedrückt
in der Anzahl von Anforderungen, die von der Farm pro Sekunde verarbeitet werden.
Dabei erfolgt jedoch keine Unterscheidung bezüglich des Typs oder der Größe der
Anforderungen. Die Benutzerbasis jeder Organisation generiert eine
Systemauslastung mit einer von den speziellen Nutzungsmerkmalen der
Organisation abhängigen Geschwindigkeit. Weitere Informationen zu diesem Begriff
finden Sie im Abschnitt Glossar unter Kapazitätsverwaltung und Größengestaltung
für SharePoint Server 2010 (Übersicht).

Gesamtanzahl der Anforderungen pro Tag – Die Gesamtanzahl der
Anforderungen pro Tag ist ein geeigneter Indikator für die Gesamtarbeitsauslastung,
die vom System bewältigt werden muss. In der Regel werden alle Anforderungen, mit
Ausnahmen von Authentifizierungshandshakeanforderungen (HTTP-Status 401),
über einen Zeitraum von 24 Stunden gemessen.

Gesamtanzahl der Benutzer pro Tag – Die Gesamtanzahl der Benutzer ist ein
weiterer geeigneter Indikator für die Gesamtarbeitsauslastung, die vom System
bewältigt werden muss.
Hinweis:
Die Gesamtanzahl der Benutzer pro Tag kann auf das Wachstumspotenzial bei der
Arbeitsauslastung in der Farm hinweisen. Wenn z. B. die Anzahl potenzieller Benutzer
100.000 Mitarbeiter beträgt, sind 15.000 Benutzer pro Tag ein Hinweis darauf, dass die
Arbeitsauslastung im Laufe der Zeit erheblich zunehmen kann, wenn es immer mehr
Benutzer werden.

Arbeitslastverteilung – Durch die Kenntnis der Verteilung der Anforderungen
basierend auf den Clientanwendungen, die mit der Farm interagieren, können Sie
den erwarteten Trend und die erwarteten Änderungen bei der Arbeitsauslastung
nach der Migration zu SharePoint Server 2010 besser vorhersagen. Wenn Benutzer
auf neuere Clientversionen wie z. B. Office 2010 umstellen und die neuen
Arbeitsauslastungsmuster zu verwenden beginnen, wird davon ausgegangen, dass
die Anforderungen pro Sekunde (RPS) und die Gesamtanzahl der Anforderungen
zunehmen werden. Für jeden Client können wir die Anzahl der eindeutigen Benutzer
während eines bestimmten Zeitraums an einem Tag sowie die Gesamtanzahl der
Anforderungen, die vom Client oder Feature auf dem Server generiert werden,
beschreiben.
Beispielsweise ist im folgenden Diagramm eine Momentaufnahme einer internen
Microsoft-Life-Umgebung mit einer typischen Lösung für soziale Netzwerke
42
dargestellt. Anhand dieses Beispiels ist erkennbar, dass der Großteil der Auslastung
durch den Suchcrawler und das typische Webbrowsing der Endbenutzer generiert
wird. Darüber hinaus sehen Sie, dass durch den neuen Outlook Connector für
soziale Netzwerke eine erhebliche Auslastung generiert wird (6,2 % der
Anforderungen).
43
44
Bestimmen der Produktionsarbeitsauslastung
45
Bei der Bestimmung des erforderlichen Durchsatzes Ihrer Farm beginnen Sie mit dem
Bestimmen der in Ihrer Farm verwendeten Transaktionsmischung. Konzentrieren Sie sich
auf die Analyse der am häufigsten verwendeten Transaktionen, die vom System
angeboten werden, und stellen Sie fest, wie oft sie von wie vielen Benutzern verwendet
werden. Dadurch können Sie später überprüfen, ob die Farm eine derartige Auslastung
in der Testumgebung unterstützt.
Im folgenden Diagramm ist die Beziehung von Arbeitsauslastung und Auslastung im
System beschrieben:
Sammeln Sie die folgenden Informationen, um die erwartete Arbeitsauslastung zu
bestimmen:
 Identifizieren Sie Benutzerinteraktionen, wie z. B. typisches Browsen in Webseiten,
Dateidownloads und -uploads, das Anzeigen und Bearbeiten von OfficeWebanwendungen im Browser, Interaktionen bei der gemeinsamen
Dokumenterstellung, Synchronisierungen von SharePoint Workspace-Websites,
Outlook Connector für soziale Netzwerke, RSS-Synchronisierung (in Outlook oder
46
anderen Viewern), PowerPoint-Übertragungen, freigegebene OneNote-Notizbücher,
freigegebene Excel Services-Arbeitsmappen, freigegebene Access ServicesAnwendungen usw. Weitere Informationen finden Sie im Abschnitt Dienste und
Features des Artikels Kapazitätsverwaltung und Größengestaltung für SharePoint
Server 2010 (Übersicht). Konzentrieren Sie sich auf das Identifizieren der
Interaktionen, die für Ihre Bereitstellung eindeutig sind, und bestimmen Sie die
erwarteten Auswirkungen einer derartigen Auslastung. Beispiele hierfür kann die
zahlreiche Verwendung von InfoPath-Formularen, Excel Services-Berechnungen und
ähnlichen dedizierten Lösungen sein.

Identifizieren Sie Systemvorgänge, wie z. B. inkrementelle Suchdurchforstungen,
tägliche Sicherungen, Zeitgeberaufträge für die Profilsynchronisierung, Web
Analytics-Verarbeitungen, die Protokollierung von Zeitgeberaufträgen usw.

Bestimmen Sie die Gesamtanzahl der Benutzer pro Tag, die voraussichtlich die
einzelnen Features verwenden werden, und leiten Sie die geschätzte Anzahl
gleichzeitiger Benutzer und eine Übersicht über die Anforderungen pro Sekunde ab.
Dabei werden Sie von einigen Annahmen ausgehen, wie z. B. die aktuelle Anzahl
gleichzeitiger Benutzer und der RPS-Faktor für gleichzeitige Benutzer, der für die
verschiedenen Features unterschiedlich ist. Für diesen Vorgang sollten Sie die
Arbeitsauslastungstabelle weiter oben in diesem Abschnitt heranziehen. Sie sollten
sich nicht auf den durchschnittlichen Durchsatz, sondern unbedingt auf Spitzenzeiten
konzentrieren. Durch die Planung für Spitzenaktivität können Sie die Größe Ihrer
SharePoint Server 2010-basierten Lösung ordnungsgemäß anpassen.
Wenn eine Microsoft Office SharePoint Server 2007-Lösung vorhanden ist, können Sie
ein Data Mining für die IIS-Protokolldateien ausführen oder andere
Webüberwachungstools verwenden, um bestimmte erwartete Verhaltensweisen der
vorhandenen Lösung besser zu verstehen. Weitere Informationen finden Sie in den
Anweisungen im nächsten Abschnitt. Falls Sie nicht von einer vorhandenen Lösung
migrieren, sollten Sie grobe Schätzungen in die Tabelle eintragen. In späteren Schritten
müssen Sie Ihre Vorgaben überprüfen und das System optimieren.
Analysieren der IIS-Protokolle von SharePoint Server 2010
Zur Ermittlung wichtiger Metriken zu einer vorhandenen SharePoint Server 2010Bereitstellung, wie z. B. wie viele Benutzer aktiv sind, wie stark sie das System
beanspruchen, welche Art von Anforderungen eingehen und von welchen Clienttypen sie
stammen, müssen Daten aus ULS- und IIS-Protokollen extrahiert werden. Die
Verwendung von Log Parser ist eine der einfachsten Methoden zur Beschaffung dieser
Daten. Hierbei handelt es sich um ein leistungsfähiges Tool, das kostenlos von der
Microsoft-Website heruntergeladen werden kann. Mit dem Log Parser kann eine Reihe
von Text- und Binärformaten gelesen und geschrieben werden, einschließlich aller IISFormate.
Ausführliche Informationen zum Analysieren der Verwendung von SharePoint Server
2010 mit dem Log Parser finden Sie unter Analysieren der Verwendung von Microsoft
SharePoint-Produkten und -Technologien
(http://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413ca3f7-2e0be6d5532e&displaylang=de-de).
Log Parser 2.2 kann auf der Webseite
http://www.microsoft.com/downloads/details.aspx?familyid=890cd06b-abf8-4c25-91b2f8d975cf8c07&displaylang=de-de heruntergeladen werden.
47
Dataset
Das Dataset beschreibt das auf dem System gespeicherte Inhaltsvolumen und wie es im
Datenspeicher verteilt werden kann. In der folgenden Tabelle finden Sie einige wichtige
Metriken, die beim Bestimmen des Datasets hilfreich sind. Mithilfe dieser Tabelle können
Sie diese Metriken beim Erfassen aufzeichnen.
Objekt
Wert
Datenbankgröße (in GB)
Anzahl der Inhaltsdatenbanken
Anzahl der Websitesammlungen
Anzahl der Webanwendungen
Anzahl der Websites
Suchindexgröße (Anzahl der Elemente)
Anzahl der Dokumente
Anzahl der Listen
Durchschnittliche Websitegröße
Größte Websitegröße
Anzahl der Benutzerprofile

Inhaltsgröße – Die Kenntnis der Größe des Inhalts, den Sie voraussichtlich im
SharePoint Server 2010-System speichern werden, spielt für das Planen und
Entwerfen des Systemspeichers sowie für die ordnungsgemäße Größenanpassung
der Suchlösung, mit der dieser Inhalt durchforstet und indiziert wird, eine wichtige
Rolle. Die Inhaltsgröße wird als Gesamtspeicherplatz beschrieben. Wenn Sie Inhalt
aus einer vorhandenen Bereitstellung migrieren, ist die Festlegung der Gesamtgröße,
die Sie verschieben werden, relativ einfach. Bei der Planung sollten Sie das
Wachstum im Laufe der Zeit basierend auf dem vorhergesagten Trend
berücksichtigen.

Gesamtanzahl der Dokumente – Neben der Inhaltsgröße muss unbedingt die
Gesamtanzahl der Elemente nachverfolgt werden. Das System reagiert
unterschiedlich, wenn 100 GB Daten aus 50 Dateien mit jeweils 2 GB bestehen oder
wenn 100.000 Dateien mit jeweils 1 KB vorhanden sind. Bei großen Bereitstellungen
gilt, je weniger ein einzelnes Element, ein Dokument oder ein Dokumentbereich
belastet wird, desto besser ist die Leistung. Weit verteilte Inhalte wie z. B. viele
kleinere Dateien in vielen Websites und Websitesammlungen können einfacher zur
Verfügung gestellt werden, als dies bei einer einzelnen großen Dokumentbibliothek
mit sehr großen Dateien der Fall ist.

Maximale Websitesammlungsgröße – Sie müssen unbedingt die größte
Inhaltseinheit identifizieren, die Sie in SharePoint Server 2010 speichern werden.
Gewöhnlich verhindern organisatorische Anforderungen das Aufteilen dieser
48
Inhaltseinheit. Die durchschnittliche Größe aller Websitesammlungen und die
geschätzte Gesamtanzahl von Websitesammlungen sind zusätzliche Indikatoren zum
Identifizieren der bevorzugten Datenarchitektur.

Datenmerkmale von Dienstanwendungen – Neben der Analyse der
Speicheranforderungen für den Inhaltsspeicher sollten Sie die Größe der folgenden
anderen SharePoint Server 2010-Speicher analysieren und bestimmen:

Gesamtgröße des Suchindexes

Die Gesamtgröße der Profildatenbank basierend auf der Anzahl von Benutzern im
Profilspeicher

Die Gesamtgröße der Datenbank für Funktionen und Daten für das soziale Netzwerk
basierend auf der erwarteten Anzahl von Kategorien, Kollegen und Aktivitäten

Die Größe des Metadatenspeichers

Die Größe der Verwendungsdatenbank
 Die Größe der Web Analytics-Datenbank
Weitere Informationen zum Bestimmen der Datenbankgrößen finden Sie unter Speicherund SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010).
Festlegen von Zielvorgaben für die Leistung und Zuverlässigkeit der
Farm
Eines der Resultate von Schritt 1: Modellierung ist die Kenntnis der Zielvorgaben für die
Leistung und Zuverlässigkeit, die für die Anforderungen Ihrer Organisation am besten
geeignet sind. Eine ordnungsgemäß entworfene SharePoint Server-Lösung sollte eine
Betriebszeit von "vier Neunen" 99,99 % mit Serverreaktionszeiten unterhalb einer
Sekunde erzielen.
Die folgenden Indikatoren können zum Beschreiben der Leistung und Zuverlässigkeit der
Farm verwendet werden:
 Serververfügbarkeit – Dies wird in der Regel durch die prozentuale
Gesamtbetriebszeit des Systems beschrieben. Sie sollten unerwartete Downtime
nachverfolgen und die Gesamtverfügbarkeit mit der von Ihnen festgelegten
Zielvorgabe vergleichen. Die Zielvorgaben werden im Allgemeinen durch eine Reihe
von Neunen beschrieben (z. B. 99 %, 99,9 %, 99,99 %)

Serverreaktionszeit – Die Zeit, die die Farm zur Erfüllung von Anforderungen
benötigt, ist ein guter Indikator für die Nachverfolgung der Farmintegrität. Dieser
Indikator wird gewöhnlich als serverseitige Wartezeit bezeichnet, und im Allgemeinen
wird die durchschnittliche oder mittlere Wartezeit (50. Quantil) der täglich bedienten
Anforderungen verwendet. Die Zielvorgaben werden generell als Sekundenbruchteile
oder Sekunden beschrieben. Wenn es in Ihrer Organisation die Zielvorgabe gibt,
Seiten aus SharePoint Server 2010 in weniger als zwei Sekunden verfügbar zu
machen, muss die serverseitige Zielvorgabe Sekundenbruchteile sein, damit
genügend Zeit vorhanden ist, dass die Seite den Client über das Netzwerk erreichen
kann und im Browser gerendert werden kann. Im Allgemeinen sind außerdem
längere Serverreaktionszeiten ein Hinweis auf eine instabile Farm, da dies
normalerweise Auswirkungen auf den Durchsatz hat und RPS selten Schritt halten
kann, wenn Sie für die meisten Anforderungen mehr als eine Sekunde auf dem
Server verbringen.
49

Serverspitzenwerte – Ein weiterer guter serverseitiger Wartezeitindikator, der
nachverfolgt werden sollte, ist das Verhalten der 5 % der langsamsten
Anforderungen. Bei langsameren Anforderungen handelt es sich häufig um
Anforderungen, die im System eingehen, wenn es stark ausgelastet ist, oder sogar
noch häufiger um Anforderungen, die durch seltenere Aktivitäten während der
Interaktion von Benutzern mit dem System beeinträchtigt werden. Bei einem stabilen
System sind auch die langsamsten Anforderungen unter Kontrolle. Das Ziel ist in
diesem Fall ähnlich wie bei der Serverreaktionszeit. Zum Erreichen einer Antwort
unterhalb einer Sekunde bei Serverspitzenwerten müssen Sie jedoch für die
Spitzenwerte eine Menge von Ersatzressourcen in das System einbauen.

Systemressourcenverwendung – Weitere häufig verwendete Indikatoren zum
Nachverfolgen der Systemintegrität stellen eine Sammlung von
Systemleistungsindikatoren dar, mit denen der Status jedes Servers in der
Farmtopologie identifiziert wird. Die am häufigsten verwendeten
Nachverfolgungsindikatoren sind die CP-Auslastung: % und Verfügbarer
Arbeitsspeicher. Es gibt jedoch zusätzliche Leistungsindikatoren zum Identifizieren
eines instabilen Systems. Weitere Informationen finden Sie in Schritt 5:
Überwachung und Wartung.
Schritt 2: Entwurf
Nachdem Sie Fakten oder Schätzungen für die bereitzustellende Lösung gesammelt
haben, können Sie mit dem nächsten Schritt des Entwerfens einer vorgeschlagenen
Architektur fortfahren, die Ihrer Meinung nach den erwarteten Bedarf bewältigen kann.
Am Ende dieses Schritts sollte ein Entwurf für die physikalische Topologie und ein Layout
für die logische Topologie vorliegen, sodass Sie mit notwendigen Bestellungen beginnen
können.
Die Hardwarespezifikationen und die Anzahl der Server im Layout sind eng miteinander
verknüpft. Für eine bestimmte Auslastung gibt es mehrere Lösungen, die für die
Bereitstellung zur Auswahl stehen. Gewöhnlich werden entweder ein paar wenige
leistungsstarke Server (vertikale Skalierung) oder aber eine größere Anzahl
leistungsschwächerer Server (horizontale Skalierung) verwendet. Jede Lösung weist Vorund Nachteile bezüglich Kapazität, Redundanz, Leistung, Kosten, Platzbedarf usw. auf.
Es wird empfohlen, diesen Schritt mit der Festlegung der Architektur und Topologie zu
beginnen. Definieren Sie das Layout der verschiedenen Farmen und der verschiedenen
Dienste in jeder Farm, und wählen Sie dann die Hardwarespezifikationen für die
einzelnen Server Ihres Entwurfs aus. Dieses Verfahren können Sie auch ausführen,
indem Sie die bereitzustellenden Hardwarespezifikationen identifizieren (viele
Organisationen sind auf einen bestimmten Firmenstandard festgelegt) und anschließend
die Architektur und Topologie definieren.
Zeichnen Sie anhand der folgenden Tabelle die Entwurfsparameter auf. Die
angegebenen Daten sind Beispieldaten und sollten nicht für die Größenanpassung Ihrer
Farm verwendet werden. Hiermit soll lediglich aufgezeigt werden, wie Sie diese Tabelle
für Ihre eigenen Daten verwenden.
50
Rolle
Typ
Anza Prozesso RA IOPSDatenträgerg Datenlaufw
(Stand hl der ren
M Anforderun röße
erk
ard
Serve
gen
BS+Protokoll
oder
r
virtuell)
Webserver
Virtuell 4
4 Kerne 8
n/v
400 GB
n/v
Inhaltsdatenbankserver Standa 1
4 Quad- 48 2000
rd
Clust Core mit
er
2,33 GHz
400 GB
20 300GBDatenträge
r
mit 15.000
Umdrehun
gen pro
Minute
Anwendungsserver
Virtuell 4
4 Kerne 16 n/v
400 GB
n/v
SuchdurchforstungZielwebserver
Virtuell 1
4 Kerne 8
n/v
400 GB
n/v
Suchabfrageserver
Standa 2
rd
2 Quad- 32 n/v
Core mit
2,33 GHz
400 GB
500 GB
Suchcrawlerserver
Standa 2
rd
2 Quad- 16 400
Core mit
2,33 GHz
400 GB
n/v
100 GB
16 150GBDatenträge
r mit
15.000
Umdrehun
gen pro
Minute
2000
100 GB
(optimiert
für das
Schreiben)
16 150GBDatenträge
r mit
15.000
Umdrehun
gen pro
Minute
Server mit
Standa 1
4 Quad- 48 4000
Suchdurchforstungsdate rd
Clust Core mit
(optimiert
nbank
er
2,33 GHz
für das
Lesen)
SucheigenschaftenStanda 1
4 Quad- 48
Informationsspeicherdat rd
Clust Core mit
enbank +
er
2,33 GHz
Administrationsdatenban
kserver
Bestimmen der Ausgangsarchitektur
In diesem Abschnitt wird beschrieben, wie Sie eine Ausgangsarchitektur auswählen.
51
Bei der Bereitstellung von SharePoint Server 2010 stehen eine Reihe von Topologien
zum Implementieren Ihrer Lösung zur Auswahl. Sie können einen einzelnen Server
bereitstellen oder viele Server auf eine SharePoint Server-Farm mit gruppierten oder
gespiegelten Datenbankservern und separaten Anwendungsservern für verschiedene
Dienste horizontal skalieren. Später wählen Sie die Hardwarekonfigurationen basierend
auf den Anforderungen der verschiedenen Rollen und basierend auf Kapazität,
Verfügbarkeit und Redundanzanforderungen aus.
Beginnen Sie mit der Überprüfung der verschiedenen Referenzarchitekturen, und
bestimmen Sie die Farmstruktur. Entscheiden Sie, ob die Lösung auf mehrere Farmen
verteilt werden soll, oder fassen Sie Dienste, wie z. B. die Suche, in einer dedizierten
Farm zusammen. Weitere Informationen finden Sie im Abschnitt Referenzarchitekturen
unter Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010
(Übersicht).
Technische Fallstudien für SharePoint Server 2010
Die Dokumentation zur Kapazitätsverwaltung für SharePoint Server 2010 beinhaltet eine
Reihe von technischen Fallstudien für bestehende Produktionsumgebungen. Hier finden
Sie ausführliche Beschreibungen vorhandener SharePoint Server-basierter
Produktionsumgebungen. Weitere technische Fallstudien werden im Laufe der Zeit
veröffentlicht. Sie dienen als Referenz zum Entwerfen einer SharePoint Server-basierten
Umgebung für bestimmte Zwecke.
Verwenden Sie diese Fallstudien als Referenz beim Entwerfen der Architektur Ihrer
SharePoint Server-Lösungen, insbesondere wenn die Beschreibung der wichtigen
bereitstellungsspezifischen Unterscheidungsmerkmale mit den Anforderungen und
Zielvorgaben der zu erstellenden Lösung vergleichbar sind.
In diesen Dokumenten werden für jede dokumentierte Fallstudie die folgenden
Informationen beschrieben:
 Spezifikationen, wie z. B, Hardware, Farmtopologie und Konfiguration.

Arbeitsauslastung, einschließlich Benutzerbasis und Nutzungsmerkmalen.

Dataset, einschließlich Inhaltsgrößen, Inhaltsmerkmalen und Inhaltsverteilung.

Integrität und Leistung, einschließlich einer Reihe aufgezeichneter Indikatoren zur
Beschreibung der Zuverlässigkeit und Leistungsmerkmale der Farm.
Um weitere Informationen zu erhalten, laden Sie die entsprechenden Dokumente von der
http://technet.microsoft.com/de-de/library/cc261716(Office.14).aspx Webseite
Technische Fallstudien zu Leistung und Kapazität (http://technet.microsoft.com/dede/library/cc261716(Office.14).aspx) herunter.
Auswählen der Hardware
Die Auswahl der richtigen Spezifikationen für die Computer in der Farm ist ein wichtiger
Schritt, um die Zuverlässigkeit und Leistung der Bereitstellung sicherzustellen. Beachten
Sie unbedingt, dass Sie für Spitzenauslastungen und Spitzenzeiten planen sollten. Das
heißt, wenn die Farm unter durchschnittlichen Auslastungsbedingungen arbeitet, sollten
ausreichend Ressourcen verfügbar sein, um den größtmöglichen erwarteten Bedarf zu
bewältigen, während gleichzeitig die Zielvorgaben für Wartezeit und Durchsatz erfüllt
werden.
Die zentralen Hardwarefeatures für Kapazität und Leistung von Servern entsprechen vier
Hauptkategorien: Verarbeitungsleistung, Datenträgerleistung, Netzwerkkapazität und
Arbeitsspeicherkapazität eines Systems.
52
Darüber hinaus sollten Sie die Verwendung virtualisierter Computer berücksichtigen.
Eine SharePoint Server-Farm kann mithilfe virtueller Computer bereitgestellt werden.
Dies bietet zwar keine Leistungsvorteile, dafür aber Verwaltungsvorteile. Das
Virtualisieren von SQL Server-basierten Computern wird im Allgemeinen nicht
empfohlen, aber das Virtualisieren der Webserver- und Anwendungsserverebenen bietet
möglicherweise gewisse Vorteile. Weitere Informationen finden Sie unter
Virtualisierungsplanung (http://technet.microsoft.com/de-de/library/ff607968.aspx).
Richtlinien für die Hardwareauswahl
Auswählen von Prozessoren
SharePoint Server 2010 gibt es nur für 64-Bit-Prozessoren. Im Allgemeinen kann mit
mehr Prozessoren ein höherer Bedarf abgedeckt werden.
In SharePoint Server 2010 werden einzelne Webserver beim Hinzufügen von
Prozessorkernen skaliert (wir haben bis zu 24 Prozessorkerne getestet). Je mehr
Prozessorkerne der Server aufweist, desto mehr Auslastung kann bewältigt werden,
Alles andere ist identisch. Bei großen SharePoint Server-Bereitstellungen wird
empfohlen, entweder mehrere Webserver mit 4 Kernen (die virtualisiert werden können)
oder weniger und leistungsstärkere Webserver (mit 8/16/24 Kernen) zuzuordnen.
Die Prozessorkapazitätsanforderungen der Anwendungsserver hängen von der Rolle des
Servers und den darauf ausgeführten Diensten ab. Die SharePoint Server-Features
erfordern unterschiedlich viel Verarbeitungsleistung. Beispielsweise ist der SharePointSuchdienst in hohem Maß von der Verarbeitungsleistung des Anwendungsservers
abhängig. Weitere Informationen zu den Ressourcenanforderungen von SharePoint
Server-Features und -Diensten finden Sie unter Dienste und Features weiter oben in
diesem Dokument.
Die Prozessorkapazitätsanforderungen für SQL Server hängen auch von den
Dienstdatenbanken ab, die von einem SQL Server-basierten Computer gehostet werden.
Weitere Informationen zum typischen Verhalten und zu den Anforderungen der
verschiedenen Datenbanken finden Sie unter Speicher- und SQL ServerKapazitätsplanung und -Konfiguration (SharePoint Server 2010).
Auswählen des Arbeitsspeichers
Ihre Server benötigen in Abhängigkeit von der Funktion und der Rolle des Servers eine
unterschiedliche Menge an Arbeitsspeicher. Beispielsweise verarbeiten Server, auf
denen Suchdurchforstungskomponenten ausgeführt werden, Daten schneller, wenn sie
sehr viel Arbeitsspeicher aufweisen, da Dokumente zur Verarbeitung in den
Arbeitsspeicher eingelesen werden. Webserver, die viele Zwischenspeicherungsfeatures
von SharePoint Server 2010 nutzen, benötigen möglicherweise ebenfalls mehr
Arbeitsspeicher.
Im Allgemeinen sind die Arbeitsspeicheranforderungen für Webserver stark abhängig von
der in der Farm aktivierten Anzahl von Anwendungspools und von der Anzahl gleichzeitig
verarbeiteter Anforderungen. Bei den meisten SharePoint ServerProduktionsbereitstellungen wird empfohlen, auf jedem Webserver mindestens 8 GB
RAM zuzuordnen, wobei 16 GB für Server mit höherem Datenverkehr oder für
Bereitstellungen mit mehreren separat konfigurierten Anwendungspools empfohlen
werden.
Die Arbeitsspeicheranforderungen für Anwendungsserver variieren ebenfalls. Die
SharePoint Server-Features haben unterschiedliche Arbeitsspeicheranforderungen an
die Anwendungsebene. Bei den meisten SharePoint Server-Produktionsbereitstellungen
53
wird empfohlen, auf jedem Anwendungsserver mindestens 8 GB RAM zuzuordnen.
Anwendungsserver mit 16 GB, 32 GB und 64 GB RAM sind üblich, wenn viele
Anwendungsdienste auf demselben Server aktiviert sind, oder wenn Dienste, die in
hohem Maß auf Arbeitsspeicher angewiesen sind, wie z. B. die Dienste für ExcelBerechnungen oder der SharePoint Server-Suchdienst, aktiviert sind.
Die Arbeitsspeicheranforderungen von Datenbankservern sind direkt abhängig von der
Größe der Datenbanken. Weitere Informationen zum Auswählen von Arbeitsspeicher für
Ihre SQL Server-basierten Computer finden Sie unter Speicher- und SQL ServerKapazitätsplanung und -Konfiguration (SharePoint Server 2010).
Auswählen von Netzwerken
Neben dem Vorteil für Benutzer, wenn Clients über das Netzwerk schnellen Zugriff auf
Daten haben, benötigt eine verteilte Farm schnellen Zugriff für die Kommunikation
zwischen den Servern. Dies gilt insbesondere, wenn Sie Dienste auf mehrere Server
verteilen oder einige Dienste anderen Farmen zuteilen. In der Farm gibt es einen
erheblichen Datenverkehr auf der Webserverebene, der Anwendungsserverebene und
der Datenbankserverebene. Das Netzwerk kann in bestimmten Situationen schnell zu
einem Engpass werden, wie z. B. bei der Verwendung sehr großer Dateien oder sehr
hoher Auslastungen.
Für Webserver und Anwendungsserver sollten mindestens zwei
Netzwerkschnittstellenkarten (Network Interface Card, NIC) konfiguriert sein, nämlich
eine für den Datenverkehr von Endbenutzern, und eine zweite für die Kommunikation
zwischen den Servern. Die Netzwerklatenz zwischen Servern kann erhebliche
Auswirkungen auf die Leistung haben. Deshalb muss unbedingt eine Netzwerklatenz von
weniger als 1 Millisekunde zwischen dem Webserver und den SQL Server-basierten
Computern, von denen die Inhaltsdatenbanken gehostet werden, eingehalten werden.
Die SQL Server-basierten Computer, die die Dienstanwendungsdatenbanken hosten,
sollten auch möglichst nahe beim Anwendungsserver sein. Das Netzwerk zwischen
Farmservern sollte eine Bandbreite von mindestens 1 GBit/s aufweisen.
Auswählen von Datenträgern und Speicherplatz
Bei der Datenträgerverwaltung geht es nicht einfach darum, ausreichend Speicherplatz
für die Daten bereitzustellen. Sie müssen den Bedarf und das Wachstum kontinuierlich
bewerten und sicherstellen, dass das System durch die Speicherarchitektur nicht
ausgebremst wird. Sie sollten stets darauf achten, dass auf jedem Datenträger
mindestens 30 % mehr Speicherkapazität im Vergleich zum höchsten von Ihnen
geschätzten Datenanforderungswert vorhanden ist, um zukünftiges Wachstum zu
ermöglichen. Darüber hinaus spielt bei den meisten Produktionsumgebungen die
Datenträgergeschwindigkeit (IOps) eine entscheidende Rolle für ausreichend Durchsatz,
um die Speicheranforderungen der Server zu befriedigen. Sie müssen den Umfang des
Datenverkehrs (IOps) schätzen, der für die wichtigsten Datenbanken in der Bereitstellung
anfällt, und ausreichend Datenträger zur Bewältigung dieses Datenverkehrs zuordnen.
Weitere Informationen zum Auswählen von Datenträgern für Datenbankserver finden Sie
unter Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint
Server 2010).
Für die Webserver und Anwendungsserver gelten ebenfalls Speicheranforderungen. Bei
den meisten Produktionsumgebungen wird empfohlen, mindestens 200 GB Speicherplatz
für das Betriebssystem und temporäre Dateien sowie 150 GB Speicherplatz für
Protokolle zuzuordnen.
54
Schritt 3: Pilot-, Test- und Optimierungsphase
Die Test- und Optimierungsphase ist ein wichtiger Bestandteil einer effektiven
Kapazitätsverwaltung. Sie sollten neue Architekturen testen, bevor Sie sie in der
Produktionsumgebung bereitstellen. Außerdem sollten Sie Akzeptanztests in Verbindung
mit den folgenden bewährten Methoden für die Überwachung ausführen, um
sicherzustellen, dass die von Ihnen entworfenen Architekturen die Zielvorgaben
bezüglich Leistung und Kapazität erfüllen. Auf diese Weise können Sie potenzielle
Engpässe identifizieren und optimieren, bevor sie sich auf Benutzer in einer
Livebereitstellung negativ auswirken. Das Testen ist besonders wichtig, wenn Sie von
einer Microsoft Office SharePoint Server 2007-Umgebung upgraden und Änderungen an
der Architektur vornehmen möchten, oder wenn Sie die Benutzerauslastung der neuen
SharePoint Server-Features bestimmen. Dadurch können Sie nämlich sicherstellen, dass
die neue SharePoint Server-basierte Umgebung die Zielvorgaben bezüglich Leistung und
Kapazität erfüllt.
Nachdem Sie die Umgebung getestet haben, können Sie die Testergebnisse
analysieren, um zu bestimmen, welche Änderungen erforderlich sind, um die von Ihnen
in Schritt 1: Modellierung aufgestellten Zielvorgaben bezüglich Leistung und Kapazität zu
erfüllen.
Die folgenden empfohlenen untergeordneten Schritte sollten Sie für die Testumgebung
ausführen:
 Erstellen Sie die Testumgebung, in der die von Ihnen in Schritt 2: Entwurf entworfene
Ausgangsarchitektur imitiert wird.

Füllen Sie den Speicherplatz mit dem Dataset oder einem Teil des Datasets, das Sie
in Schritt 1: Modellierung definiert haben.

Belasten Sie das System mit einer synthetischen Auslastung, die die von Ihnen in
Schritt 1: Modellierung definierte Arbeitsauslastung darstellt.

Führen Sie Tests aus, analysieren Sie die Ergebnisse, und optimieren Sie die
Architektur.

Stellen Sie die optimierte Architektur im Rechenzentrum bereit, und führen Sie einen
Pilotversuch mit wenigen Benutzern durch.

Analysieren Sie die Ergebnisse des Pilotversuchs, identifizieren Sie potenzielle
Engpässe, und optimieren Sie die Architektur. Testen Sie bei Bedarf erneut.

Stellen Sie in der Produktionsumgebung bereit.
Testen
Das Testen ist ein wichtiger Faktor, um zu erreichen, dass von Ihrem Systementwurf die
anfallende Arbeitsauslastung und die Nutzungsmerkmale unterstützt werden.
Ausführliche Informationen zum Testen der Bereitstellung von SharePoint Server 2010
finden Sie unter Testen der Leistung für SharePoint Server 2010.
 Erstellen eines Testplans

Erstellen der Testumgebung

Erstellen von Tests und Tools
Bereitstellen der Pilotumgebung
Vor der Bereitstellung von SharePoint Server 2010 in einer Produktionsumgebung
müssen Sie unbedingt vorher eine Pilotumgebung bereitstellen und die Farm gründlich
testen, um sicherzustellen, dass sie die Zielvorgaben bezüglich Kapazität und Leistung
55
für die erwarteten Spitzenauslastungen erfüllt. Es wird empfohlen, speziell für große
Bereitstellungen die Pilotumgebung zuerst mit einer synthetischen Auslastung zu testen
und dann die Auslastung mit wenigen Livebenutzern und Liveinhalten zu testen. Die
Analyse einer Pilotumgebung mit wenigen Livebenutzern bietet die Möglichkeit, einige
von Ihnen aufgestellte Annahmen zu den Nutzungsmerkmalen und zum Inhaltswachstum
zu überprüfen, bevor Sie komplett auf die Produktionsumgebung umstellen.
Optimieren
Wenn die Zielvorgaben bezüglich Kapazität und Leistung durch Skalieren der
Farmhardware oder Änderungen an der Topologie nicht erfüllt werden können, müssen
Sie möglicherweise die Lösung überarbeiten. Wenn z. B. die ursprünglichen
Anforderungen eine einzelne Farm für die Zusammenarbeit, die Suche und soziale
Netzwerke vorsah, müssen Sie möglicherweise einige der Dienste wie z. B. den
Suchdienst einer dedizierten Farm für Dienste zuteilen oder die Arbeitsauslastung auf
mehr Farmen aufteilen. Eine Alternative ist das Bereitstellen einer dedizierten Farm für
soziale Netzwerke und eine weitere Farm für die Teamzusammenarbeit.
Schritt 4: Bereitstellung
Nachdem Sie die abschließende Testrunde ausgeführt und bestätigt haben, dass die
gewählte Architektur die von Ihnen Schritt 1: Modellierung aufgestellten Zielvorgaben
bezüglich Leistung und Kapazität erfüllt, können Sie die SharePoint Server 2010-basierte
Umgebung für die Produktion bereitstellen.
Die geeignete Einführungsstrategie hängt von der Umgebung und der Situation ab.
Während die Bereitstellung von SharePoint Server im Allgemeinen den Rahmen dieses
Dokuments sprengt, gibt es bestimmte vorgeschlagene Aktivitäten, die sich aus der
Kapazitätsplanungsübung ergeben. Es folgen einige Beispiele:
 Bereitstellen einer neuen SharePoint Server-Farm: Die Kapazitätsplanungsübung
sollte die Pläne für einen Entwurf und die Bereitstellung von SharePoint Server 2010
in die richtigen Bahnen gelenkt und bestätigt haben. In diesem Fall ist die Einführung
die erste umfassende Bereitstellung von SharePoint Server 2010. Dabei müssen die
Server und Dienste, die in den Kapazitätsplanungsübungen verwendet wurden, in die
Produktionsumgebung verschoben oder neu erstellt werden. Dies ist das einfachste
Szenario, da keine Upgrades oder Änderungen an einer vorhandenen Farm
erforderlich sind.

Upgraden einer Microsoft Office SharePoint Server 2007-Farm auf SharePoint
Server 2010: In der Kapazitätsplanungsübung sollte der Entwurf für eine Farm, die
die bestehenden Anforderungen erfüllen und für den höheren Bedarf und die höhere
Nutzung einer SharePoint Server 2010-Farm vertikal skaliert werden kann, überprüft
worden sein. Die Kapazitätsplanungsübung sollte Testmigrationen beinhaltet haben,
um zu überprüfen, wie lange der Upgradeprozess dauert, ob benutzerdefinierter
Code geändert oder ersetzt werden muss, ob Drittanbietertools aktualisiert werden
müssen usw. Am Ende der Kapazitätsplanung sollten Sie über einen geprüften
Entwurf verfügen und wissen, wie lange das Upgrade dauert, sowie einen Plan für
die optimale Abarbeitung des Upgradeprozesses haben – z. B. ein direktes Upgrade
oder das Migrieren von Inhaltsdatenbanken in eine neue Farm. Falls Sie ein direktes
Upgrade ausführen, haben Sie bei der Kapazitätsplanung möglicherweise
festgestellt, dass zusätzliche oder aktualisierte Hardware erforderlich ist und die
Downtime berücksichtigt werden muss. Das Resultat der Kapazitätsplanungsübung
56
sollte unter anderem eine Liste der erforderlichen Hardwareänderungen und ein
detaillierter Plan für die vorherige Bereitstellung der Hardwareänderungen in der
Farm sein. Wenn die während der Kapazitätsplanung überprüfte Hardwareplattform
vorhanden ist, können Sie das Upgraden auf SharePoint Server 2010 fortsetzen.

Verbessern der Leistung einer vorhandenen SharePoint Server 2010-Farm: Die
Kapazitätsplanungsübung sollte Ihnen beim Identifizieren der Engpässe in Ihrer
aktuellen Implementierung geholfen, Wege zum Reduzieren oder Eliminieren dieser
Engpässe aufgezeigt sowie eine optimierte Implementierung, die Ihre
Geschäftsanforderungen für SharePoint Server-Dienste erfüllt, ergeben haben. Es
gibt verschiedene Methoden zum Beheben von Leistungsproblemen, die von der
einfachen Neuzuordnung von Diensten auf vorhandener Hardware, dem Upgraden
vorhandener Hardware, bis hin zum Hinzufügen zusätzlicher Hardware und Dienste
reichen können. Die verschiedenen Methoden sollten während der
Kapazitätsplanungsübung getestet und geprüft werden. Anschließend sollte in
Abhängigkeit von den Ergebnissen dieser Tests ein Bereitstellungsplan aufgestellt
werden.
Schritt 5: Überwachung und Wartung
Zur Aufrechterhaltung der Systemleistung müssen Sie den Server überwachen, um
potenzielle Engpässe zu identifizieren. Vor einer effektiven Überwachung müssen Sie die
wichtigen Indikatoren kennen, von denen Sie auf ein Problem bei einer bestimmten
Farmkomponente hingewiesen werden, und diese Indikatoren zu deuten wissen. Falls
Sie feststellen, dass in der Farm die von Ihnen definierten Zielvorgaben nicht eingehalten
werden, können Sie die Farm anpassen, indem Sie Hardwareressourcen hinzufügen
oder entfernen, die Topologie ändern oder die Methode zum Speichern von Daten
ändern.
Eine Liste der Einstellungen, die Sie ändern können, um die Umgebung in einer früheren
Phase zu überwachen, finden Sie unter Überwachen und Verwalten von SharePoint
Server 2010. Anhand dieser Liste können Sie entscheiden, ob Änderungen erforderlich
sind. Beachten Sie, dass sich eine detailliertere Überwachung auf den
Speicherplatzbedarf der Verwendungsdatenbank auswirkt. Wenn die Umgebung stabil ist
und diese detaillierte Überwachung nicht mehr benötigt wird, können Sie die folgenden
Einstellungen auf die Standardwerte zurücksetzen.
Weitere Informationen zur Systemüberwachung und zur Problembehandlung mithilfe der
in die Benutzeroberfläche der SharePoint Server-Zentraladministration integrierten
Systemüberwachungstools finden Sie in den folgenden Artikeln:
Health Monitoring (SharePoint Server 2010)
Problembehandlung (http://technet.microsoft.com/enus/library/ee748639(office.14).aspx)
Siehe auch
Konzepte
Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht)
Testen der Leistung für SharePoint Server 2010
Überwachen und Verwalten von SharePoint Server 2010
57
Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server
2010)
Weitere Ressourcen
Health Monitoring (SharePoint Server 2010)
58
Testen der Leistung für SharePoint
Server 2010
In diesem Artikel wird beschrieben, wie die Leistung von Microsoft SharePoint Server
2010 getestet wird. Die Test- und Optimierungsphase stellt eine wesentliche
Komponente bei der effektiven Kapazitätsverwaltung dar. Vor der Bereitstellung in der
Produktion sollten Sie neue Architekturen testen und Akzeptanztests unter Einhaltung
der optimalen Methoden für die Überwachung durchführen,, um sicherzustellen, dass die
von Ihnen entworfenen Architekturen die gewünschten Leistungs- und Kapazitätsziele
erreichen. Sie können so potenzielle Engpässe erkennen und optimieren, ehe sich diese
auf Benutzer in der tatsächlichen Bereitstellung auswirken. Wenn Sie von einer Microsoft
Office SharePoint Server 2007-Umgebung aktualisieren und Änderungen an der
Architektur planen oder die Benutzerauslastung der neuen SharePoint Server 2010Features schätzen, sind Tests besonders wichtig, damit sichergestellt wird, dass die
neue SharePoint Server 2010-Umgebung die Leistungs- und Kapazitätsziele erreicht.
Nach dem Testen der Umgebung können Sie die Testergebnisse analysieren und die
Änderungen durchführen, die notwendig sind, um die in Schritt 1: Modellierung in
Kapazitätsplanung für SharePoint Server 2010 festgelegten Leistungs- und
Kapazitätsziele zu erreichen.
Es folgt eine Liste der empfohlenen Teilschritte, die für die Testumgebung ausgeführt
werden sollten:
 Erstellen Sie eine Testumgebung, die den anfänglichen Architekturentwurf aus
Schritt 2: Entwurf nachbildet.

Füllen Sie den Speicher mit dem Dataset oder Teilen des Datasets auf, den Sie in
Schritt 1: Modellierung bestimmt haben.

Wenden Sie die synthetische Auslastung auf das System an, die der Arbeitslast
entspricht, die Sie in Schritt 1: Modellierung bestimmt haben.

Führen Sie Tests aus, analysieren Sie die Ergebnisse und optimieren Sie Ihre
Architektur.

Stellen Sie die optimierte Architektur in Ihrem Datencenter bereit, und führen Sie eine
Pilotversion bei einer kleineren Gruppe von Benutzern ein.

Analysieren Sie die Pilotergebnisse, überprüfen Sie auf potenzielle Engpässe, und
optimieren Sie die Architektur. Führen Sie ggf. erneut Tests durch.
 Führen Sie die Bereitstellung in der Produktionsumgebung durch.
Vor dem Lesen dieses Artikels sollten Sie sich mit dem Inhalt von Kapazitätsverwaltung
und Größengestaltung für SharePoint Server 2010 (Übersicht) vertraut machen.
Inhalt dieses Artikels
 Erstellen eines Testplans

Erstellen der Testumgebung

Erstellen von Tests und Tools
59
Erstellen eines Testplans
Ihr Plan sollte Folgendes enthalten:
 Hardware, die für die Ausführung bei erwarteten Produktionsleistungszielen
konzipiert ist. Sie sollten die Leistung von Testsystemen immer konservativ messen.

Bei Verwendung von benutzerdefiniertem Code oder benutzerdefinierten
Komponenten ist es wichtig, diese Komponenten zuerst isoliert zu testen, um ihre
Leistung und Stabilität zu überprüfen. Wenn sie stabil sind, sollten Sie das System
mit den installierten Komponenten testen und die Leistung mit der Farm ohne die
installierten Komponenten vergleichen. Häufig stellen benutzerdefinierte
Komponenten die Hauptverursacher von Problemen im Zusammenhang mit der
Leistung und Zuverlässigkeit in Produktionssystemen dar.

Die Zielsetzung der Tests sollte bekannt sein. Sie sollten im Voraus wissen, welche
Ziele im Rahmen der Tests erreicht werden sollten. Soll die Leistung neuer
benutzerdefinierter Komponenten, die für die Farm entwickelt wurden, beurteilt
werden? Soll die Zeitdauer für das Durchforsten und Indizieren einer Reihe von
Inhalten erfasst werden? Soll festgestellt werden, wie viele Anforderungen pro
Sekunde von der Farm unterstützt werden können? Für einen Test kann es viele
verschiedene Zielsetzungen geben; bei der Ausarbeitung eines guten Testplans
sollten Sie als erstes die Ziele festlegen, die verfolgt werden sollen.

Wissen, wie das Testziel gemessen werden kann. Wenn Sie beispielsweise die
Durchsatzkapazität Ihrer Farm messen möchten, müssen Sie die Anforderungen pro
Sekunde (RPS) sowie die Seitenwartezeit erfassen. Wenn Sie die Suchleistung
messen möchten, müssen Sie die Durchforstungszeit und die
Dokumentindizierungsraten bestimmen. Wenn Sie sich über die Zielsetzung Ihrer
Tests im Klaren sind, ist es einfacher, die Schlüsselleistungsindikatoren zu
definieren, die im Rahmen der Tests bewertet werden müssen.
Erstellen der Testumgebung
Nachdem Sie die Ziele für die Tests festgelegt, die Messungen definiert und die
Kapazitätsanforderungen für Ihre Farm (aus den Schritten 1 und 2 dieses Prozesses)
bestimmt haben, besteht die nächste Aufgabe darin, die Testumgebung zu entwerfen
und zu erstellen. Der Aufwand, der mit dem Erstellen einer Testumgebung verbunden ist,
wird häufig unterschätzt. Die Testumgebung sollte die Produktionsumgebung so nah wie
möglich duplizieren. Zu den Features und Funktionen, die beim Entwurf der
Testumgebung berücksichtigt werden sollten, gehören die folgenden:
 Authentifizierung - Legen Sie fest, ob die Active Directory-Domänendienste (Active
Directory Domain Services, AD DS), die formularbasierte Authentifizierung (und
wenn ja, mit welchem Verzeichnis) und die anspruchsbasierte Authentifizierung usw.
in der Farm verwendet werden sollen. Unabhängig vom verwendeten Verzeichnis
werden wie viele Benutzer in der Umgebung benötigt und wie sollen diese erstellt
werden? Wie viele Gruppen oder Rollen werden benötigt und wie erstellen Sie sie
und füllen sie auf? Sie müssen auch sicherstellen, dass Sie den
Authentifizierungsdiensten ausreichend Ressourcen zugewiesen haben, damit keine
Engpässe während der Tests auftreten.
60

DNS - Bestimmen Sie, welche Namespaces bei Ihren Tests benötigt werden.
Identifizieren Sie die Server, die auf diese Anforderungen reagieren, und stellen Sie
sicher, dass in Ihrem Plan die IP-Adressen berücksichtigt werden, die von den
jeweiligen Servern verwendet werden sowie die DNS-Einträge, die erstellt werden
müssen.

Lastenausgleich - Vorausgesetzt, Sie verwenden mehr als einen Server (was
normalerweise der Fall ist, da Sie sonst nicht ausreichend Auslastung für die
Durchführung von Auslastungstests haben), benötigen Sie eine Art von
Lastenausgleichslösung. Dabei kann es sich um ein Hardwarelastenausgleichsmodul
oder um Softwarelastenausgleich wie den Windows-Netzwerklastenausgleich
(Network Load Balancing, NLB) handeln. Legen Sie fest, was verwendet werden soll,
und schreiben Sie alle Konfigurationsinformationen auf, die Sie für das schnelle und
effiziente Setup benötigen. Darüber hinaus sollten Sie bedenken, dass
Auslastungstest-Agents in der Regel die Adresse zur einer URL nur alle 30 Minuten
versuchen aufzulösen. Sie sollten also keine Datei für lokale Hosts oder RoundrobinDNS für den Lastenausgleich verwenden, da sich die Test-Agents voraussichtlich bei
jeder einzelnen Anforderung an denselben Server wenden, anstatt die Last auf alle
verfügbaren Server zu verteilen.

Testserver - Bei der Planung der Testumgebung müssen Sie nicht nur die Server für
die SharePoint Server 2010-Farm einplanen, sondern auch die für die Tests
erforderlichen Computer. Dazu gehören in der Regel mindestens 3 Server, ggf. sind
mehr erforderlich. Wenn Sie Visual Studio Team System (Team Test Load Agent) für
die Tests verwenden, wird ein Computer als Auslastungstestcontroller verwendet. Im
Allgemeinen werden mindestens 2 Computer als Auslastungstest-Agents eingesetzt.
Die Agents sind die Computer, die die Anweisungen vom Testcontroller darüber, was
getestet werden soll, entgegen nehmen und die Anforderungen an die SharePoint
Server 2010-Farm herausgeben. Die Testergebnisse werden auf einem SQL Serverbasierten Computer gespeichert. Sie sollten nicht denselben SQL Server-basierten
Computer verwenden, der für die SharePoint Server 2010-Farm verwendet wird, da
durch das Schreiben der Testdaten die verfügbaren SQL Server-Ressourcen für die
SharePoint Server 2010-Farm beeinträchtigt werden. Beim Ausführen der Tests
müssen auch die Testserver überwacht werden, genauso wie die Server in der
SharePoint Server 2010-Farm oder Domänencontroller usw., um sicherzustellen,
dass die Testergebnisse der Farm repräsentativ für die geplante Farm sind.
Gelegentlich kann es vorkommen, dass die Auslastungs-Agents oder -Controller
selbst einen Engpass darstellen. In diesem Fall entspricht der im Test angezeigte
Durchsatz nicht dem Maximum, das von der Farm unterstützt werden kann.

SQL Server - Folgen Sie in Ihrer Testumgebung den Hinweisen in den Abschnitten
"Konfigurieren von SQL Server" und "Überprüfen von Speicherleistung und zuverlässigkeit" im Artikel Speicher- und SQL Server-Kapazitätsplanung und Konfiguration (SharePoint Server 2010).

Überprüfung des Datasets - Bei der Auswahl der Inhalte, die Tests unterzogen
werden, sollten Sie bedenken, dass in einem optimalen Szenario Daten aus einem
vorhandenen Produktionssystem verwendet werden. So können Sie beispielsweise
Ihre Inhaltsdatenbanken aus einer Produktionsfarm sichern und in Ihrer
Testumgebung wiederherstellen. Fügen Sie dann die Datenbanken an, um die
Inhalte in die Farm zu übertragen. Immer wenn Sie Tests auf erfundene Daten oder
61
Beispieldaten anwenden, besteht das Risiko, dass die Ergebnisse aufgrund von
Unterschieden der gesammelten Inhalte verfälscht werden.
Wenn Sie Beispieldaten erstellen müssen, sollten Sie die folgenden Aspekte für die
Inhalte berücksichtigen:
 Alle Seiten sollten veröffentlicht sein; es sollten keine Inhalte ausgecheckt sein.

Die Navigation sollte realistisch sein; erstellen Sie nicht mehr als das, was Sie
normalerweise in einer Produktionsumgebung verwenden würden.

Sie sollten eine Vorstellung von den Anpassungen haben, die in der
Produktionswebsite verwendet werden. So sollten beispielsweise
Gestaltungsvorlagen, Stylesheets, JavaScript usw. so eng wie möglich in der
Produktionsumgebung implementiert sein.

Bestimmen Sie die Anzahl der erforderlichen SharePoint-Gruppen und/oder
Berechtigungsebenen und wie Benutzer diesen zugeordnet werden.

Stellen Sie fest, ob Profile importiert werden müssen, und wie lange dies ggf. dauert.

Finden Sie heraus, ob Benutzergruppen benötigt werden, wie diese ggf. erstellt und
aufgefüllt werden.

Legen Sie fest, ob zusätzliche Inhaltsquellen für Suchen erforderlich sind und was
Sie benötigen, um diese zu erstellen. Wenn Sie keine Inhaltsquellen erstellen
müssen, finden Sie heraus, ob Sie Netzwerkzugang haben, um sie zu durchforsten.

Stellen Sie fest, ob ausreichend Beispieldaten vorhanden sind - Dokumente, Listen,
Listenelemente usw. Erstellen Sie andernfalls einen Plan dafür, wie Sie diese Inhalte
erstellen.

Erstellen Sie einen Plan, damit ausreichend eindeutige Inhalte im Rahmen der Tests
durchsucht werden können. Häufig wird der Fehler gemacht, dass dasselbe
Dokument sogar hundert- oder tausendfach unter unterschiedlichen Namen in
verschiedene Dokumentbibliotheken hochgeladen wird. Dies kann sich auf die
Suchleistung auswirken, da der Suchprozessor beträchtliche Zeit mit der Erkennung
von Duplikaten verbringt, was in einer Produktionsumgebung mit tatsächlichen
Inhalten nicht notwendig wäre.
Erstellen von Tests und Tools
Nach dem Einrichten der Testumgebung ist es Zeit, die Tests zu erstellen und zu
optimieren, die für die Messung der Leistungskapazität der Farm verwendet werden. In
diesem Abschnitt wird gelegentlich spezifisch auf Visual Studio Team System (Team
Test Load Agent) verwiesen, doch können viele der Konzepte unabhängig vom
verwendeten Auslastungstool angewendet werden. Weitere Informationen zu Visual
Studio Team System finden Sie unter Visual Studio Team System im MSDN
(http://msdn.microsoft.com/de-de/library/fda2bad5.aspx" ).
Sie können auch das SharePoint Load Testing Kit (LTK) zusammen mit VSTS für die
Durchführung von Auslastungstests von SharePoint 2010-Farmen verwenden. Mit dem
Load Testing Kit wird ein Visual Studio Team System 2008-Auslastungstest auf der
Grundlage von Windows SharePoint Services 3.0- und Microsoft Office SharePoint
Server 2007-IIS-Protokollen generiert. Der VSTS-Auslastungstest kann verwendet
werden, um als Bestandteil der Kapazitätsplanungsübung oder des Stresstests vor dem
62
Upgrade eine synthetische Last für SharePoint Foundation 2010 oder SharePoint
Server 2010 zu generieren.
Das Load Testing Kit gehört zum Lieferumfang des Microsoft SharePoint 2010
Administration Toolkit Version 1.0, das im Microsoft Download Center
(http://www.microsoft.com/downloads/details.aspx?familyid=718447d8-0814-427a-81c3c9c3d84c456e&displaylang=de-de) verfügbar ist.
Ein wesentliches Kriterium für den Erfolg der Tests ist die Fähigkeit, eine realistische
Arbeitslast zu simulieren, indem Anforderungen für die unterschiedlichsten
Testwebsitedaten generiert werden, so als würden Benutzer auf die unterschiedlichsten
Inhalte einer SharePoint Server 2010-Farm im Produktionsbetrieb zugreifen. Dazu
müssen Sie die Tests in der Regel so konstruieren, dass sie datengesteuert sind. Anstatt
Hunderte individueller hardcodierter Tests zu erstellen, die auf eine bestimmte Seite
zugreifen, sollten Sie nur einige wenige Tests verwenden, die Datenquellen mit den
URLs für diese Elemente enthalten, um dynamisch auf diese Gruppe von Seiten
zuzugreifen.
In Visual Studio Team System (Team Test Load Agent) kann eine Datenquelle die
unterschiedlichsten Formate aufweisen, doch sind CSV-Dateien häufig am einfachsten
zu verwalten und zwischen Entwicklungs- und Testumgebungen zu transportieren. Wenn
CSV-Dateien mit solchen Inhalten erstellt werden, ist es eventuell notwendig,
benutzerdefinierte Tools zum Aufzählen der SharePoint Server 2010-basierten
Umgebung und Aufzeichnen der verschiedenen URLs zu erstellen.
Möglicherweise benötigen Sie Tools für Aufgaben wie die folgenden:
 Erstellen von Benutzern und Gruppen in Active Directory oder anderen
Authentifizierungsspeichern bei Verwendung der formularbasierten Authentifizierung

Aufzählen von URLs für Websites, Listen und Bibliotheken, Listenelemente,
Dokumente usw. sowie Übertragen in CSV-Dateien für Auslastungstests

Hochladen von Beispieldokumenten für verschiedene Dokumentbibliotheken und
Websites

Erstellen von Websitesammlungen, Webs, Listen, Bibliotheken, Ordner und
Listenelementen

Erstellen von "Meine Websites"

Erstellen von CSV-Dateien mit Benutzernamen und Kennwörtern für Testbenutzer.
Dies sind die Benutzerkonten, über die die Auslastungstests ausgeführt werden. Es
sollten mehrere Dateien vorhanden sein, sodass einige beispielsweise nur
Administratorbenutzer enthalten, einige Benutzer mit erhöhten Rechten (wie z. B.
Autor/Mitwirkender, Hierarchie-Manager usw.) und andere wiederum nur Leser usw.

Erstellen einer Liste von Beispielstichwörtern und -begriffen für die Suche

Auffüllen von SharePoint-Gruppen und Berechtigungsebenen mit Benutzern und
Active Directory-Gruppen (oder Rollen bei Verwendung der formularbasierten
Authentifizierung)
Beim Erstellen der Webtests sollten Sie u. a. die folgenden optimalen Methoden
beachten und implementieren:
 Aufzeichnen einfacher Webtests als Ausgangspunkt. Diese Tests enthalten
hartcodierte Werte für Parameter wie URLs und IDs usw. Ersetzen Sie diese
hartcodierten Werte durch Hyperlinks aus Ihren CSV-Dateien. Die Datenbindung
63
dieser Werte ist in Visual Studio Team System (Team Test Load Agent) äußerst
einfach.

Festlegen von Gültigkeitsregeln für die Tests. Wenn beispielsweise eine Seite
angefordert wird, erhalten Sie als Antwort auf einen Fehler oft die Seite error.aspx.
Aus Webtestperspektive handelt es sich einfach um eine weitere positive Antwort, da
in den Auslastungstestergebnissen der HTTP-Statuscode 200 (erfolgreich) angezeigt
wird. Offensichtlich ist jedoch ein Fehler aufgetreten, der anderweitig nachverfolgt
werden sollte. Durch eine oder mehrere Gültigkeitsregeln können Sie bestimmten,
als Antwort gesendeten Text abfangen, sodass die Überprüfung nicht erfolgreich
ausgeführt und die Anforderung als Fehler gekennzeichnet wird. In Visual Studio
Team System (Team Test Load Agent) kann als einfache Gültigkeitsregel
ResponseUrl bei der Überprüfung verwendet werden. Dabei wird ein Fehler
ausgegeben, wenn die nach Umleitungen gerenderte Seite nicht dieselbe
Antwortseite ist, die im Test aufgezeichnet wurde. Sie können auch eine FindTextRegel hinzufügen, bei der ein Fehler aufgezeichnet wird, wenn der Ausdruck "Zugriff
verweigert" beispielsweise in der Antwort gefunden wird.

Verwenden von mehreren Benutzern in verschiedenen Rollen für Tests.
Verschiedene Verhalten, wie z. B. das Zwischenspeichern der Ausgabe wird
abhängig von den Rechten des jeweiligen Benutzers unterschiedlich gehandhabt. So
erhalten beispielsweise ein Websitesammlungsadministrator oder ein authentifizierter
Benutzer mit Genehmigungs- oder Dokumenterstellungsrechten keine
zwischengespeicherten Ergebnisse, da es ihnen stets möglich sein sollte, auf die
aktuellste Version von Inhalten zuzugreifen. Anonyme Benutzer hingegen erhalten
zwischengespeicherte Inhalte. Sie müssen sicherstellen, dass es sich bei den
Testbenutzern um eine Kombination dieser Rollen handelt, die in etwa der
Zusammenstellung der Benutzer in der Produktionsumgebung entspricht. Wenn
beispielsweise in einer Produktionsumgebung nur zwei oder drei
Websitesammlungsadministratoren vorkommen, sollten Sie keine Tests erstellen, bei
denen 10% der Seitenanforderungen von Benutzerkonten stammen, die
Websitesammlungsadministratoren für die Testinhalte sind.

Die Analyse abhängiger Anforderungen ist ein Attribut von Visual Studio Team
System (Team Test Load Agent), das bestimmt, ob der Test-Agent versuchen sollte,
nur die Seite oder die Seite einschließlich aller zugehörigen Anforderungen, die Teil
der Seite sind, abzurufen, wie z. B. Bilder, Stylesheets und Skripts usw. Beim Testen
der Auslastung werden diese Elemente in der Regel aus verschiedenen Gründen
ignoriert:

Nach dem erstmaligen Zugreifen eines Benutzers auf eine Website werden diese
Elemente häufig vom lokalen Browser zwischengespeichert

Die Elemente stammen in einer SharePoint Server 2010-basierten Umgebung in
der Regel nicht von SQL Server. Wenn der BLOB-Cache aktiviert ist, werden sie
vielmehr von den Webservern bereitgestellt, sodass keine SQL Server-Last
generiert wird.
Wenn der Prozentsatz der Benutzer Ihrer Website, die diese erstmalig besuchen hoch
ist, oder wenn Sie die Browserzwischenspeicherung deaktiviert haben oder aus einem
sonstigen Grund nicht vorhaben, den BLOB-Cache zu verwenden, kann es sinnvoll sein,
die Analyse abhängiger Anforderungen in Ihren Tests zu aktivieren. Für die meisten
Implementierungen stellt dies jedoch tatsächlich eine Ausnahme und nicht die Regel dar.
64
Durch Aktivieren der Funktion können die vom Testcontroller gemeldeten RPS-Zahlen
deutlich ansteigen. Diese Anforderungen werden so schnell bereitgestellt, dass Sie
möglicherweise zu dem trügerischen Schluss gelangen, dass mehr Kapazität in der Farm
verfügbar ist als tatsächlich vorhanden.
 Denken Sie daran, auch die Aktivität von Clientanwendungen zu modellieren. Auch
durch Clientanwendungen, wie Microsoft Word, PowerPoint, Excel und Outlook,
werden Anforderungen für SharePoint Server 2010-Farmen generiert. Durch Senden
der Serveranforderungen, wie z. B. beim Abrufen von RSS-Feeds, Abrufen
thematischer Informationen, Anfordern von Details zur Website- und Listenstruktur
und Synchronisieren von Daten usw., steigt die Auslastung innerhalb der Umgebung.
Diese Anforderungstypen sollten berücksichtigt und modelliert werden, wenn diese
Clients Teil Ihrer Implementierung sind.

In den meisten Fällen sollte ein Webtest nur eine einzelne Anforderung enthalten.
Die Optimierung und Problembehandlung der Testumgebung und einzelner
Anforderungen ist einfacher, wenn der Test nur eine einzelne Anforderung enthält.
Webtests müssen in der Regel mehrere Anforderungen enthalten, wenn der
simulierte Vorgang auf mehreren Anforderungen zusammen gesetzt ist. Wenn Sie
beispielsweise diese Reihe von Aktionen testen möchten, benötigen Sie einen aus
mehreren Schritten bestehenden Test: Auschecken eines Dokuments, Bearbeiten
des Dokuments, Einchecken und Veröffentlichen. Ebenfalls erforderlich ist es,
zwischen den Schritten den Zustand zu erhalten. So sollte beispielsweise dasselbe
Benutzerkonto für das Auschecken, Bearbeiten und Einchecken verwendet werden.
Solche Vorgänge aus mehreren Schritten, die erfordern, dass zwischen den
einzelnen Schritten der Zustand erhalten bleibt, werden am besten mit mehreren
Anforderungen in einem einzelnen Webtest durchgeführt.

Führen Sie jeden Webtest einzeln aus. Stellen Sie sicher, dass jeder Test erfolgreich
beendet werden kann, ehe er innerhalb eines umfangreicheren Auslastungstests
ausgeführt wird. Überprüfen Sie, dass alle Namen für Webanwendungen aufgelöst
werden und die im Test verwendeten Benutzerkonten über ausreichende Rechte für
die Ausführung des Tests verfügen.
Webtests umfassen die Anforderungen nach einzelnen Seiten, das Hochladen von
Dokumenten und das Anzeigen von Listenelementen usw. Diese werden in
Auslastungstests alle kombiniert. Ein Auslastungstest ist eine Kombination der
verschiedenen Webtests, die ausgeführt werden sollen. Jedem Webtest wird ein
Prozentsatz der Zeit für die Ausführung eingeräumt. Wenn Sie beispielsweise feststellen,
dass 10% der Anforderungen in einer Produktionsfarm Suchabfragen sind, konfigurieren
Sie einen Abfragewebtest für den Auslastungstest, der 10% der Zeit ausgeführt wird. In
Visual Studio Team System (Team Test Load Agent) befassen sich Auslastungstests
auch mit der Konfiguration von Faktoren wie der Browsermischung, der
Netzwerkmischung, Auslastungsmustern und Ausführungseinstellungen.
Für Auslastungstests sollten zusätzlich die folgenden optimalen Methoden beachtet und
implementiert werden:
 Verwenden eines angemessenen Lese-/Schreibverhältnisses bei den Tests. Eine
überhöhte Anzahl von Schreibvorgängen kann sich deutlich auf den
Gesamtdurchsatz eines Tests auswirken. Selbst Farmen für die Zusammenarbeit
tendieren zu Lese-/Schreibverhältnissen mit deutlich mehr Lese- als
Schreibvorgängen. Weitere Informationen finden Sie unter Technische Fallstudien zu
65
Leistung und Kapazität (http://technet.microsoft.com/dede/library/cc261716(Office.14).aspx).

Berücksichtigen der Auswirkungen anderer ressourcenintensiver Vorgänge und
Festlegen, ob diese während des Auslastungstests ausgeführt werden sollen. So
werden beispielsweise Vorgänge wie Sichern und Wiederherstellen im Allgemeinen
nicht während eines Auslastungstests ausgeführt. Eine vollständige Durchforstung
sollte in der Regel nicht während eines Auslastungstests ausgeführt werden,
während eine inkrementelle Durchforstung nicht ungewöhnlich ist. Überlegen Sie
sich, wie der Zeitplan für diese Aufgaben in der Produktion aussieht - werden sie zu
Spitzenauslastungszeiten ausgeführt? Wenn dies nicht der Fall ist, sollten sie
vermutlich von den Auslastungstests ausgenommen werden, wenn Sie versuchen,
die maximale Auslastung bei gleichbleibendem Zustand zu ermitteln, die zu
Spitzenzeiten unterstützt werden kann.

Keine Verwendung von Reaktionszeiten. Reaktionszeiten sind ein Feature von Visual
Studio Team System (Team Test Load Agent), das die Simulierung des Zeitraums
ermöglicht, den ein Benutzer zwischen dem Klicken auf einer Seite verstreichen
lässt. So lädt beispielsweise ein typischer Benutzer möglicherweise eine Seite,
verbringt drei Minuten mit Lesen und klickt dann auf eine Verknüpfung auf der Seite,
um eine andere Site zu besuchen. Die korrekte Modellierung in einer Testumgebung
ist beinahe unmöglich und bringt den Testergebnissen keinen zusätzlichen Wert. Die
Modellierung ist deshalb so schwierig, da die meisten Organisationen keine
Möglichkeit haben, verschiedene Benutzer und den Zeitraum zwischen Klicks in
verschiedenen Typen von SharePoint-Websites zu überwachen (wie z. B.
Veröffentlichungssites im Gegensatz zu Websites für die Zusammenarbeit usw.).
Darüber hinaus stellt die Modellierung keinen tatsächlichen Mehrwert dar, da ein
Benutzer zwar zwischen Seitenanforderungen pausiert, SharePoint Server 2010basierte Server jedoch nicht. Sie erhalten nur einen konstanten Strom von
Anforderungen mit Spitzen und Senken im Laufe der Zeit, verbringen jedoch keine
Zeit im Leerlauf, so wie Benutzer zwischen dem Klicken auf Hyperlinks auf einer
Seite pausieren.

Kenntnisse über den Unterschied zwischen Benutzern und Anforderungen. Visual
Studio Team System (Team Test Load Agent) weist ein Auslastungsmuster auf, bei
dem Sie zur Eingabe der Anzahl der simulierenden Benutzer aufgefordert werden.
Dies hat nichts mit den Anwendungsbenutzern zu tun, vielmehr geht es nur um die
Anzahl der Threads, die von den Auslastungstest-Agents zum Generieren von
Anforderungen verwendet werden. Ein häufiger Fehler besteht darin, anzunehmen,
dass bei einer Bereitstellung für 5.000 Benutzer die Zahl 5.000 in Visual Studio Team
System (Team Test Load Agent) verwendet werden sollte - was nicht der Fall ist.
Dies ist einer der zahlreichen Gründe, weshalb bei der Schätzung der Anforderungen
für die Kapazitätsplanung die Verwendungsanforderungen auf der Anzahl der
Anforderungen pro Sekunde und nicht der Anzahl von Benutzern basieren sollten.
Bei einem Visual Studio Team System (Team Test Load Agent)-Auslastungstest
werden Sie feststellen, dass häufig Hunderte von Anforderungen pro Sekunde bei
nur 50 bis 75 Auslastungstest-"Benutzern" generiert werden.

Verwenden eines konstanten Auslastungsmusters für zuverlässige und
reproduzierbare Testergebnisse. In Visual Studio Team System (Team Test Load
Agent) haben Sie die Option, die Auslastung für eine konstante Anzahl von
Benutzern (Threads, wie im vorherigen Punkt erläutert), ein intensiviertes
66
Benutzerauslastungsmuster oder einen zielbasierten Verwendungstest zu simulieren.
Ein intensiviertes Auslastungsmuster bedeutet, dass Sie mit einer niedrigeren Anzahl
von Benutzern beginnen und alle paar Minuten zusätzliche Benutzer hinzufügen. Bei
einem zielbasierten Verwendungstest wird ein Schwellenwert für einen bestimmten
Diagnoseindikator, wie die CPU-Auslastung, eingerichtet und Versuche getestet, die
Auslastung so zu halten, dass der Leistungsindikator sich zwischen den definierten
Mindest- und Höchstschwellenwerten bewegt. Wenn Sie jedoch nur den maximalen
Durchsatz der SharePoint Server 2010-Farm während Spitzenauslastungszeiten
ermitteln möchten, ist es sinnvoller und genauer, nur ein konstantes
Auslastungsmuster auszuwählen. Damit können Sie die auf das System anwendbare
Auslastung einfacher bestimmen, ehe die Schwellenwerte, die in einer fehlerfreien
Farm eingehalten werden sollten, regelmäßig überschritten werden.
Bei der Ausführung eines Auslastungstests sollten Sie bedenken, dass Daten in der
Datenbank geändert werden. Unabhängig davon, ob Dokumente hochgeladen,
Listenelemente bearbeitet oder nur Aktivitäten in der Verwendungsdatenbank
aufgezeichnet werden, werden Daten auf SQL Server geschrieben. Um konsistente und
seriöse Testergebnisse aus den einzelnen Auslastungstests zu erhalten, sollten Sie vor
der Ausführung des ersten Auslastungstests eine Sicherung erstellen. Nach jedem
einzelnen Auslastungstest sollte der Inhalt mithilfe der Sicherung so wiederhergestellt
werden, wie er zu Beginn des Tests vorlag.
Siehe auch
Konzepte
Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht)
Kapazitätsplanung für SharePoint Server 2010
Überwachen und Verwalten von SharePoint Server 2010
Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server
2010)
Weitere Ressourcen
Health Monitoring (SharePoint Server 2010)
67
Überwachen und Verwalten von
SharePoint Server 2010
Dieser Artikel enthält Informationen zur Überwachung sowie zu Leistungsindikatoren für
Microsoft SharePoint Server 2010-Farmen. Für die Verwaltung der Systemleistung von
SharePoint Server 2010 müssen Sie den Server überwachen, um mögliche Engpässe
erkennen zu können. Eine leistungsfähige Überwachung ist erst dann möglich, wenn Sie
die wichtigsten Indikatoren kennen, die Ihnen Aufschluss darüber geben, ob bestimmte
Teile der Farm Aufmerksamkeit erfordern, und wissen, wie diese Indikatoren ausgewertet
werden müssen. Wenn Sie feststellen, dass sich Ihre Farm außerhalb der von Ihnen
definierten Ziele bewegt, können Sie durch Hinzufügen oder Entfernen von
Hardwareressourcen, Ändern der Topologie oder Ändern der Speicherung von Daten
entsprechende Anpassungen der Farm vornehmen.
Die Informationen in diesem Abschnitt sollen Administratoren bei der manuellen
Konfiguration von Leistungsindikatoren und anderen Einstellungen unterstützen. Weitere
Informationen zur Systemüberwachung mithilfe der Systemüberwachungstools auf der
Oberfläche der SharePoint-Zentraladministration finden Sie in den folgenden Artikeln:
 Health Monitoring (SharePoint Server 2010)
 Solving Problems and Troubleshooting (SharePoint Server 2010)
Vor dem Lesen dieses Artikels sollten Sie sich mit dem Inhalt von Kapazitätsverwaltung
und Größengestaltung für SharePoint Server 2010 (Übersicht) vertraut machen.
Inhalt dieses Artikels
 Konfigurieren der Überwachung

Beseitigen von Engpässen
Konfigurieren der Überwachung
Es folgt eine Liste der Einstellungen, die Sie zur Überwachung Ihrer Umgebung in den
Anfangsphasen ändern können, sodass Sie rechtzeitig erkennen, ob Änderungen
erforderlich sind. Die Ausweitung Ihrer Überwachungsfunktionen wirkt sich auf den
Speicherplatz aus, der von der Verwendungsdatenbank beansprucht wird. Wenn ein
stabiler Zustand der Umgebung erreicht ist und eine detaillierte Überwachung nicht mehr
erforderlich ist, sollten Sie die nachfolgenden Einstellungen eventuell wieder auf ihre
Standardwerte zurücksetzen.
Einstellung
Wert
Hinweise
Ereignisprotokoll-Flutschutz
Deaktiviert
Der Standardwert ist Aktiviert.
Die Einstellung kann
deaktiviert werden, um so
viele Überwachungsdaten wie
möglich zu sammeln. Bei
68
Einstellung
Wert
Hinweise
Normalbetrieb sollte die
Einstellung aktiviert sein.
Zeitplan für den
Zeitgeberauftrag
Import der Microsoft
SharePoint FoundationVerwendungsdaten
5 Minuten
Der Standardwert beträgt
30 Minuten. Durch Senken
dieser Einstellung werden die
Daten häufiger in die
Verwendungsdatenbank
importiert, was vor allem für
die Problembehandlung
hilfreich ist. Bei Normalbetrieb
sollte die Einstellung
30 Minuten lauten.
Aktiviert
Der Standardwert lautet
Deaktiviert mit Ausnahme des
Anbieters
"Suchintegritätsüberwachung Ablaufverfolgung der
Ereignisse". Diese Anbieter
sammeln Integritätsdaten für
verschiedene Features und
Komponenten. Bei
Normalbetrieb sollten Sie die
Standardeinstellung
zurücksetzen.
Zeitplanintervalle "job1 Minute
diagnostics-performancecounter-wfe-provider" und "jobdiagnostics-performancecounter-sql-provider" festlegen
Der Standardwert beträgt
5 Minuten. Durch Senken
dieser Einstellung werden die
Daten häufiger abgerufen, was
vor allem für die
Problembehandlung hilfreich
ist. Bei Normalbetrieb sollte
die Einstellung 5 Minuten
lauten.
Diagnoseanbieter
Alle Diagnoseanbieter
aktivieren
Verschiedenes
Aktiviert
Stapelablaufverfolgung für
Inhaltsanforderungen aktivieren
Der Standardwert ist
Deaktiviert. Durch Aktivieren
dieser Einstellung ist die
Diagnose von
Inhaltsanforderungsfehlern
mithilfe der
Prozessstapelablaufverfolgung
69
Einstellung
Wert
Hinweise
möglich. Bei Normalbetrieb
sollte die Einstellung
deaktiviert sein.
Entwicklerdashboard aktivieren Aktiviert
Der Standardwert ist
Deaktiviert. Das Aktivieren
dieser Einstellung ermöglicht
die Diagnose von langsamen
Seiten oder sonstigen
Problemen mithilfe des
Entwicklerdashboards. Bei
Normalbetrieb und sobald
keine Problembehandlung
mehr erforderlich ist, sollte die
Einstellung deaktiviert werden.
Verwendungsdatenerfassung
Inhaltsimportverwendung
Inhaltsexportverwendung
Seitenanforderungen
Featureverwendung
Suchvorgangsverwendung
Websiteinventarverwendung
Zeitgeberaufträge
Aktiviert
Das Aktivieren der
Protokollierung dieser
Leistungsindikatoren
ermöglicht es Ihnen, mehr
Verwendungsdaten innerhalb
der Umgebung zu sammeln
und die Muster im
Datenverkehr in der
Umgebung besser zu
verstehen.
Bewertungsverwendung
Leistungsindikatoren
Wenn Sie die Verwendungsdatenbank einsetzen, können Sie die Leistungsindikatoren
hinzufügen, um die Leistung der Farm besser in der Verwendungsdatenbank zu
überwachen und zu beurteilen, indem diese automatisch in bestimmten Intervallen
(Standardeinstellung beträgt 30 Minuten) protokolliert werden. So können Sie die
Verwendungsdatenbank nach diesen Indikatoren abfragen und die Ergebnisse über
längere Zeit in einem Diagramm darstellen. Es folgt ein Beispiel für die Verwendung des
PowerShell-Cmdlets Add-SPDiagnosticsPerformanceCounter, um den Indikator
Prozessorzeit (%) zur Verwendungsdatenbank hinzuzufügen. Es genügt die Ausführung
auf einem Webserver:
Code
kopieren
Add-SPDiagnosticsPerformanceCounter -Category "Processor" -Counter "%
Processor Time" -Instance "_Total" -WebFrontEnd
70
Es existiert eine Reihe von allgemeinen Leistungsindikatoren, die Sie für jedes
Serversystem überwachen sollten. Diese Leistungsindikatoren werden in der folgenden
Tabelle beschrieben.
Leistungsindikator
Beschreibung
Prozessor
Sie sollten die Prozessorleistung
überwachen, um sicherzustellen, dass die
gesamte Prozessorauslastung nicht
konstant hoch (über 80 Prozent) bleibt. Dies
ist ein Hinweis, dass das System nicht in
der Lage ist, plötzliche
Aktivitätssteigerungen zu verarbeiten. Im
Normalbetrieb sollte darauf geachtet
werden, dass im Falle des Ausfalls einer
Komponente kein Dominoeffekt eintritt und
die verbleibenden Komponenten in
Mitleidenschaft gezogen werden. Wenn Sie
beispielsweise über drei Webserver
verfügen, sollten Sie sicherstellen, dass die
durchschnittliche CPU-Auslastung aller
Server bei unter 60% liegt, damit bei einem
Ausfall eines Servers ausreichend
verbleibende Kapazität der anderen beiden
Server vorhanden ist, um die zusätzliche
Last zu übernehmen.
Netzwerkschnittstelle
Überwachen Sie die Geschwindigkeit, mit
der Daten mittels Netzwerkkarte gesendet
und empfangen werden. Diese sollte
weniger als 50 Prozent der
Netzwerkkapazität betragen.
Datenträger und Cache
Es existiert eine Vielzahl von logischen
Datenträgeroptionen, die regelmäßig
überwacht werden sollten. Der verfügbare
Speicherplatz ist in jeder Kapazitätsstudie
wichtig, doch sollte auch der Zeitraum
überwacht werden, in der der Datenträger
im Leerlauf ist. Abhängig von den Typen
von Anwendungen oder Diensten, die Sie
auf den Servern ausführen, sollten Sie auch
die Lese und Schreibzeiten des
Datenträgers überwachen. Verlängerte
Warteschlangenzeiten für Lese- oder
Schreibfunktionen wirken sich auf die
Leistung aus. Der Cache hat deutliche
Auswirkungen auf Lese- und
Schreibvorgänge. Überwachen Sie auf
71
Leistungsindikator
Beschreibung
vermehrte Cachefehler.
Arbeitsspeicher und Auslagerungsdatei
Überwachen Sie die Menge des
physikalischen Speichers, der für die
Speicherreservierung zur Verfügung steht.
Unzureichender Speicher hat die exzessive
Nutzung der Auslagerungsdatei und eine
Zunahme der Seitenfehler pro Sekunde zur
Folge.
Systemindikatoren
Die folgende Tabelle enthält Informationen zu Systemobjekten und -indikatoren, die Sie
der Gruppe von in der Verwendungsdatenbank überwachten Indikatoren mithilfe von
SPDiagnosticPerformanceCounter auf einem Webserver hinzufügen können.
Objekte und Indikatoren
Beschreibung
Prozessor
Prozessorzeit (%)
Gibt die Prozessorauslastung über einen
Zeitraum an. Wenn der Wert dauerhaft zu
hoch ist, kann sich dies negativ auf die
Leistung auswirken. Bei
Multiprozessorsystemen sollte der
Gesamtwert berechnet werden. Sie können
auch die Nutzung der einzelnen
Prozessoren messen, um eine
ausgeglichene Leistung zwischen den
Prozessorkernen sicherzustellen.
Datenträger
Durchschnittl. Warteschlangenlänge des
Datenträgers
Gibt die durchschnittliche Anzahl von Leseund Schreibanforderungen in der
Warteschlage für den gewählten
Datenträger während des Abfragezeitraums
an. Eine verlängerte
Datenträgerwarteschlange ist
unproblematisch, so lange keine Probleme
bei den Datenträgerlese- und
schreibvorgängen vorkommen und das
System kontinuierlich ohne Erweiterung der
Warteschlange ausgeführt wird.
Durchschnittl. Warteschlangenlänge der
Datenträger-Lesevorgänge
Die durchschnittliche Anzahl der
Leseanforderungen in der Warteschlange.
Durchschnittl. Warteschlangenlänge der
Die durchschnittliche Anzahl der
72
Objekte und Indikatoren
Beschreibung
Datenträger-Schreibvorgänge
Schreibanforderungen in der
Warteschlange.
Lesevorgänge/s
Die Anzahl der Lesevorgänge auf dem
Datenträger pro Sekunde.
Schreibvorgänge/s
Die Anzahl der Schreibvorgänge auf dem
Datenträger pro Sekunde.
Arbeitsspeicher
- Verfügbare MB
Gibt die Menge des physikalischen
Speichers an, der für die
Speicherreservierung zur Verfügung steht.
Unzureichender Speicher hat die exzessive
Nutzung der Auslagerungsdatei und eine
Zunahme der Seitenfehler pro Sekunde zur
Folge.
- Cachefehler/s
Dieser Indikator gibt die Rate an, mit der
Fehler auftreten, wenn eine Seite im
Dateisystemcache nicht gefunden wird und
aus dem Arbeitsspeicher oder vom
Datenträger abgerufen werden muss.
Die effektive Verwendung des Caches für
Lese- und Schreibvorgänge kann sich
deutlich auf die Serverleistung auswirken.
Überwachen Sie, ob vermehrt Cachefehler
auftreten; ein Hinweis darauf ist eine
Reduzierung von Schnelle
Lesevorgänge/s (async.) oder von
Vorauslesevorgänge/s.
- Seiten/s
Dieser Leistungsindikator zeigt die
Geschwindigkeit an, mit der Seiten vom
Datenträger gelesen oder auf den
Datenträger geschrieben werden, um
Hardwareseitenfehler zu beheben. Ein
Anstieg ist ein Hinweis auf systemweite
Leistungsprobleme.
Auslagerungsdatei
- % belegt und Maximale Belegung %
In der Serverauslagerungsdatei werden
"virtuelle" Speicheradressen auf dem
Datenträger gespeichert. Seitenfehler treten
auf, wenn ein Prozess angehalten wird und
warten muss, während erforderliche
"virtuelle" Ressourcen vom Datenträger in
den Arbeitsspeicher abgerufen werden. Bei
73
Objekte und Indikatoren
Beschreibung
unzureichendem physikalischen Speicher
treten diese häufiger auf.
NIC
- Gesamtanzahl Bytes/s
Dies ist die Geschwindigkeit, mit der Daten
mittels Netzwerkkarte gesendet und
empfangen werden. Wenn dieser Wert bei
mehr als 40-50 Prozent der
Netzwerkkapazität liegt, sollten Sie nach der
Ursache suchen. Zur Optimierung Ihrer
Suche überwachen Sie Empfangene
Bytes/s und Bytes gesendet/s.
Prozess
- Arbeitssatz
Dieser Indikator gibt die aktuelle Größe (in
Bytes) des Arbeitssatzes für einen
bestimmten Prozess an. Dieser
Arbeitsspeicher ist für den Prozess
vorbehalten, selbst wenn er nicht verwendet
wird.
- Prozessorzeit (%)
Dieser Indikator gibt die Prozessorzeit in
Prozent an, die von einem bestimmten
Prozess verwendet wird.
Threadanzahl (_Gesamt)
Die aktuelle Anzahl von Threads.
ASP.NET
Anforderungen gesamt
Die Gesamtanzahl von Anforderungen seit
dem Start des Diensts.
Anforderungen in Warteschlange
In Microsoft SharePoint Foundation 2010
werden die Grundbausteine für HTMLSeiten bereitgestellt, die im
Benutzerbrowser über HTTP gerendert
werden. Dieser Indikator gibt die Anzahl der
Anforderungen an, die auf die Verarbeitung
warten.
Wartezeit der Anforderung
Die Anzahl von Millisekunden, die die letzte
Anforderung in der Warteschlange auf die
Verarbeitung warten musste. Mit steigender
Anzahl von Warteereignissen sinkt die
Leistung beim Rendern von Seiten für
Benutzer.
Zurückgewiesene Anforderungen
Die Gesamtanzahl der Anforderungen, die
aufgrund von unzureichenden
Serverressourcen nicht ausgeführt wurden.
74
Objekte und Indikatoren
Beschreibung
Dieser Indikator stellt die Anzahl der
Anforderungen dar, die den Statuscode 503
erhielten, als Hinweis, dass der Server
überlastet ist.
Ausgeführte Anforderungen (_Gesamt)
Die Anzahl der derzeit ausgeführten
Anforderungen.
Anforderungen/s (_Gesamt)
Die Anzahl der pro Sekunde ausgeführten
Anforderungen. Dieser Indikator gibt den
aktuellen Durchsatz der Anwendung an. Bei
Dauerauslastung sollte der Wert innerhalb
eines bestimmten Bereichs bleiben, wobei
andere Serveraktionen (wie z. B. Garbage
Collection, Cachebereinigungsthread,
externe Servertools usw.) gesperrt sind.
.NET CLR-Speicher
Auflistungsanzahl der Generation 0
Zeigt die Anzahl der Garbage Collections
von Objekten der Generation 0 (also der
neuesten, zuletzt zugeordneten Objekte)
seit dem Starten der Anwendung an. Beim
Verhältnis von "Anzahl der Generation 0:
Anzahl der Generation 1: Anzahl der
Generation 2" sollte die Auflistungsanzahl
der Generation 2 die Auflistungsanzahl der
Generation 0 nicht deutlich übersteigen,
optimal um den Faktor 2.
Auflistungsanzahl der Generation 1
Gibt die Anzahl der Garbage Collections
von Objekten der Generation 1 seit dem
Starten der Anwendung an.
Auflistungsanzahl der Generation 2
Gibt die Anzahl der Garbage Collections
von Objekten der Generation 2 seit dem
Starten der Anwendung an. Der Indikator
wird am Ende einer Garbage Collection der
Generation 2 (auch vollständige Garbage
Collection genannt) erhöht.
GC-Zeitdauer in Prozent
Zeigt den Prozentsatz der Zeit für die
Durchführung einer Garbage Collection an,
die seit dem letzten Garbage CollectionZyklus verstrichen ist. Dieser Indikator gibt
in der Regel die Aufgaben des Garbage
Collectors zur Sammlung und
Komprimierung von Speicher im Auftrag der
Anwendung an. Dieser Indikator wird erst
am Ende einer Garbage Collection
75
Objekte und Indikatoren
Beschreibung
aktualisiert. Es handelt sich hierbei nicht um
einen Durchschnitt; der Wert spiegelt den
letzten gemessenen Wert wider. Bei
Normalbetrieb sollte der Wert unter 5%
liegen.
SQL Server-Leistungsindikatoren
Die folgende Tabelle enthält Informationen zu SQL Server-Objekten und Leistungsindikatoren.
Objekte und Indikatoren
Beschreibung
Allgemeine Statistik
Dieses Objekt stellt Leistungsindikatoren für
die Überwachung der allgemeinen
serverweiten Aktivität zur Verfügung, z. B.
die Anzahl gleichzeitiger Verbindungen und
die Anzahl der Benutzer, die pro Sekunde
von Computern mit einer Instanz von
SQL Server eine Verbindung herstellen oder
trennen.
Benutzerverbindungen
Dieser Leistungsindikator zeigt den Umfang
der Benutzerverbindungen auf dem
Computer mit SQL Server an. Wenn dieser
Wert um mehr als 500 % ausgehend von
Ihrer Baseline ansteigt, kann sich dies in
Leistungseinbußen niederschlagen.
Datenbanken
Dieses Objekt stellt Leistungsindikatoren für
die Überwachung von
Massenkopiervorgängen, des Sicherungsund Wiederherstellungsdurchsatzes und
von Transaktionsprotokollaktivitäten zur
Verfügung. Überwachen Sie Transaktionen
und das Transaktionsprotokoll, um den
Umfang der Benutzeraktivitäten in der
Datenbank zu bestimmen und festzustellen,
in welchem Umfang das
Transaktionsprotokoll aufgefüllt wird. Der
Umfang der Benutzeraktivitäten kann die
Leistung der Datenbank bestimmen und
sich auf die Protokollgröße, Sperren und die
Replikation auswirken. Die Überwachung
von Protokollaktivitäten auf niedriger Ebene
zur Messung der Benutzeraktivität und der
Ressourcennutzung kann Ihnen helfen,
76
Objekte und Indikatoren
Beschreibung
Leistungsengpässe zu identifizieren.
Transaktionen/s
Dieser Leistungsindikator zeigt den Umfang
der Transaktionen für eine bestimmte
Datenbank oder die gesamte SQL ServerInstanz pro Sekunde an. Dieser Wert hilft
Ihnen beim Erstellen einer Baseline und bei
der Problembehandlung.
Sperren
Dieses Objekt stellt Informationen zu
SQL Server-Sperren für einzelne
Ressourcentypen zur Verfügung.
Anzahl der Deadlocks/s
Dieser Leistungsindikator zeigt die Anzahl
der Deadlocks pro Sekunde auf dem
Computer mit SQL Server an. Dieser Wert
sollte normalerweise 0 sein.
Durchschnittliche Wartezeit (ms)
Dieser Leistungsindikator zeigt die
durchschnittliche Länge der Wartezeit für
jede Sperranforderung an, die nicht sofort
erfüllt werden konnte.
Sperrenwartezeit (ms)
Dieser Leistungsindikator zeigt die
Wartezeit für Sperren in der vergangenen
Sekunde an.
Sperrenwartezeit/s
Sperrenwartevorgänge/Sekunde Dieser
Leistungsindikator zeigt die Anzahl der
Sperren pro Sekunde an, die nicht sofort
erfüllt werden konnten, sodass auf
Ressourcen gewartet werden musste.
Latches
Dieses Objekt stellt Leistungsindikatoren für
die Überwachung interner SQL ServerRessourcensperren, so genannter Latches,
zur Verfügung. Die Überwachung von
Latches zum Bestimmen der
Benutzeraktivität und der
Ressourcennutzung kann Ihnen helfen,
Leistungsengpässe zu identifizieren.
Durchschnittliche Latchwartezeit (ms)
Dieser Leistungsindikator zeigt die
durchschnittliche Wartezeit für
Latchanforderungen an, die nicht sofort
erfüllt werden konnten.
Latchwartezeiten/s
Dieser Leistungsindikator zeigt die Anzahl
der Latchanforderungen an, die nicht sofort
erfüllt werden konnten.
77
Objekte und Indikatoren
Beschreibung
SQL-Statistik
Dieses Objekt stellt Leistungsindikatoren für
die Überwachung der Kompilierung und des
Typs der Anforderungen zur Verfügung, die
an eine Instanz von SQL Server gesendet
werden. Die Überwachung der Anzahl der
Abfragekompilierungen und
Neukompilierungen sowie der Anzahl der
Batches, die von einer Instanz von
SQL Server empfangen wurden, liefert
Ihnen einen Hinweis darauf, wie schnell
Benutzerabfragen von SQL Server
verarbeitet werden und wie effektiv der
Abfrageoptimierer die Abfragen verarbeitet.
SQL-Kompilierungen/s
Dieser Leistungsindikator zeigt an, wie oft
der Pfad für den Kompilierungscode pro
Sekunde eingegeben wurde.
SQL-Neukompilierungen/s
Dieser Leistungsindikator zeigt die Anzahl
der erneuten Anweisungskompilierungen
pro Sekunde an.
Plancache
Dieses Objekt stellt Leistungsindikatoren zur
Verfügung, mit denen Sie überwachen
können, wie SQL Server den
Arbeitsspeicher zum Speichern von
Objekten wie gespeicherten Prozeduren,
Ad-hoc-Anweisungen und vorbereiteten
Transact-SQL-Anweisungen sowie Triggern
verwendet.
Cachetrefferquote
Dieser Leistungsindikator zeigt das
Verhältnis zwischen Cachetreffern und
Plansuchvorgängen an.
Puffercache
Dieses Objekt stellt Leistungsindikatoren zur
Verfügung, mit denen Sie überwachen
können, wie SQL Server den
Arbeitsspeicher zum Speichern von
Datenseiten, internen Datenstrukturen und
des Prozedurcaches verwendet. Es stellt
darüber hinaus Leistungsindikatoren bereit,
um die physikalische E/A zu überwachen,
während SQL Server Datenbankseiten liest
und schreibt.
Puffercache-Trefferquote
Dieser Leistungsindikator zeigt den
Prozentsatz der Seiten an, die im
Puffercache gefunden wurden, ohne dass
ein Lesevorgang vom Datenträger
78
Objekte und Indikatoren
Beschreibung
erforderlich war. Die Quote entspricht der
Gesamtzahl von Cachetreffern dividiert
durch die Gesamtzahl der
Cachesuchvorgänge seit dem Starten einer
SQL Server-Instanz.
Beseitigen von Engpässen
Systemengpässe stellen Konflikte dar, die durch unzureichende Ressourcen bei der
Ausführung von Transaktionsanforderungen von Benutzern entstehen. Sie können im
Zusammenhang mit physikalischer Hardware, der Betriebsumgebung oder
Anwendungen stehen. Häufig sind ineffizienter benutzerdefinierter Code oder
unzureichende Drittanbieterlösungen die Ursache für den Engpass und ihre Optimierung
könnte zu besseren Ergebnissen führen als Hardware hinzuzufügen. Eine weitere
häufige Ursache für Engpässe ist die fehlerhafte Konfiguration der Farm oder eine
ineffiziente Lösungsimplementierung, bei der Daten so strukturiert sind, dass zusätzliche
Ressourcen notwendig werden. Für einen Systemadministrator ist die konstante
Überwachung der Leistung zur Verwaltung von Engpässen unumgänglich. Wird ein
Leistungsproblem erkannt, muss die beste Lösung zur Beseitigung des Engpasses
erwägt werden. Die Leistungsindikatoren und sonstigen Anwendungen zur Überwachung
der Leistung, wie z. B. System Center Operations Manager (SCOM), sind die wichtigsten
Tools bei der Nachverfolgung und Analyse von Problemen und helfen Ihnen dabei,
Lösungen zu entwickeln.
Beseitigung physikalischer Engpässe
Physikalische Engpässe entstehen aufgrund von Konflikten von Prozessoren,
Datenträgern, Speichern und Netzwerk: es stehen zu viele Anforderungen im
Wettbewerb nach zu wenigen physikalischen Ressourcen. Die innerhalb des Themas
"Leistungsüberwachung" beschriebenen Objekte und Leistungsindikatoren geben
Aufschluss über die Ursache des Leistungsproblems, wie z. B. Hardwareprozessor oder
ASP.NET. Für die Beseitigung des Engpasses ist es notwendig, dass Sie das Problem
identifizieren und dann Änderungen vornehmen, die das Leistungsproblem entschärfen.
Probleme treten selten überraschend auf; wenn Sie die Leistung regelmäßig mithilfe
Ihres Tools zur Leistungsüberwachung oder eines ausgefeilten Systems wie SCOM
überwachen, ist in der Regel ist eine schrittweise Verschlechterung der Leistung
feststellbar. Bei beiden Optionen können Sie in unterschiedlichem Umfang Lösungen in
Form von Empfehlungen oder Skriptbefehlen in eine Warnung einbauen.
Möglicherweise müssen Sie Engpässe durch Änderungen an Hardware oder
Systemkonfigurationen beseitigen, sofern Sie festgestellt haben, dass diese nicht mit
einer fehlerhaften Konfiguration, ineffizientem benutzerdefinierten Code, unzureichenden
Drittanbieterlösungen oder ineffizienter Lösungsimplementierung zusammenhängen. In
den folgenden Tabellen werden Problemschwellenwerte und mögliche Lösungsoptionen
aufgeführt. Bei einigen Optionen werden Hardwareupgrades oder -änderungen
empfohlen.
79
Objekte und Indikatoren
Problem
Lösungsoptionen
Über 75-85%
Upgrade des Prozessors
Anzahl Prozessoren erhöhen
Prozessor
Prozessor - Prozessorzeit
(%)
Zusätzliche(n) Server
hinzufügen
Datenträger
Durchschnittl.
Warteschlangenlänge des
Datenträgers
Schrittweise Zunahme,
System nicht stabil und
Rückstau der
Warteschlange
Anzahl oder Geschwindigkeit
von Datenträger erhöhen
Arraykonfiguration zu Stripe
ändern
Einige Daten auf alternativen
Server verschieben
Leerlaufzeit (%)
Höher als 90%
Anzahl Datenträger erhöhen
Daten auf alternativen
Datenträger oder Server
verschieben
Freier Speicherplatz (%(
Weniger als 30%
Anzahl Datenträger erhöhen
Daten auf alternativen
Datenträger oder Server
verschieben
Arbeitsspeicher
Verfügbare MB
Weniger als 2 GB auf
einem Webserver.
Arbeitsspeicher hinzufügen.
Hinweis:
Der für SQL Server verfügbare
Arbeitsspeicher ist
entwurfsbedingt niedrig und
weist nicht immer auf ein
Problem hin.
Cachefehler/s
Mehr als 1
Arbeitsspeicher hinzufügen
Cachegeschwindigkeit oder größe ggf. erhöhen
Daten auf alternativen
Datenträger oder Server
verschieben
80
Objekte und Indikatoren
Problem
Lösungsoptionen
Seiten/s
Mehr als 10
Arbeitsspeicher hinzufügen
Auslagerungsdatei
% belegt und Maximale
Belegung %
In der
Arbeitsspeicher hinzufügen
Serverauslagerungsdatei
werden "virtuelle"
Speicheradressen auf dem
Datenträger gespeichert.
Seitenfehler treten auf,
wenn ein Prozess
angehalten wird und warten
muss, während
erforderliche "virtuelle"
Ressourcen vom
Datenträger in den
Arbeitsspeicher abgerufen
werden. Bei
unzureichendem
physikalischen Speicher
treten diese häufiger auf.
NIC
Gesamtanzahl Bytes/s
Über 40-50% der
Netzwerkkapazität. Dies ist
die Geschwindigkeit, mit
der Daten mittels
Netzwerkkarte gesendet
und empfangen werden.
Empfangene Bytes/s und
Bytes gesendet/s weiter
überwachen
Geschwindigkeit der
Netzwerkkarte erneut
überprüfen
Anzahl, Größe und Verwendung
von Speicherpuffern überprüfen
Prozess
Arbeitssatz
Über 80% des
Gesamtspeicherplatzes
Arbeitsspeicher hinzufügen
Prozessorzeit (%)
Über 75-85%
Anzahl Prozessoren erhöhen
Arbeitslast auf zusätzliche
Server umverteilen
ASP.NET
AnwendungspoolWiederverwendungen
Achten Sie darauf, keine
Mehrere täglich, was
Einstellungen zu
zeitweise auftretende
Langsamkeit zur Folge hat implementieren, durch die der
Anwendungspool im Verlauf des
Tages unnötig wiederverwendet
wird.
81
Objekte und Indikatoren
Problem
Lösungsoptionen
Anforderungen in
Warteschlange
Hunderte oder Tausende
von Anforderungen in
Warteschlange.
Zusätzliche Webserver
implementieren
Der Standard-Maximalwert für
diesen Indikator beträgt 5.000;
Sie können diese Einstellung in
der Datei Machine.config
ändern.
Wartezeit der Anforderung Mit steigender Anzahl von Zusätzliche Webserver
Warteereignissen sinkt die implementieren
Leistung beim Rendern von
Seiten für Benutzer.
Zurückgewiesene
Anforderungen
Mehr als 0
Zusätzliche Webserver
implementieren
Siehe auch
Konzepte
Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht)
Testen der Leistung für SharePoint Server 2010
Kapazitätsplanung für SharePoint Server 2010
Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server
2010)
Weitere Ressourcen
Health Monitoring (SharePoint Server 2010)
82
SharePoint Server 2010Kapazitätsverwaltung:
Softwarebeschränkungen und -grenzen
In diesem Dokument werden Softwarebeschränkungen und -grenzen von Microsoft
SharePoint Server 2010 beschrieben. Hierzu gehören folgende:
 Beschränkungen: Statische Grenzwerte, die entwurfsbedingt nicht überschritten
werden können

Schwellenwerte: Konfigurierbare Grenzwerte, die für bestimmte Anforderungen
überschritten werden können

Unterstützte Grenzwerte: Konfigurierbare Grenzwerte, die standardmäßig auf einen
getesteten Wert festgelegt wurden
Hinweis:
Die in diesem Dokument enthaltenen Informationen zur Kapazitätsplanung bieten Ihnen
Hilfestellung bei Ihrem Planungsprozess. Sie stützen sich auf Tests, die bei Microsoft mit
realen Ressourcen durchgeführt wurden. Ihre Ergebnisse können jedoch in Abhängigkeit
von den verwendeten Anlagen und den Features und Funktionen variieren, die Sie für
Ihre Websites implementieren möchten.
Inhalt dieses Artikels:
 Übersicht über Beschränkungen und Grenzen


Beschränkungen, Schwellenwerte und unterstützte Grenzwerte

Festlegen von Grenzwerten
Beschränkungen und Grenzen

Grenzen nach Hierarchie

Webanwendungsgrenzen

Webserver- und Anwendungsservergrenzen

Grenzen für Inhaltsdatenbanken

Grenzen für Websitesammlungen

Listen- und Bibliotheksgrenzen

Spaltengrenzen

Seitengrenzen

Grenzen nach Feature

Suchgrenzen

Grenzen für den Benutzerprofildienst
83

Inhaltsbereitstellungsgrenzen

Bloggrenzen

Grenzen für Business Connectivity Services

Workflowgrenzen

Grenzen für Terminologiespeicher (Datenbank) für verwaltete Metadaten

Grenzen für Visio Services

Grenzen für PerformancePoint Services

Grenzen für Word Automation Services

Grenzen für SharePoint Workspace

Grenzen für OneNote

Grenzen für Office-Webanwendungsdienste

Grenzen für Project Server
Übersicht über Beschränkungen und Grenzen
Dieser Artikel enthält Informationen zur getesteten Leistung und den Kapazitätsgrenzen
von SharePoint Server 2010 und stellt Richtlinien für das Verhältnis zwischen diesen
Grenzen und einer akzeptablen Leistung bereit. Bestimmen Sie anhand der
Informationen in diesem Artikel, ob die von Ihnen geplante Bereitstellung innerhalb der
akzeptablen Leistungs- und Kapazitätsgrenzen liegt, um die Grenzwerte in Ihrer
Umgebung entsprechend zu konfigurieren.
Die Testergebnisse und Richtlinien in diesem Artikel gelten für eine einzelne SharePoint
Server 2010-Farm. Möglicherweise werden die Kapazitätsgrenzen der in den Tabellen im
Abschnitt Beschränkungen und Grenzen weiter unten in diesem Thema aufgeführten
Objekte durch das Hinzufügen von Servern zur Installation nicht erhöht. Allerdings führt
das Hinzufügen von Servercomputern zu einer Steigerung des Durchsatzes einer
Serverfarm, was bei vielen Objekten erforderlich sein kann, um eine akzeptable Leistung
zu erzielen. In einigen Fällen werden bei einem hohen Objektaufkommen in einer Lösung
möglicherweise mehr Server in der Farm benötigt.
Es gibt zahlreiche Faktoren, die sich auf die Leistung in einer bestimmten Umgebung
auswirken können, und jeder dieser Faktoren kann sich auf die Leistung eines anderen
Bereichs auswirken. Einige der in diesem Artikel aufgeführten Testergebnisse und
Empfehlungen beziehen sich möglicherweise auf Features oder Benutzervorgänge, die
es in Ihrer Umgebung nicht gibt, und gelten damit nicht für Ihre Lösung. Präzise
Ergebnisse für Ihre eigene Umgebung erhalten Sie nur durch sorgfältiges Testen.
Beschränkungen, Schwellenwerte und unterstützte Grenzwerte
In SharePoint Server 2010 gibt es bestimmte Grenzwerte, die entwurfsbedingt sind und
nicht überschritten werden können, während es sich bei anderen Grenzwerten um
Standardwerte handelt, die von einem Farmadministrator geändert werden können.
Außerdem gibt es bestimmte Grenzen, die nicht durch einen konfigurierbaren Wert
dargestellt werden, beispielsweise die Anzahl von Websitesammlungen pro
Webanwendung.
 Bei Beschränkungen handelt es sich um absolute Grenzwerte, die entwurfsbedingt
nicht überschritten werden können. Es ist wichtig, diese Grenzen zu kennen, um
84
sicherzustellen, dass Sie beim Entwerfen Ihrer Farm nicht von falschen
Voraussetzungen ausgehen.
Ein Beispiel für eine Beschränkung ist die Beschränkung der Dokumentgröße auf
2 GB. Sie können SharePoint Server nicht so konfigurieren, dass Dokumente mit
einer Größe von über 2 GB gespeichert werden. Es handelt sich hierbei um einen
integrierten absoluten Wert, der entwurfsbedingt nicht überschritten werden kann.
 Bei Schwellenwerten handelt es sich um Standardwerte, die nur durch Ändern dieses
Werts überschritten werden können. Unter bestimmten Bedingungen können
Schwellenwerte überschritten werden, um Abweichungen im Farmentwurf Rechnung
zu tragen, doch ist es wichtig zu wissen, dass sich dies auf die Leistung der Farm
und auch auf den geltenden Wert anderer Grenzen auswirken kann.
Der Standardwert bestimmter Schwellenwerte kann nur bis zu einem absoluten
Maximalwert überschritten werden. Ein gutes Beispiel hierfür ist die Beschränkung
der Dokumentgröße. Standardmäßig ist der Schwellenwert für die Dokumentgröße
auf 50 MB festgelegt, er kann jedoch geändert werden, sodass er die maximale
Beschränkung von 2 GB unterstützt.
 Unterstützte Grenzwerte definieren den getesteten Wert für einen bestimmten
Parameter. Die Standardwerte für diese Grenzen wurden durch Tests festgelegt und
stellen die bekannten Einschränkungen des Produkts dar. Ein Überschreiten dieser
unterstützten Grenzwerte kann zu unerwarteten Ergebnissen, signifikanten
Leistungseinbußen und anderen negativen Folgen führen.
Bei einigen unterstützten Grenzwerten handelt es sich um konfigurierbare Parameter,
die standardmäßig auf den empfohlenen Wert festgelegt sind, während andere
unterstützte Grenzwerte sich auf Parameter beziehen, die nicht durch einen
konfigurierbaren Wert dargestellt werden.
Ein Beispiel für einen unterstützten Grenzwert ist die Anzahl von Websitesammlungen
pro Webanwendung. Der unterstützte Grenzwert liegt bei 250.000. Dabei handelt es sich
um die größte Anzahl von Websitesammlungen pro Webanwendung, die beim Testen die
Leistungsbenchmarks erfüllt hat.
Es ist wichtig zu wissen, dass viele der in diesem Dokument angegebenen Grenzwerte
einen Punkt in einer Kurve darstellen, die eine wachsende Ressourcenlast und einen
damit einhergehenden Leistungsverlust bei Zunahme des Werts beschreibt. Deshalb
kann das Überschreiten bestimmter Grenzwerte, wie beispielsweise der Anzahl von
Websitesammlungen pro Webanwendung, nur zu einem anteiligen Verlust der
Farmleistung führen. In den meisten Fällen empfiehlt es sich jedoch, am oder zumindest
nah am festgelegten Grenzwert zu operieren, da akzeptable Leistungs- und
Zuverlässigkeitsziele sich am ehesten erreichen lassen, wenn der Entwurf einer Farm ein
ausgewogenes Verhältnis zwischen Grenzwerten bietet.
Richtlinien für Schwellenwerte und unterstützte Grenzwerte werden auf Leistungsbasis
bestimmt. Mit anderen Worten, Sie können die Standardwerte für diese Grenzen
überschreiten, doch kann es dann zu einer Beeinträchtigung der Farmleistung und zu
Auswirkungen auf andere geltende Grenzwerte kommen, wenn Sie den Grenzwert
heraufsetzen. Viele Grenzen in SharePoint Server können geändert werden; es ist
jedoch wichtig zu wissen, wie sich die Änderung einer bestimmten Grenze auf andere
Teile der Farm auswirkt.
Festlegen von Grenzwerten
85
In SharePoint Server 2010 werden Schwellenwerte und unterstützte Grenzwerte durch
Tests festgelegt sowie durch Beobachten des Farmverhaltens bei zunehmenden Lasten
bis zu dem Punkt, an dem Farmdienste und -operationen ihren effektiven
Betriebsgrenzwert erreichen. Einige Farmdienste und -komponenten können eine höhere
Last unterstützen als andere, sodass Sie in einigen Fällen einen Grenzwert zuweisen
müssen, der auf einem Durchschnitt aus mehreren Faktoren beruht.
So weisen beispielsweise Beobachtungen des Farmverhaltens unter Last beim
Hinzufügen von Websitesammlungen darauf hin, dass bestimmte Funktionen eine
inakzeptabel lange Wartezeit aufweisen, während andere Funktionen weiterhin innerhalb
akzeptabler Parameter arbeiten. Aus diesem Grund ist der Maximalwert, der der Anzahl
von Websitesammlungen zugewiesen wird, nicht absolut, sondern beruht auf einer
vorhergesehenen Reihe von Nutzungsmerkmalen, bei der die allgemeine Farmleistung
beim festgelegten Grenzwert unter den meisten Umständen akzeptabel ist.
Wenn also einige Dienste mit Parametern arbeiten, die über denen liegen, die zum
Testen der Grenzwerte verwendet werden, werden die effektiven Maximalgrenzwerte
anderer Dienste verringert. Deshalb sind ein striktes Kapazitätsmanagement sowie
Skalierungstests für bestimmte Bereitstellungen erforderlich, um effektive Grenzwerte für
die jeweilige Umgebung aufzustellen.
Hinweis: Dieses Dokument enthält keine Beschreibung der Hardware, die für die
Überprüfung der hier genannten Grenzwerte verwendet wurde, da die Grenzwerte aus
verschiedenen Farmen und Umgebungen stammen. Eine Beschreibung der bei den
Tests verwendeten Farmen finden Sie unter Ergebnisse der Leistungs- und
Kapazitätstests und Empfehlungen (SharePoint Server 2010) und Performance and
capacity technical case studies (SharePoint Server 2010) (in englischer Sprache).
Der Equalizer-Vergleich zur Veranschaulichung
Sie können sich Schwellenwerte und unterstützte Grenzwerte wie die Schieberegler
eines Grafikequalizers vorstellen, bei dem jeder Grenzwert eine bestimmte Frequenz
darstellt. Das Erhöhen eines Grenzwerts kann somit dazu führen, dass der effektive Wert
eines oder mehrerer anderer Grenzwerte sinkt.
Stellen Sie sich vor, dass ein Schieberegler die maximale Anzahl von Dokumenten pro
Bibliothek darstellt, einen unterstützten Grenzwert mit einem getesteten Maximalwert von
etwa 30 Millionen. Dieser Wert ist jedoch von einem anderen Regler abhängig, der die
maximale Größe von Dokumenten in der Farm darstellt, einen Schwellenwert mit dem
Standardwert von 50 MB.
Wenn Sie die Maximalgröße von Dokumenten in 1 GB ändern, um Videos oder andere
große Objekte einzubeziehen, wird die Anzahl der Dokumente, die von der Bibliothek
effizient für Benutzer bereitgestellt werden können, entsprechend reduziert.
Beispielsweise kann die Hardwarekonfiguration und Topologie einer bestimmten Farm
eine Million Dokumente bis zu 50 MB unterstützen. Die gleiche Farm mit der gleichen
Anzahl von Dokumenten kann jedoch nicht dieselben Wartezeit- und Durchsatzziele
erreichen, wenn die Farm eine höhere durchschnittliche Dokumentgröße bedient, weil
der Grenzwert für die Dateigröße auf 1 GB festgelegt wurde.
Das Ausmaß der Reduzierung der maximalen Anzahl von Dokumenten in diesem
Beispiel ist schwer vorauszusagen und ist abhängig von der Anzahl großer Dateien in der
Bibliothek, dem in ihnen enthaltenen Datenvolumen, den Nutzungsmerkmalen der Farm
sowie der Verfügbarkeit von Hardwareressourcen.
86
Beschränkungen und Grenzen
In diesem Abschnitt sind die Objekte aufgeführt, die zu einer Lösung gehören können,
sowie Richtlinien für eine akzeptable Leistung der einzelnen Objekte. Eine akzeptable
Leistung bedeutet, dass das System gemäß Test diese Anzahl an Objekten unterstützen
kann, dass die Anzahl jedoch nicht überschritten werden kann, ohne dass es zu
Leistungsbeeinträchtigungen oder einer Reduzierung zugehöriger Grenzwerte kommt.
Objekte werden sowohl nach Größe als auch nach Feature aufgelistet. Grenzwerte
werden zusammen mit Hinweisen zur Beschreibung der Bedingungen bereitgestellt,
unter denen der Grenzwert erreicht wird, sowie mit Links zu ggf. verfügbaren
zusätzlichen Informationen.
Überprüfen Sie mithilfe der Richtlinien in diesem Artikel Ihre allgemeinen Lösungspläne.
Wenn Ihre Lösungspläne die empfohlenen Richtlinien für ein oder mehrere Objekte
überschreiten, führen Sie eine oder mehrere der folgenden Aktionen durch:
 Überprüfen Sie die Lösung, um sicherzustellen, dass in anderen Bereichen ein
Ausgleich stattfindet.

Kennzeichnen Sie diese Bereiche, um sie beim Erstellen Ihrer Bereitstellung zu
testen und zu überwachen.

Entwerfen Sie die Lösung neu, oder teilen Sie sie auf, um sicherzustellen, dass keine
Kapazitätsrichtlinien überschritten werden.
Grenzen nach Hierarchie
Dieser Abschnitt enthält Grenzen, die nach der logischen Hierarchie einer SharePoint
Server 2010-Farm geordnet sind.
Webanwendungsgrenzen
Die folgende Tabelle enthält die empfohlenen Richtlinien für Webanwendungen.
Grenze
Maximalwert
Grenztyp
Hinweise
Inhaltsdatenbank
300 pro
Webanwendung
Unterstützt
Bei 300 Inhaltsdatenbanken
pro Webanwendung werden
Endbenutzeroperationen
wie das Öffnen der Website
oder Websitesammlungen
nicht beeinträchtigt. Zu
Leistungsbeeinträchtigungen
kommt es jedoch bei
Verwaltungsoperationen wie
dem Erstellen einer neuen
Websitesammlung. Sie
sollten Windows PowerShell
zum Verwalten der
Webanwendung verwenden,
wenn eine große Anzahl von
Inhaltsdatenbanken vorliegt,
da die
Verwaltungsschnittstelle
langsam und die Navigation
87
Grenze
Maximalwert
Grenztyp
Hinweise
erschwert wird.
Zone
5 pro Webanwendung Beschränkung Die Anzahl der für eine
Farm definierten Zonen ist
auf 5 hartcodiert. Zu den
Zonen gehören "Standard",
"Intranet", "Extranet",
"Internet" und
"Benutzerdefiniert".
Verwalteter Pfad
20 pro
Webanwendung
Größe des
Lösungscaches
300 MB pro
Webanwendung
Unterstützt
Verwaltete Pfade werden
auf dem Webserver
zwischengespeichert, und
CPU-Ressourcen werden
verwendet, um eingehende
Anforderungen anhand der
Liste verwalteter Pfade zu
verarbeiten.
Das Überschreiten von 20
verwalteten Pfaden pro
Webanwendung bedeutet
für den Webserver mit jeder
Anforderung mehr Last.
Wenn Sie beabsichtigen, 20
verwaltete Pfade in einer
bestimmten Webanwendung
zu überschreiten, sollten Sie
testen, ob die
entsprechende
Systemleistung akzeptabel
ist.
Schwellenwert Der Lösungscache
ermöglicht es dem InfoPathFormulardienst, Lösungen
im Cache aufzubewahren,
um das Abrufen der
Lösungen zu beschleunigen.
Wird die Cachegröße
überschritten, werden
Lösungen vom Datenträger
abgerufen, was zu
langsameren Antwortzeiten
führen kann. Sie können die
Größe des Lösungscaches
mithilfe des Windows
PowerShell-Cmdlets SetSPInfoPathFormsService
konfigurieren. Weitere
88
Grenze
Maximalwert
Grenztyp
Hinweise
Informationen finden Sie
unter SetSPInfoPathFormsService.
Webserver- und Anwendungsservergrenzen
In der folgenden Tabelle sind die empfohlenen Richtlinien für Webserver in der Farm
aufgelistet.
Grenze
Maximalwert
Grenztyp
Hinweise
Anwendungspools
10 pro Webserver
Unterstützt Die maximale Anzahl wird
durch Hardwareressourcen
bestimmt.
Diese Grenze hängt
weitgehend von folgenden
Faktoren ab:
 Der Menge an RAM, die
den Webservern
zugewiesen ist

Der Arbeitslast, die von
der Farm verarbeitet
wird, also die
Benutzerbasis und die
Nutzungsmerkmale (ein
hoch aktiver
Anwendungspool kann
10 GB und mehr
erreichen)
Grenzen für Inhaltsdatenbanken
Die folgende Tabelle enthält die empfohlenen Richtlinien für Inhaltsdatenbanken.
Grenze
Maximalwert
Grenztyp
Hinweise
Größe von
Inhaltsdatenbanken
200 GB pro
Inhaltsdatenbank
Unterstützt
Sie sollten die Größe von
Inhaltsdatenbanken
unbedingt auf 200 GB
beschränken, um die
Aufrechterhaltung der
Systemleistung
sicherzustellen.
Inhaltsdatenbanken mit
89
Grenze
Maximalwert
Grenztyp
Hinweise
einer Größe bis zu 1
Terabyte werden nur bei
großen Repositorys mit
einer Website und
Archiven mit nicht
gemeinsamen E/A- und
Nutzungsmustern wie
Datenarchiven
unterstützt. Größere
Datenbanken werden für
diese Szenarien
unterstützt, weil ihre E/AMuster und typischen
Datenstrukturformate für
größere Größen
entwickelt und getestet
wurden. Weitere
Informationen zu großen
Dokumentrepositorys
finden Sie in "Schätzen
von Leistungs- und
Kapazitätsanforderungen
für große
Dokumentrepositorys"
unter Ergebnisse der
Leistungs- und
Kapazitätstests und
Empfehlungen
(SharePoint Server
2010) und in
Standardszenarien der
Verwaltung
umfangreicher Inhalte
unter Enterprise content
storage planning
(SharePoint Server
2010).
Eine Websitesammlung
sollte 100 GB nur dann
überschreiten, wenn es
sich um die einzige
Websitesammlung in der
Datenbank handelt.
Websitesammlungen
pro Inhaltsdatenbank
2.000 empfohlen
5.000 maximal
Unterstützt
90
Es wird empfohlen, die
Anzahl der
Websitesammlungen in
einer Inhaltsdatenbank
Grenze
Maximalwert
Grenztyp
Hinweise
auf 2.000 zu
beschränken. Unterstützt
werden jedoch bis zu
5.000
Websitesammlungen in
einer Datenbank.
Diese Grenzwerte
stehen im
Zusammenhang mit der
Upgradegeschwindigkeit.
Je höher die Anzahl von
Websitesammlungen in
einer Datenbank, desto
langsamer das Upgrade.
Die Begrenzung der
Anzahl von
Websitesammlungen in
einer Datenbank ist der
Begrenzung der Größe
einer Inhaltsdatenbank
untergeordnet, die
mehrere
Websitesammlungen
umfasst (200 GB). Aus
diesem Grund muss mit
der zunehmenden
Anzahl von
Websitesammlungen in
einer Datenbank die
Durchschnittsgröße der
in der Datenbank
enthaltenen
Websitesammlungen
abnehmen.
Mit dem Überschreiten
des Grenzwerts von
2.000
Websitesammlungen
riskieren Sie bei
Upgrades längere
Ausfallzeiten. Wenn Sie
beabsichtigen, 2.000
Websitesammlungen zu
überschreiten, sollten
Sie über eine klare
Upgradestrategie
verfügen und zusätzliche
Hardware erwerben, um
91
Grenze
Maximalwert
Grenztyp
Hinweise
Upgrades und
Softwareupdates, die
sich auf Datenbanken
auswirken, zu
beschleunigen.
Verwenden Sie zum
Festlegen der Warnstufe
für die Anzahl der
Websites in einer
Inhaltsdatenbank das
Windows PowerShellCmdlet SetSPContentDatabase mit
dem WarningSiteCountParameter. Weitere
Informationen finden Sie
unter SetSPContentDatabase.
Remote-BLOBDie Zeit bis zum ersten Beschränkung Wenn SharePoint Server
Speichersubsystem
Byte einer Antwort vom
2010 für die Verwendung
(RBS) in Network
NAS darf 20
von RBS konfiguriert ist
Attached Storage (NAS) Millisekunden nicht
und die BLOBs in NAS
überschreiten
gespeichert sind, sollten
Sie die folgende
Beschränkung
berücksichtigen.
Von dem Zeitpunkt, an
dem SharePoint Server
2010 ein BLOB
anfordert, bis zum
Empfang des ersten
Bytes vom NAS dürfen
nicht mehr als 20
Millisekunden vergehen.
Grenzen für Websitesammlungen
Die folgende Tabelle enthält die empfohlenen Richtlinien für Websitesammlungen.
Grenze
Maximalwert
Grenztyp
Website
250.000 pro
Websitesammlung
Unterstützt Die empfohlene Maximalzahl
von Websites und
Unterwebsites liegt bei
92
Hinweise
Grenze
Maximalwert
Grenztyp
Hinweise
250.000 Websites.
Sie können eine sehr große
Gesamtanzahl von Websites
durch Schachteln von
Unterwebsites erstellen. So
hätten Sie beispielsweise in
einer flachen Hierarchie mit
100 Websites mit jeweils
1.000 Unterwebsites eine
Gesamtzahl von 100.000
Websites.
Hinweis: Das Löschen oder
Erstellen einer Website oder
Unterwebsite kann sich
signifikant auf die
Verfügbarkeit einer Website
auswirken. Während des
Löschens der Website ist
der Zugriff auf die Website
und die Unterwebsites
eingeschränkt. Außerdem
kann der Versuch, mehrere
Unterwebsites gleichzeitig
zu erstellen, fehlschlagen.
Größe einer
Websitesammlung
100 GB pro
Websitesammlung
Unterstützt Eine Websitesammlung
sollte 100 GB nur dann
überschreiten, wenn es sich
um die einzige
Websitesammlung in der
Datenbank handelt.
Einige
Websitesammlungsaktionen,
z. B. die
Sicherung/Wiederherstellung
von Websites oder das
Windows PowerShellCmdlet Move-SPSite,
führen zu großen Microsoft
SQL Server-Operationen,
die sich auf die Leistung
auswirken oder fehlschlagen
können, wenn andere
Websitesammlungen in
derselben Datenbank aktiv
sind. Weitere Informationen
finden Sie unter MoveSPSite.
93
Listen- und Bibliotheksgrenzen
Die folgende Tabelle enthält die empfohlenen Richtlinien für Listen und Bibliotheken.
Weitere Informationen finden Sie im Whitepaper "Entwerfen umfangreicher Listen und
Maximieren der Leistung von Listen" unter Ergebnisse der Leistungs- und Kapazitätstests
und Empfehlungen (SharePoint Server 2010).
Grenze
Maximalwert
Grenztyp
Hinweise
Listenzeilengröße 8.000 Bytes pro Beschränku Jedes Listen- bzw. Bibliothekselement
Zeile
kann nur insgesamt 8.000 Bytes in der
ng
Datenbank belegen. 256 Bytes sind für
integrierte Spalten reserviert, sodass
7.774 Bytes für Endbenutzerspalten
übrig bleiben. Weitere Informationen
über den Platzanspruch der einzelnen
Felder finden Sie unter
Spaltengrenzen.
Dateigröße
2 GB
Dokumente
30.000.000 pro Unterstützt
Bibliothek
Sie können sehr große
Dokumentbibliotheken durch
Schachteln von Ordnern erstellen oder
indem Sie Standardansichten und eine
Websitehierarchie verwenden. Dieser
Wert kann je nach Organisation der
Dokumente und Ordner sowie je nach
Art und der Größe der gespeicherten
Dokumente variieren.
Hauptversionen
400.000
Wenn Sie diesen Grenzwert
überschreiten, können allgemeine
Dateioperationen – wie das Öffnen,
Speichern und Löschen von Dateien
oder Anzeigen des Dateiverlaufs –
möglicherweise nicht mehr erfolgreich
ausgeführt werden.
Elemente
30.000.000 pro Unterstützt
Liste
Beschränku Die maximale Dateigröße liegt
ng
standardmäßig bei 50 MB. Sie kann auf
2 GB erhöht werden, doch können sich
viele sehr große Dateien auf die
Farmleistung auswirken.
Unterstützt
94
Sie können sehr große Listen erstellen,
indem Sie Standardansichten,
Websitehierarchien und die
Metadatennavigation verwenden.
Dieser Wert kann je nach Anzahl der
Grenze
Maximalwert
Grenztyp
Hinweise
Spalten in der Liste und der Nutzung
der Liste variieren.
Zeilengrößengrenz 6 interne
Unterstützt
Tabellenzeilen
e
in der
Datenbank, die
für ein Listenoder ein
Bibliothekselem
ent verwendet
werden
Gibt die maximale Anzahl von internen
Tabellenzeilen der Datenbank an, die
für ein Listen- oder Bibliothekselement
verwendet werden können. Für breite
Listen mit vielen Spalten kann jedes
Element über mehrere interne
Tabellenzeilen umbrochen werden
(standardmäßig über bis zu sechs
Zeilen). Diese Konfiguration kann nur
mithilfe des Objektmodells von
Farmadministratoren vorgenommen
werden. Die Objektmodellmethode ist
SPWebApplication.MaxListItemRowSto
rage.
Massenvorgänge 100 Elemente Beschränku Die Benutzeroberfläche lässt eine
pro
ng
Auswahl von maximal 100 Elementen
Massenvorgang
für Massenvorgänge zu.
Schwellenw Gibt die maximale Anzahl von JOINSchwellenwert für 8 JOINOperationen
pro
ert
Operationen pro Abfrage an, wie
den Listenansichtbeispielsweise solchen, die auf
Nachschlagevorga Abfrage
Nachschlagespalten, Person/Gruppeng
Spalten oder Workflowstatusspalten
basieren. Werden in der Abfrage mehr
als acht JOIN-Operationen verwendet,
wird der Vorgang blockiert. Dies gilt
nicht für Operationen mit einzelnen
Elementen. Bei Verwendung der
Maximalansicht über das Objektmodell
(indem keine Ansichtsfelder angegeben
werden) gibt SharePoint die ersten acht
Nachschlagevorgänge zurück.
Schwellenwert für 5.000
die Listenansicht
Schwellenw Gibt die maximale Anzahl von Listenert
oder Bibliothekselementen an, die mit
einem Datenbankvorgang
(beispielsweise einer Abfrage)
außerhalb des vom Administrator
festgelegten täglichen Zeitfensters, in
dem keine Einschränkungen für
Abfragen bestehen, gleichzeitig
verarbeitet werden können.
Schwellenwert für 20.000
Listenansicht für
Auditoren und
Schwellenw Gibt die maximale Anzahl von Listenert
oder Bibliothekselementen an, die mit
einem Datenbankvorgang
95
Grenze
Maximalwert
Grenztyp
Administratoren
Unterwebsite
Hinweise
(beispielsweise einer Abfrage)
gleichzeitig verarbeitet werden können,
wenn der Vorgang von einem Auditor
oder Administrator mit entsprechenden
Berechtigungen ausgeführt wird. Diese
Einstellung funktioniert mit
Außerkraftsetzung des
Objektmodells zulassen.
2.000 pro
Schwellenw Die Leistung der Schnittstelle für das
Websiteansicht ert
Aufzählen von Unterwebsites einer
bestimmten Website ist nicht optimal,
wenn die Anzahl der Unterwebsites
über 2.000 liegt. Außerdem nimmt die
Leistung der Seite Gesamter
Websiteinhalt und des
Strukturansicht-Steuerelements mit
der wachsenden Zahl von
Unterwebsites signifikant ab.
Gemeinsame
10 Bearbeiter
Schwellenw Die empfohlene maximale Anzahl
Dokumenterstellun gleichzeitig pro ert
gleichzeitiger Bearbeiter liegt bei 10.
g in Microsoft
Dokument
Der Höchstwert liegt bei 99.
Word und
Wenn 99 Bearbeiter gleichzeitig ein
Microsoft
Dokument zur gemeinsamen
PowerPoint für
Bearbeitung geöffnet haben, wird ab
DOCX-, PPTXdem 100. Benutzer jedem Benutzer der
und PPSXFehler "Dokument wird verwendet"
Dateien
angezeigt, und er muss eine
schreibgeschützte Kopie anzeigen.
Bei mehr als 10 Bearbeitern
gleichzeitig kommt es zu einer
sukzessiven Beeinträchtigung der
Benutzererfahrung durch mehr
Konflikte, und es sind mehr
Wiederholungen nötig, um Änderungen
erfolgreich hochzuladen.
Sicherheitsbereich 1.000 pro Liste
Schwellenw Die maximale Anzahl eindeutiger
ert
Sicherheitsbereiche, die für eine Liste
festgelegt werden, sollte 1.000 nicht
überschreiten.
Ein Bereich ist die
Sicherheitsbeschränkung für ein
sicherungsfähiges Objekt und all seine
untergeordneten Objekte, für die keine
separate Sicherheitsbeschränkung
vorliegt. Ein Bereich enthält eine
96
Grenze
Maximalwert
Grenztyp
Hinweise
Zugriffssteuerungsliste (Access Control
List, ACL), doch im Gegensatz zu
NTFS-Zugriffssteuerungslisten kann
ein Bereich spezifische
Sicherheitsprinzipale für SharePoint
Server enthalten. Zu den Mitgliedern
der Zugriffssteuerungsliste eines
Bereichs können Windows-Benutzer,
andere, nicht Windows-basierte
Benutzerkonten (z. B. formularbasierte
Konten), Active Directory-Gruppen oder
SharePoint-Gruppen gehören.
Spaltengrenzen
SharePoint Server 2010-Daten werden in SQL Server-Tabellen gespeichert. Um die
maximale Anzahl möglicher Spalten in einer SharePoint-Liste zuzulassen, erstellt
SharePoint Server mehrere Zeilen in der Datenbank, wenn Daten nicht in eine Zeile
passen. Dieser Vorgang wird Zeilenumbruch genannt.
Sobald eine Zeile in SQL Server umbrochen wird, wird der Server bei Abfragen dieses
Elements zusätzlich belastet, da ein SQL-Join in der Abfrage enthalten sein muss. Um
eine zu große Last zu verhindern, sind standardmäßig maximal sechs SQL Server-Zeilen
für ein SharePoint-Element zugelassen. Dieser Grenzwert führt zu einer bestimmten
Beschränkung der Anzahl von Spalten, die in einer SharePoint-Liste enthalten sein
können. In der folgenden Tabelle werden die Grenzwerte für die einzelnen Spaltentypen
erläutert.
Der Zeilenumbruchparameter kann auf mehr als sechs erhöht werden, doch kann dies zu
einer zu hohen Serverlast führen. Vor dem Überschreiten dieses Grenzwerts sollten
deshalb Leistungstests durchgeführt werden. Weitere Informationen finden Sie im
Whitepaper "Entwerfen umfangreicher Listen und Maximieren der Leistung von Listen"
unter Ergebnisse der Leistungs- und Kapazitätstests und Empfehlungen (SharePoint
Server 2010).
Für jeden Spaltentyp ist ein Größenwert in Bytes aufgelistet. Die Summe aller Spalten in
einer SharePoint-Liste kann 8.000 Bytes nicht übersteigen. Je nach Spaltennutzung
können Benutzer die Grenze von 8.000 Bytes vor der Zeilenumbruchgrenze von sechs
Zeilen erreichen.
Grenze
Maximalwert
Grenztyp
Eine Textzeile
276
Schwellenwert 28
Bytes
Größe
pro
Spalte
97
Hinweise
Ein SQL Server-Zeilenumbruch
erfolgt nach 64 Spalten in einer
SharePoint-Liste. Der
Standardwert von sechs Zeilen
für den Zeilenumbruch lässt pro
SharePoint-Liste maximal 384
Grenze
Maximalwert
Grenztyp
Größe
pro
Spalte
Hinweise
Spalten mit einer Textzeile zu
(6 x 64 = 384). Da der
Grenzwert pro SharePointListenelement jedoch bei 8.000
Bytes liegt, von denen 256
Bytes für integrierte
SharePoint-Spalten reserviert
sind, liegt die tatsächliche
Grenze bei 276 Spalten mit
einer Textzeile.
Mehrere
Textzeilen
192
Schwellenwert 28
Bytes
Ein SQL Server-Zeilenumbruch
erfolgt nach 32 Spalten in einer
SharePoint-Liste. Der
Standardwert von sechs Zeilen
für den Zeilenumbruch lässt pro
SharePoint-Liste maximal 192
Spalten mit mehreren
Textzeilen zu (6 x 32 = 192).
Auswahl
276
Schwellenwert 28
Bytes
Ein SQL Server-Zeilenumbruch
erfolgt nach 64 Spalten in einer
SharePoint-Liste. Der
Standardwert von sechs Zeilen
für den Zeilenumbruch lässt pro
SharePoint-Liste maximal 394
Auswahlspalten zu (6 x 64 =
384). Da der Grenzwert pro
SharePoint-Listenelement
jedoch bei 8.000 Bytes liegt,
von denen 256 Bytes für
integrierte SharePoint-Spalten
reserviert sind, liegt die
tatsächliche Grenze bei 276
Auswahlspalten.
Zahl
72
Schwellenwert 12
Bytes
Ein SQL Server-Zeilenumbruch
erfolgt nach 12 Spalten in einer
SharePoint-Liste. Der
Standardwert von sechs Zeilen
für den Zeilenumbruch lässt pro
SharePoint-Liste maximal 72
Zahlenspalten zu (6 x 12 = 72).
Währung
72
Schwellenwert 12
Bytes
Ein SQL Server-Zeilenumbruch
erfolgt nach 12 Spalten in einer
SharePoint-Liste. Der
Standardwert von sechs Zeilen
98
Grenze
Maximalwert
Grenztyp
Größe
pro
Spalte
Hinweise
für den Zeilenumbruch lässt pro
SharePoint-Liste maximal 72
Währungsspalten zu (6 x 12 =
72).
Datum und
Uhrzeit
48
Schwellenwert 12
Bytes
Nachschlagen
96
Schwellenwert 4 Bytes Ein SQL Server-Zeilenumbruch
erfolgt nach 16 Spalten in einer
SharePoint-Liste. Der
Standardwert von sechs Zeilen
für den Zeilenumbruch lässt pro
SharePoint-Liste maximal 96
Nachschlagespalten mit einem
Wert zu (6 x 16 = 96).
Ja/Nein
96
Schwellenwert 5 Bytes Ein SQL Server-Zeilenumbruch
erfolgt nach 16 Spalten in einer
SharePoint-Liste. Der
Standardwert von sechs Zeilen
für den Zeilenumbruch lässt pro
SharePoint-Liste maximal 96
Ja/Nein-Spalten zu (6 x 16 =
96).
Person oder
Gruppe
96
Schwellenwert 4 Bytes Ein SQL Server-Zeilenumbruch
erfolgt nach 16 Spalten in einer
SharePoint-Liste. Der
Standardwert von sechs Zeilen
für den Zeilenumbruch lässt pro
SharePoint-Liste maximal 96
Personen- oder
Gruppenspalten zu (6 x 16 =
96).
Link oder Bild
138
Schwellenwert 56
Bytes
99
Ein SQL Server-Zeilenumbruch
erfolgt nach 8 Spalten in einer
SharePoint-Liste. Der
Standardwert von sechs Zeilen
für den Zeilenumbruch lässt pro
SharePoint-Liste maximal 48
Datums- und Uhrzeitspalten zu
(6 x 8 = 48).
Ein SQL Server-Zeilenumbruch
erfolgt nach 32 Spalten in einer
SharePoint-Liste. Der
Standardwert von sechs Zeilen
für den Zeilenumbruch lässt pro
SharePoint-Liste maximal 192
Grenze
Maximalwert
Grenztyp
Größe
pro
Spalte
Hinweise
Link- oder Bildspalten zu (6 x
32 = 192). Da der Grenzwert
pro SharePoint-Listenelement
jedoch bei 8.000 Bytes liegt,
von denen 256 Bytes für
integrierte SharePoint-Spalten
reserviert sind, liegt die
tatsächliche Grenze bei 138
Link- oder Bildspalten.
Berechnet
48
Schwellenwert 28
Bytes
Ein SQL Server-Zeilenumbruch
erfolgt nach 8 Spalten in einer
SharePoint-Liste. Der
Standardwert von sechs Zeilen
für den Zeilenumbruch lässt pro
SharePoint-Liste maximal 48
berechnete Spalten zu (6 x 8 =
48).
GUID
6
Schwellenwert 20
Bytes
Ein SQL Server-Zeilenumbruch
erfolgt nach jeder Spalte in
einer SharePoint-Liste. Der
Standardwert von sechs Zeilen
für den Zeilenumbruch lässt pro
SharePoint-Liste maximal
sechs GUID-Spalten zu (6 x 1
= 6).
Int
96
Schwellenwert 4 Bytes Ein SQL Server-Zeilenumbruch
erfolgt nach 16 Spalten in einer
SharePoint-Liste. Der
Standardwert von sechs Zeilen
für den Zeilenumbruch lässt pro
SharePoint-Liste maximal 96
Int-Spalten zu (6 x 16 = 96).
Verwaltete
Metadaten
94
Schwellenwert 40
Dem ersten verwalteten
Bytes
Metadatenfeld, das einer Liste
für die hinzugefügt wird, werden vier
erste,
Spalten zugewiesen:
32 für  Ein Nachschlagefeld für
jede
das eigentliche Tag
folgende
 Ein ausgeblendetes
Textfeld für den
Zeichenfolgenwert

100
Ein Nachschlagefeld für
den Catch-All
Grenze
Maximalwert
Grenztyp
Größe
pro
Spalte
Hinweise

Ein Nachschlagefeld für
den Catch-All-Überlauf
Für jedes folgende verwaltete
Metadatenfeld, das einer Liste
hinzugefügt wird, werden zwei
weitere Spalten hinzugefügt:

Ein Nachschlagefeld für
das eigentliche Tag

Ein ausgeblendetes
Textfeld für den
Zeichenfolgenwert
Die maximale Anzahl von
Spalten verwalteter Metadaten
wird mit (14 + (16 x (n-1))
berechnet, wobei n der
Zeilenzuordnungswert ist
(Standard: 6).
Spalten für externe Daten folgen dem Konzept einer primären Spalte und sekundärer
Spalten. Wenn Sie eine externe Datenspalte hinzufügen, können Sie einige sekundäre
Felder des externen Inhaltstyps auswählen, die der Liste hinzugefügt werden sollen. So
können Sie bei Hinzufügen einer externen Datenspalte vom Inhaltstyp "Kunde", der
Felder wie "ID", "Name", "Land" und "Beschreibung" besitzt, sekundäre Felder
hinzufügen, um "ID", "Name" und "Beschreibung" des Kunden anzuzeigen. Im
Allgemeinen werden folgende Spalten hinzugefügt:
 Primäre Spalte: ein Textfeld

Ausgeblendete ID-Spalte: ein mehrzeiliges Textfeld.

Sekundäre Spalten: Jede sekundäre Spalte enthält einen Text/eine Zahl/einen
booleschen Wert/mehrzeiligen Text basierend auf dem im GeschäftsdatenkatalogModell definierten Datentyp der sekundären Spalte. So kann beispielsweise "ID"
einer Zahlenspalte, "Name" einer Spalte mit einer Textzeile und "Beschreibung" einer
Spalte mit mehreren Textzeilen zugeordnet sein.
Seitengrenzen
Die folgende Tabelle enthält die empfohlenen Richtlinien für Seiten.
Grenze
Maximalwert
Grenztyp
Webparts
25 pro Wiki- oder
Webpartseite
Schwellenwert Bei dieser
Zahl handelt
es sich um
eine
Schätzung
101
Hinweise
Grenze
Maximalwert
Grenztyp
Hinweise
auf der
Grundlage
einfacher
Webparts.
Wie viele
Webparts
auf einer
Seite
verwendet
werden
können,
bevor die
Leistung
beeinträchtigt
wird, hängt
von der
Komplexität
der
Webparts
ab.
Sicherheitsgrenzen
Grenze
Maximalwert
Anzahl der
5.000
SharePointGruppen, zu denen
ein Benutzer
gehören kann
Grenztyp
Hinweise
Unterstütz Dies ist keine harte Grenze,
entspricht aber den Active
t
Directory-Richtlinien. Die Zahl wird
von mehreren Faktoren beeinflusst:
 Größe des Benutzertokens
102

Gruppencache: SharePoint
Server 2010 besitzt eine
Tabelle, in der die Anzahl der
Gruppen, zu denen ein
Benutzer gehört,
zwischengespeichert wird,
sobald diese Gruppen in
Zugriffssteuerungslisten
verwendet werden.

Sicherheitsüberprüfungszeit:
Mit der wachsenden Zahl von
Benutzergruppen, zu denen ein
Benutzer gehört, nimmt auch
die für die Zugriffsüberprüfung
erforderliche Zeit zu.
Grenze
Maximalwert
Benutzer in einer 2 Millionen pro
Websitesammlung Websitesammlung
Grenztyp
Hinweise
Unterstütz Sie können Ihrer Website Millionen
t
von Personen hinzufügen, indem
Sie die Sicherheit mithilfe von
Microsoft WindowsSicherheitsgruppen anstatt über
einzelne Benutzer verwalten.
Bei dieser Grenze werden
Verwaltbarkeit und die einfache
Navigation auf der
Benutzeroberfläche berücksichtigt.
Wenn Sie zahlreiche Einträge
(Sicherheitsgruppen mit Benutzern)
in der Websitesammlung haben
(über 1.000), sollten Sie anstelle
der Benutzeroberfläche Windows
PowerShell verwenden, um
Benutzer zu verwalten. Auf diese
Weise können Sie die Verwaltung
vereinfachen.
Active Directory5.000 pro SharePoint- Unterstütz
Prinzipale/Benutzer Gruppe
t
in einer
SharePoint-Gruppe
In SharePoint Server 2010 können
Sie Benutzer oder Active DirectoryGruppen einer SharePoint-Gruppe
hinzufügen.
Eine Zahl von bis zu 5.000
Benutzern (bzw. Active DirectoryGruppen oder -Benutzer) in einer
SharePoint-Gruppe bietet eine
akzeptable Leistung.
Folgende Aktivitäten sind am
stärksten von dieser Grenze
betroffen:
 Das Abrufen von Benutzern zur
Überprüfung von
Berechtigungen. Dieser
Vorgang nimmt mit der
zunehmenden Anzahl von
Benutzern in einer Gruppe
inkrementell mehr Zeit in
Anspruch.

103
Das Rendern der
Mitgliedschaft in der Ansicht.
Dieser Vorgang erfordert stets
Zeit.
Grenze
Maximalwert
Grenztyp
Hinweise
SharePointGruppen
10.000 pro
Websitesammlung
Unterstütz Bei mehr als 10.000 Gruppen
nimmt die zum Ausführen von
t
Vorgängen erforderliche Zeit
beträchtlich zu. Dies gilt vor allem
für das Hinzufügen eines
Benutzers zu einer vorhandenen
Gruppe, das Erstellen einer neuen
Gruppe und das Rendern von
Gruppenansichten.
Sicherheitsprinzipal 5.000 pro
Unterstütz Die Größe des Bereichs wirkt sich
Zugriffssteuerungslist t
: Größe des
auf die Daten aus, die für eine
Sicherheitsbereichs e
Sicherheitsüberprüfungsberechnun
g verwendet werden. Diese
Berechnung erfolgt jedes Mal,
wenn der Bereich sich ändert. Es
gibt keine harte Grenze, doch
dauert die Berechnung umso
länger, je größer der Bereich ist.
Grenzen nach Feature
In diesem Abschnitt werden die Grenzen nach Feature aufgelistet.
Suchgrenzen
Die folgende Tabelle enthält die empfohlenen Richtlinien für die Suche.
Grenze
Maximalwert
SharePoint20 pro Farm
Suchdienstanwendung
en
Grenztyp
Hinweise
Unterstütz In einer Farm können
t
mehrere SharePointSuchdienstanwendungen
bereitgestellt werden, da Sie
Suchkomponenten und
Datenbanken separaten
Servern zuweisen können.
Die empfohlene Grenze von
20 ist niedriger als die
maximale Grenze für alle
Dienstanwendungen in einer
Farm.
Durchforstungsdatenb 10
Schwellen Die Durchforstungsdatenbank
anken und Durchforstungsdatenba wert
speichert die
datenbankelemente
nken pro
Durchforstungsdaten
Suchdienstanwendung
(Zeit/Status usw.) zu allen
Elementen, die durchforstet
104
Grenze
Maximalwert
25 Millionen Elemente
pro
Durchforstungsdatenba
nk
Grenztyp
Hinweise
wurden. Der unterstützte
Grenzwert liegt bei 10
Durchforstungsdatenbanken
pro SharePointSuchdienstanwendung.
Die empfohlene Grenze liegt
bei 25 Millionen Elementen
pro Durchforstungsdatenbank
(oder insgesamt vier
Durchforstungsdatenbanken
pro Suchdienstanwendung).
Durchforstungskompon 16 pro
Schwellen Die empfohlene Grenze pro
enten
Suchdienstanwendung wert
Anwendung liegt bei 16
Durchforstungskomponenten
insgesamt, mit jeweils zwei
pro Durchforstungsdatenbank
und zwei pro Server – unter
der Voraussetzung, dass der
Server mindestens acht
Prozessoren (Kerne) besitzt.
Die Gesamtzahl von
Durchforstungskomponenten
pro Server muss niedriger
sein als
128/(Abfragekomponenten
insgesamt), um die
Verschlechterung der
Verteilungs-E/A zu
minimieren. Das
Überschreiten der
empfohlenen Grenze muss
die Durchforstungsleistung
nicht erhöhen; tatsächlich
kann die
Durchforstungsleistung in
Abhängigkeit von den
verfügbaren Ressourcen des
Durchforstungsservers, der
Datenbank und des
Inhaltshosts abnehmen.
Indexpartitionen
20 pro
Schwellen Die Indexpartition beinhaltet
Suchdienstanwendung; wert
einen Teil des Indexes der
128 insgesamt
Suchdienstanwendung. Die
empfohlene Grenze ist 20.
Eine Erhöhung der Anzahl
von Indexpartitionen führt
dazu, dass jede Partition
105
Grenze
Maximalwert
Grenztyp
Hinweise
einen kleineren Teil des
Indexes umfasst und dadurch
RAM und Festplattenspeicher
reduziert werden, die auf dem
Abfrageserver mit der
Abfragekomponente benötigt
werden, die der Indexpartition
zugewiesen ist. Die
Gesamtanzahl der
Indexpartitionen ist auf 128
beschränkt.
Indizierte Elemente
100 Millionen pro
Unterstütz Die SharePoint-Suche
Suchdienstanwendung; t
unterstützt Indexpartitionen,
10 Millionen pro
von denen jede jeweils einen
Indexpartition
Teil des Suchindexes enthält.
Das empfohlene Maximum
liegt bei zehn Millionen
Elementen in einer Partition.
Die insgesamt empfohlene
maximale Anzahl von
Elementen (beispielsweise
Personen, Listenelemente,
Dokumente, Webseiten) liegt
bei 100 Millionen.
Durchforstungsprotokol 100 Millionen pro
Suchanwendung
leinträge
Unterstütz Dies ist die Anzahl einzelner
Protokolleinträge im
t
Durchforstungsprotokoll. Sie
richtet sich nach der Grenze
für indizierte Elemente.
Eigenschaftendatenba 10 pro
Schwellen Die Eigenschaftendatenbank
nken
Suchdienstanwendung; wert
speichert die Metadaten für
128 insgesamt
Elemente in den ihr
zugeordneten
Indexpartitionen. Eine
Indexpartition kann nur einem
Eigenschaftenspeicher
zugeordnet sein. Die
empfohlene Grenze liegt bei
zehn
Eigenschaftendatenbanken
pro Suchdienstanwendung.
Die Beschränkung für
Indexpartitionen liegt bei 128.
Abfragekomponenten 128 pro
Schwellen Die Gesamtzahl der
Suchanwendung;
wert
Abfragekomponenten wird
64/(Durchforstungskom
durch die Fähigkeit der
106
Grenze
Maximalwert
Grenztyp
ponenten insgesamt)
pro Server
Hinweise
Durchforstungskomponenten
zum Kopieren von Dateien
beschränkt. Die maximale
Anzahl von
Abfragekomponenten pro
Server wird durch die
Fähigkeit der
Abfragekomponenten zur
Aufnahme der von den
Durchforstungskomponenten
verteilten Dateien begrenzt.
Bereichsregeln
100 Bereichsregeln pro Schwellen Bei Überschreiten dieser
Bereich; 600 insgesamt wert
Grenze nimmt die Aktualität
pro
der Durchforstung ab, und
Suchdienstanwendung
mögliche Ergebnisse von
Abfragen mit zugewiesenen
Bereichen werden verzögert.
Bereiche
200 pro Website
Schwellen Hierbei handelt es sich um
wert
eine empfohlene Grenze pro
Website. Das Überschreiten
dieser Grenze kann dazu
führen, dass die
Durchforstungseffizienz
abnimmt, und sich auf die
Browserwartezeit für
Endbenutzer auswirken, falls
die Bereiche zur
Anzeigegruppe hinzugefügt
werden. Außerdem
verschlechtert sich die
Anzeige der Bereiche in der
Verwaltungsoberfläche der
Suche, wenn die Anzahl der
Bereiche die empfohlene
Grenze übersteigt.
Anzeigegruppen
25 pro Website
Schwellen Anzeigegruppen werden für
wert
eine gruppierte Anzeige von
Bereichen über die
Benutzeroberfläche
verwendet. Mit dem
Überschreiten dieser Grenze
verschlechtert sich die
Bereichsfunktionalität in der
Verwaltungsoberfläche der
Suche.
107
Grenze
Maximalwert
Grenztyp
Hinweise
Benachrichtigungen
1.000.000 pro
Suchanwendung
Unterstütz Hierbei handelt es sich um
den getesteten Grenzwert.
t
Inhaltsquellen
50 pro
Schwellen Die empfohlene Grenze von
Suchdienstanwendung wert
50 kann bis zur Grenze von
500 pro
Suchdienstanwendung
überschritten werden. Es
sollten jedoch weniger
Startadressen verwendet
werden. Außerdem muss die
Grenze für gleichzeitige
Durchforstungen
berücksichtigt werden.
Startadressen
100 pro Inhaltsquelle
Gleichzeitige
Durchforstungen
20 pro Suchanwendung Schwellen Hierbei handelt es sich um
wert
die Anzahl der
Durchforstungen, die
gleichzeitig stattfinden. Ein
Überschreiten dieser Zahl
kann zu einer
Verschlechterung der
allgemeinen
Durchforstungsrate führen.
Durchforstete
Eigenschaften
500.000 pro
Suchanwendung
Schwellen Die empfohlene Grenze kann
wert
bis zur Beschränkung von
500 pro Inhaltsquelle
überschritten werden. Je
mehr Startadressen Sie
jedoch haben, desto weniger
Inhaltsquellen sollten
verwendet werden. Bei vielen
Startadressen sollten Sie
diese als Links auf einer
HTML-Seite platzieren und
den HTTP-Crawler die Seite
durchforsten lassen, indem er
den Links folgt.
Unterstütz Hierbei handelt es sich um
die bei einer Durchforstung
t
entdeckten Eigenschaften.
100
Regel für
Crawlerauswirkungen
Schwellen Empfohlene Grenze von 100
wert
pro Farm. Die Empfehlung
kann überschritten werden,
allerdings verschlechtert sich
die Anzeige von
Websitezugriffsregeln in der
108
Grenze
Maximalwert
Grenztyp
Hinweise
Verwaltungsoberfläche der
Suche. Bei etwa 2.000
Websitezugriffsregeln wird die
Seite Websitezugriffsregeln
verwalten unlesbar.
Durchforstungsregeln 100 pro
Schwellen Dieser Wert kann
Suchdienstanwendung wert
überschritten werden;
allerdings verschlechtert sich
die Anzeige von
Durchforstungsregeln in der
Verwaltungsoberfläche der
Suche.
Verwaltete
Eigenschaften
100.00 pro
Schwellen Hierbei handelt es sich um
Suchdienstanwendung wert
Eigenschaften, die vom
Suchsystem in Abfragen
verwendet werden.
Durchforstete Eigenschaften
werden verwalteten
Eigenschaften zugeordnet.
Zuordnungen
100 pro verwaltete
Eigenschaft
Schwellen Das Überschreiten dieser
wert
Grenze kann zu einer
Verschlechterung der
Durchforstungsgeschwindigke
it und Abfrageleistung führen.
URL-Entfernungen
100 Entfernungen pro
Vorgang
Unterstütz Hierbei handelt es sich um
die empfohlene Maximalzahl
t
an URLs, die in einem
einzigen Vorgang aus dem
System entfernt werden
sollten.
Autorisierende Seiten Eine Seite auf höchster Schwellen Die empfohlene Grenze ist
wert
eine autorisierende Seite auf
Ebene und minimale
höchster Ebene und
Seiten auf zweiter und
dritter Ebene pro
möglichst wenig Seiten auf
Suchdienstanwendung
zweiter und dritter Ebene, um
die gewünschte Relevanz zu
erreichen.
Die Beschränkung liegt bei
200 pro Relevanzebene pro
Suchanwendung, doch wird
bei Hinzufügen zusätzlicher
Seiten möglicherweise nicht
die gewünschte Relevanz
erzielt. Fügen Sie die
Schlüsselwebsite zur ersten
109
Grenze
Maximalwert
Grenztyp
Hinweise
Relevanzebene hinzu. Fügen
Sie weitere Schlüsselwebsites
auf der zweiten oder dritten
Relevanzebene hinzu, und
bewerten Sie nach jedem
Hinzufügen die Relevanz, um
sicherzustellen, dass der
gewünschte Relevanzeffekt
erreicht wird.
Schlüsselwörter
200 pro
Websitesammlung
Unterstütz Die empfohlene Grenze kann
bis zur (durch ASP.NET
t
bestimmten) Maximalgrenze
von 5.000 pro
Websitesammlung bei fünf
besten Suchergebnissen pro
Schlüsselwort überschritten
werden. Wenn Sie diese
Grenze überschreiten,
verschlechtert sich die
Anzeige von Schlüsselwörtern
auf der Benutzeroberfläche
der Websiteverwaltung. Die
durch ASP.NET bestimmte
Grenze kann durch das
Bearbeiten der Dateien
Web.Config und
Client.config(MaxItemsInOb
jectGraph) geändert werden.
Erkannte
10.000 pro
Beschränk Hierbei handelt es sich um
Metadateneigenschaft durchforstetes Element ung
die Anzahl von
en
Metadateneigenschaften, die
bestimmt und potenziell
zugeordnet oder für Abfragen
verwendet werden können,
wenn ein Element
durchforstet wird.
Grenzen für den Benutzerprofildienst
Die folgende Tabelle enthält die empfohlenen Richtlinien für den Benutzerprofildienst.
Grenze
Maximalwert
Grenztyp
Benutzerprofile
2.000.000 pro
Dienstanwendung
Unterstützt Eine BenutzerprofilDienstanwendung kann bis
zu zwei Millionen
110
Hinweise
Grenze
Maximalwert
Grenztyp
Hinweise
Benutzerprofile mit
umfassender Funktionalität
für die Features sozialer
Netzwerke unterstützen. Die
Zahl stellt die Anzahl der
Profile dar, die aus einem
Verzeichnisdienst in den
Benutzerprofilspeicher
importiert werden können,
sowie die Anzahl der Profile,
die eine BenutzerprofilDienstanwendung
unterstützen kann, ohne
dass es bei Features für
soziale Netzwerke zu
Leistungsverschlechterungen
kommt.
Thematische
Kategorien, Notizen
und Bewertungen
500.000.000 pro
Unterstützt Bis zu 500 Millionen
thematische Kategorien,
Datenbank für
Notizen und Bewertungen
Funktionen und Daten
insgesamt werden in einer
für das soziale
Datenbank für Funktionen
Netzwerk
und Daten für das soziale
Netzwerk unterstützt, ohne
dass es zu signifikanten
Leistungsverschlechterungen
kommt. Allerdings kann es
bei Wartungsvorgängen wie
Sicherung und
Wiederherstellung an diesem
Punkt zu
Leistungsbeeinträchtigungen
kommen.
Inhaltsbereitstellungsgrenzen
Die folgende Tabelle enthält die empfohlenen Richtlinien für die Inhaltsbereitstellung.
Grenze
Maximalwert
Grenztyp
In verschiedenen Pfaden
20
ausgeführte
Inhaltsbereitstellungsaufträge
Hinweise
Unterstützt Für gleichzeitig ausgeführte
Aufträge in Pfaden, die mit
Websitesammlungen in
derselben
Quellinhaltsdatenbank
verbunden sind, besteht ein
111
Grenze
Maximalwert
Grenztyp
Hinweise
erhöhtes Risiko für
Deadlocks in der Datenbank.
Für Aufträge, die gleichzeitig
ausgeführt werden müssen,
sollten Sie die
Websitesammlungen in
verschiedene
Quellinhaltsdatenbanken
verschieben.
Hinweis:
Gleichzeitig ausgeführte
Aufträge in einem Pfad sind
nicht möglich.
Wenn Sie SQL ServerMomentaufnahmen für die
Inhaltsbereitstellung
verwenden, wird für jeden
Pfad eine Momentaufnahme
erstellt. Dadurch werden die
E/A-Anforderungen für die
Quelldatenbank erhöht.
Weitere Informationen finden
Sie unter
Bereitstellungspfade und aufträge.
Bloggrenzen
Die folgende Tabelle enthält die empfohlenen Richtlinien für Blogs.
Grenze
Maximalwert
Grenztyp
Hinweise
Blogbeiträge
5.000 pro Website
Unterstützt
Die maximale
Anzahl von
Blogbeiträgen
liegt bei 5.000
pro Website.
Kommentare
1.000 pro Beitrag
Unterstützt
Die maximale
Anzahl von
Kommentaren
liegt bei 1.000
pro Beitrag.
112
Grenzen für Business Connectivity Services
Die folgende Tabelle enthält die empfohlenen Richtlinien für Business Connectivity
Services.
Grenze
Maximalwert
Grenztyp
Externe Inhaltstypen (im
Arbeitsspeicher)
5.000 pro Webserver (pro Beschränkung Gesamtzahl von
Mandant)
Definitionen für
externe Inhaltstypen,
die zu einem
bestimmten
Zeitpunkt im
Arbeitsspeicher auf
einem Webserver
geladen sind.
Externe
Systemverbindungen
500 pro Webserver
113
Hinweise
Beschränkung Anzahl der
aktiven/offenen
Systemverbindungen
zu einem
bestimmten
Zeitpunkt. Der
standardmäßige
Maximalwert liegt bei
200, die
Beschränkung bei
500. Diese Grenze
wird für den
Webserverbereich
unabhängig von der
Art des externen
Systems (wie
Datenbank, .NETAssembly usw.)
durchgesetzt. Der
standardmäßige
Maximalwert wird
verwendet, um die
Anzahl der
Verbindungen zu
begrenzen. Eine
Anwendung kann
mittels
Ausführungskontext
eine höhere Grenze
festlegen. Die
Beschränkung
erzwingt den
Grenze
Maximalwert
Grenztyp
Hinweise
Maximalwert auch
für Anwendungen,
die den
Standardwert nicht
berücksichtigen.
Pro Anforderung
zurückgegebene
Datenbankelemente
2.000 pro
Datenbankconnector
Schwellenwert Die Anzahl der
Elemente pro
Anforderung, die der
Datenbankconnector
zurückgeben kann.
Der standardmäßige
Maximalwert von
2.000 wird vom
Datenbankconnector
verwendet, um die
Anzahl der
Ergebnisse zu
begrenzen, die pro
Seite zurückgegeben
werden können. Die
Anwendung kann
über den
Ausführungskontext
eine höhere Grenze
festlegen. Die
absolute maximale
Größe erzwingt den
Maximalwert auch
für Anwendungen,
die den
Standardwert nicht
berücksichtigen. Die
Beschränkung für
diese Grenze liegt
bei 1.000.000.
Workflowgrenzen
Die folgende Tabelle enthält die empfohlenen Richtlinien für Workflows.
Grenze
Maximalwert
Grenztyp
Schwellenwert für
Workflowverschiebung
15
Schwellenwert 15 ist die maximale
Anzahl von
Workflows, die
gleichzeitig für eine
114
Hinweise
Grenze
Maximalwert
Grenztyp
Hinweise
Inhaltdatenbank
ausgeführt werden
dürfen, abgesehen
von Instanzen, die im
Timerdienst
ausgeführt werden.
Wird dieser
Schwellenwert
erreicht, werden
neue Anforderungen
für die Aktivierung
von Workflows in die
Warteschlange
gestellt, um später
vom
Workflowtimerdienst
ausgeführt zu
werden. Sobald die
Ausführung ohne
Zeitgeber beendet
ist, werden neue
Anforderungen auf
diesen
Schwellenwert
angerechnet. Diese
Grenze kann mithilfe
des Windows
PowerShell-Cmdlets
Set-SPFarmConfig
konfiguriert werden.
Weitere
Informationen finden
Sie unter SetSPFarmConfig.
Hinweis: Diese
Grenze bezieht sich
nicht auf die
Gesamtanzahl von
Workflowinstanzen,
die ausgeführt
werden können,
sondern es handelt
sich um die Anzahl
der Instanzen, die
verarbeitet werden.
Durch das
Heraufsetzen dieser
Grenze steigt der
115
Grenze
Maximalwert
Grenztyp
Hinweise
Durchsatz beim
Starten und Beenden
von
Workflowaufgaben
ebenso wie die Last
für Inhaltsdatenbank
und
Systemressourcen.
100
Batchgröße des
Workflowzeitgebers
Schwellenwert Die Anzahl der
Ereignisse, die bei
jeder Ausführung des
WorkflowZeitgeberauftrags
aufgenommen und
an Workflows
übermittelt werden.
Dieser Wert kann
mithilfe von Windows
PowerShell
konfiguriert werden.
Um zusätzliche
Ereignisse zu
ermöglichen, können
Sie zusätzliche
Instanzen des
Microsoft SharePoint
Foundation Workflowtimerdiensts
ausführen.
Grenzen für Terminologiespeicher (Datenbank) für verwaltete
Metadaten
Die folgende Tabelle enthält die empfohlenen Richtlinien für Terminologiespeicher
verwalteter Metadaten.
Grenze
Maximalwert
Maximale Anzahl der 7
Ebenen
geschachtelter
Ausdrücke in einem
Terminologiespeicher
Grenztyp
Hinweise
Unterstützt Ausdrücke in einem
Ausdruckssatz lassen sich
hierarchisch darstellen. Ein
Ausdruckssatz kann bis zu
sieben Ausdrucksebenen (ein
übergeordneter Ausdruck mit
sechs Schachtelungsebenen
darunter) umfassen.
116
Grenze
Maximalwert
Grenztyp
Hinweise
Maximale Anzahl von 1.000
Ausdruckssätzen in
einem
Terminologiespeicher
Unterstützt Ein Terminologiespeicher kann
bis zu 1.000 Ausdruckssätze
beinhalten.
Maximale Anzahl von 30.000
Ausdrücken in einem
Ausdruckssatz
Unterstützt 30.000 ist die maximale Anzahl
von Ausdrücken in einem
Ausdruckssatz.
Hinweis:
Zusätzliche Bezeichnungen für
einen Ausdruck, beispielsweise
Synonyme und Übersetzungen,
gelten nicht als separate
Ausdrücke.
Gesamtanzahl von
1.000.000
Elementen in einem
Terminologiespeicher
Unterstützt Ein Element ist entweder ein
Ausdruck oder ein
Ausdruckssatz. Die
Gesamtanzahl von Ausdrücken
und Ausdruckssätzen kann
1.000.000 nicht übersteigen.
Zusätzliche Bezeichnungen für
einen Ausdruck, beispielsweise
Synonyme und Übersetzungen,
gelten nicht als separate
Ausdrücke.
Hinweis:
Ein Terminologiespeicher kann
nicht die maximale Anzahl von
Ausdruckssätzen und die
maximale Anzahl von
Ausdrücken gleichzeitig
enthalten.
Grenzen für Visio Services
Die folgende Tabelle enthält die empfohlenen Richtlinien für Instanzen von Visio Services
in Microsoft SharePoint Server 2010.
117
Grenze
Maximalwert
Grenztyp
Dateigröße von
VisioWebzeichnungen
50 MB
Schwellenwert Visio Services verfügt über eine
Konfigurationseinstellung, mit
deren Hilfe ein Administrator die
maximale Größe von
Webzeichnungen ändern kann,
die Visio verarbeitet.
Größere Dateien haben folgende
Nebeneffekte:
 Höherer Speicherbedarf von
Visio Services.
Visio-Timeout für 120 Sekunden
die Neuberechnung
von VisioWebzeichnungen
Hinweise

Höhere CPU-Auslastung.

Weniger
Anwendungsserveranforderu
ngen pro Sekunde.

Höhere durchschnittliche
Wartezeit.

Höhere SharePointFarmnetzwerklast.
Schwellenwert Visio Services verfügt über eine
Konfigurationseinstellung, mit
deren Hilfe ein Administrator die
maximale Zeitdauer ändern kann,
die für die Neuberechnung einer
Zeichnung nach einer
Datenaktualisierung aufgewendet
werden kann.
Ein höherer Timeout für die
Neuberechnung hat folgende
Auswirkungen:
 Geringere Verfügbarkeit von
CPU und Arbeitsspeicher.


Weniger
Anwendungsanforderungen
pro Sekunde.
Höhere durchschnittliche
Wartezeit für alle Dokumente.
Ein niedrigerer Timeout für die
Neuberechnung hat folgende
Auswirkungen:
 Geringere Komplexität der
Diagramme, die angezeigt
118
Grenze
Maximalwert
Grenztyp
Hinweise
werden können.

Mehr Anforderungen pro
Sekunde.

Niedrigere durchschnittliche
Wartezeit für alle Dokumente.
Minimales
Minimales
Cachealter für Visio Cachealter: 0 bis
Services (mit Daten 24 Std.
verbundene
Diagramme)
Schwellenwert Das minimale Cachealter gilt für
Diagramme, die mit Daten
verbunden sind. Es bestimmt den
frühesten Zeitpunkt, an dem das
aktuelle Diagramm aus dem
Cache entfernt werden kann.
Das Festlegen des minimalen
Cachealters auf einen sehr
niedrigen Wert führt zu einem
geringeren Durchsatz und einer
höheren Wartezeit, weil durch die
Außerkraftsetzung des Caches
Visio zu häufig gezwungen ist,
Neuberechnungen
durchzuführen, und die
Verfügbarkeit von CPU und
Arbeitsspeicher abnimmt.
Maximales
Maximales
Cachealter für Visio Cachealter: 0 bis
Services (nicht mit 24 Std.
Daten verbundene
Diagramme)
Schwellenwert Das maximale Cachealter gilt für
Diagramme, die nicht mit Daten
verbunden sind. Es bestimmt, wie
lange das aktuelle Diagramm im
Arbeitsspeicher verbleibt.
Durch das Erhöhen des
maximalen Cachealters nimmt die
Wartezeit für häufig angeforderte
Zeichnungen ab.
Das Festlegen des maximalen
Cachealters auf einen sehr hohen
Wert führt jedoch zu einer
längeren Wartezeit und reduziert
den Durchsatz für nicht
zwischengespeicherte Elemente,
da die bereits im Cache
befindlichen Elemente den
verfügbaren Arbeitsspeicher
belegen.
119
Grenzen für PerformancePoint Services
Die folgende Tabelle enthält die empfohlenen Richtlinien für PerformancePoint Services
in Microsoft SharePoint Server 2010.
Grenze
Maximalwert
Grenztyp
Zellen
1.000.000 pro Abfrage an
Excel ServicesDatenquelle
Beschränkung Eine
PerformancePointScorecard, die
eine Excel
ServicesDatenquelle
aufruft, unterliegt
einer Grenze von
höchstens
1.000.000 Zellen
pro Abfrage.
Spalten und Zeilen
15 Spalten mal 60.000
Zeilen
Schwellenwert Die maximale
Anzahl von
Spalten und Zeilen
beim Rendern
eines
PerformancePointDashboardobjekts,
das eine Microsoft
ExcelArbeitsmappe als
Datenquelle
verwendet. Die
Anzahl der Zeilen
kann sich je nach
Anzahl der
Spalten ändern.
Abfrage einer SharePoint- 15 Spalten mal 5.000
Liste
Zeilen
120
Unterstützt
Hinweise
Die maximale
Anzahl von
Spalten und Zeilen
beim Rendern
eines
PerformancePointDashboardobjekts,
das eine
SharePoint-Liste
als Datenquelle
verwendet. Die
Anzahl der Zeilen
kann sich je nach
Anzahl der
Grenze
Maximalwert
Grenztyp
Hinweise
Spalten ändern.
Abfrage einer SQL Server - 15 Spalten mal 20.000
Datenquelle
Zeilen
Unterstützt
Die maximale
Anzahl von
Spalten und Zeilen
beim Rendern
eines
PerformancePointDashboardobjekts,
das eine SQL
Server-Tabelle als
Datenquelle
verwendet. Die
Anzahl der Zeilen
kann sich je nach
Anzahl der
Spalten ändern.
Grenzen für Word Automation Services
Die folgende Tabelle enthält die empfohlenen Richtlinien für Word Automation Services.
Grenze
Maximalwert
Grenztyp
Größe der
Eingabedatei
512 MB
Beschränku Die maximale Dateigröße, die von
ng
Word Automation Services
verarbeitet werden kann.
Häufigkeit, mit der
Konvertierungen
gestartet werden
(Minuten)
Eine Minute
(empfohlen)
Schwellenw Diese Einstellung bestimmt, wie
ert
häufig der Word Automation
Services-Zeitgeberauftrag
ausgeführt wird. Eine niedrigere
Zahl führt dazu, dass der
Zeitgeberauftrag schneller
ausgeführt wird. Tests haben
gezeigt, dass es am besten ist,
den Zeitgeberauftrag einmal pro
Minute auszuführen.
Anzahl der
Konvertierungen,
die pro
Konvertierungsproz
ess gestartet
werden
Schwellenw
Für PDF/XPSAusgabeformate: 30 ert
x M, für alle anderen
Ausgabeformate: 72
x M, wobei M der
Wert der Häufigkeit
ist, mit der
Konvertierungen
gestartet werden
15 Minuten
(Standard)
59 Minuten
(Beschränkung)
121
Hinweise
Die Anzahl der zu startenden
Konvertierungen wirkt sich auf den
Durchsatz von Word Automation
Services aus.
Werden hierfür höhere Werte
festgelegt als empfohlen, kann es
zeitweise zu Fehlern bei einigen
Konvertierungselementen sowie
zum Ablauf von
Grenze
Maximalwert
Grenztyp
(Minuten)
Hinweise
Benutzerberechtigungen kommen.
Benutzerberechtigungen laufen 24
Stunden nach Start eines
Konvertierungsauftrags ab.
100.000
Größe des
Unterstützt Ein Konvertierungsauftrag
beinhaltet ein oder mehrere
Konvertierungsauftr Konvertierungselem
ente
Konvertierungselemente, von
ags
denen jedes eine Konvertierung
darstellt, die für eine Eingabedatei
in SharePoint ausgeführt wird.
Beim Starten eines
Konvertierungsauftrags (mithilfe
der ConversionJob.StartMethode) werden der
Konvertierungsauftrag und alle
Konvertierungselemente an einen
Anwendungsserver übertragen,
der den Auftrag dann in der Word
Automation Services-Datenbank
speichert. Eine große Anzahl von
Konvertierungselementen führt zu
einer längeren Ausführungszeit
der Start-Methode und einer
größeren Anzahl von Bytes, die an
den Anwendungsserver
übertragen werden.
Aktive
N-1, wobei N die
Schwellenw
Konvertierungsproz Anzahl der
ert
esse insgesamt
Prozessorkerne auf
den einzelnen
Anwendungsservern
ist
Ein aktiver Konvertierungsprozess
kann einen Prozessorkern
beanspruchen. Kunden sollten
deshalb nicht mehr
Konvertierungsprozesse
ausführen, als sich
Prozessorkerne auf den
Anwendungsservern befinden.
Sie sollten stets einen Kern für die
Verwendung durch den
Konvertierungszeitgeberauftrag
und SharePoint übrig lassen.
Zwei Millionen
Größe der Word
Unterstützt Word Automation Services
Konvertierungselem
unterhält eine beständige
Automation
Services-Datenbank ente
Warteschlange mit
Konvertierungselementen in der
Datenbank. Jede
Konvertierungsanforderung
generiert einen oder mehrere
Datensätze.
122
Grenze
Maximalwert
Grenztyp
Hinweise
Word Automation Services löscht
Datensätze nicht automatisch aus
der Datenbank, sodass die
Datenbank ohne Wartung endlos
wachsen kann. Administratoren
können Konvertierungsaufträge
mithilfe des Windows PowerShellCmdlets RemoveSPWordConversionServiceJob
History manuell entfernen.
Weitere Informationen finden Sie
unter RemoveSPWordConversionServiceJobHis
tory.
Grenzen für SharePoint Workspace
Die folgende Tabelle enthält die empfohlenen Richtlinien für Microsoft SharePoint
Workspace 2010.
Grenze
Maximalwert
Grenztyp
SharePoint WorkspaceSynchronisierung
30.000 Elemente pro Liste
Beschränkung SharePoint
Workspace
synchronisiert
keine Listen,
die über
30.000
Elemente
beinhalten.
Diese
Beschränkung
besteht, weil
das
Herunterladen
einer Liste mit
über 30.000
Elementen
sehr lange
dauert und
viele
Ressourcen
in Anspruch
nimmt.
SharePoint WorkspaceSynchronisierung
Grenze von 1.800
Dokumenten in SharePoint
Workspace
Beschränkung Benutzer
werden bei
mehr als 500
123
Hinweise
Grenze
Maximalwert
Grenztyp
Hinweise
Dokumenten
in SharePoint
Workspace
gewarnt, aber
sie können
weiter
Dokumente
hinzufügen.
Grenzen für OneNote
Die folgende Tabelle enthält die empfohlenen Richtlinien für Microsoft OneNote-Dienste.
Grenze
Maximalwert
Grenztyp
Anzahl der Abschnitte und
Abschnittsgruppen in
einem OneNote-Notizbuch
(in SharePoint)
Siehe Grenze für
"Dokumente"
unter "Listen- und
Bibliotheksgrenze
n"
Jeder Abschnitt zählt als ein
Ordner und ein Dokument
in der Liste. Jede
Abschnittsgruppe zählt als
ein Ordner und ein
Dokument in der Liste.
Maximale Größe eines
Abschnitts
Siehe Grenze für
"Dateigröße" unter
"Listen- und
Bibliotheksgrenze
n"
Dieser Maximalwert schließt
alle Bilder, eingebetteten
Dateien und XPSAusdrucke an OneNote
aus, die größer sind als 100
KB. Bilder und eingebettete
Dateien, die größer sind als
100 KB, werden in ihre
eigenen Binärdateien
aufgespalten. Das bedeutet,
dass ein Abschnitt mit 100
KB eingegebener Daten
und vier eingebetteten
Word-Dokumenten mit
jeweils 1 MB als 100-KBAbschnitt gilt.
Maximale Größe eines
Bildes, einer eingebetteten
Datei und eines OneNoteXPS-Ausdrucks in einem
OneNote-Abschnitt.
Siehe Grenze für
"Dateigröße" unter
"Listen- und
Bibliotheksgrenze
n"
Jedes Element wird als
separate Binärdatei
gespeichert und unterliegt
deshalb den Grenzen für
die Dateigröße. Jeder
Druckvorgang an OneNote
führt zu einer binären XPSAusdruckdatei, und zwar
auch dann, wenn der
124
Hinweise
Grenze
Maximalwert
Grenztyp
Hinweise
Ausdruck mehrere Seiten
umfasst.
Die maximale Größe aller
Bilder, eingebetteten
Dateien und XPSAusdrucke auf einer
OneNote-Seite.
Die
Standardgrenze
ist doppelt so
hoch wie die
Grenze für die
Dateigröße.
Schwellenwe Dies gilt für eingebettete
rt
Inhalte auf einer OneNoteSeite, nicht in einem
Abschnitt oder Notizbuch.
Benutzern wird in diesem
Fall der folgende Fehler in
OneNote angezeigt:
"jerrcStorageUrl_HotTableF
ull (0xE0000794)". Benutzer
können dies umgehen,
indem sie eingebetteten
Inhalt in verschiedene
Seiten aufspalten und
vorherigen Versionen der
Seite löschen. Wenn
Benutzer diesen Wert
(“Maximale Größe aktueller
Tabellen”) anpassen
müssen, beträgt der
effektive Grenzwert die
Hälfte des von ihnen
festgelegten Grenzwerts
(bei Angabe einer
maximalen Größe aktueller
Tabellen von 400 MB
bedeutet dies
beispielsweise, dass die
maximale Größe des
gesamten eingebetteten
Inhalts auf einer Seite auf
200 MB beschränkt ist).
Zusammenführungsvorgän Einer pro
Beschränkun OneNote führt Änderungen
Prozessorkern pro g
ge
von mehreren Benutzern
Webserver
zusammen, die gemeinsam
ein Notizbuch erstellen. Ist
kein Prozessorkern zum
Ausführen einer
Zusammenführung
vorhanden, wird stattdessen
eine Konfliktseite generiert,
die den Benutzer zwingt,
die Zusammenführung
manuell durchzuführen.
Diese Grenze ist
125
Grenze
Maximalwert
Grenztyp
Hinweise
unabhängig davon gültig, ob
OneNote als
Clientanwendung oder als
Microsoft Office Web Apps
ausgeführt wird.
Grenzen für Office-Webanwendungsdienste
Die folgende Tabelle enthält die empfohlenen Richtlinien für Office Web Apps. OfficeClientanwendungsgrenzen gelten auch, wenn eine Anwendung als Webanwendung
ausgeführt wird.
Grenze
Maximalwert
Grenztyp
Cachegröße
100 GB
Schwellenwert Verfügbarer
Speicher zum
Rendern von
Dokumenten, die
im Rahmen einer
Inhaltsdatenbank
erstellt werden.
Standardmäßig
steht zum Rendern
von Dokumenten
ein Cache von 100
GB zur Verfügung.
Sie sollten den
verfügbaren Cache
nicht erhöhen.
Renderings
Eins pro Dokument pro
Sekunde pro
Prozessorkern pro
Anwendungsserver
(maximal acht
Prozessorkerne)
Beschränkung Dies ist die
gemessene
durchschnittliche
Anzahl von
Renderings, die
über einen
gewissen Zeitraum
hinweg für
"typische"
Dokumente auf
dem
Anwendungsserver
durchgeführt
werden kann.
Grenzen für Project Server
126
Hinweise
Die folgende Tabelle enthält die empfohlenen Richtlinien für Microsoft Project Server.
Weitere Informationen zur Planung für Project Server finden Sie unter Planning and
architecture for Project Server 2010.
Grenze
Maximalwert
Grenztyp
Hinweise
Ende der Projektzeit
Datum: 31.12.2049
Beschränkung Project-Pläne
können nicht
über das
Datum
31.12.2049
hinausgehen.
Lieferumfang pro Projektplan 1.500 Lieferumfänge
Beschränkung Project-Pläne
können nicht
mehr als
1.500
Lieferumfänge
enthalten.
Anzahl der Felder in einer
Ansicht
Beschränkung Benutzer
können einer
Ansicht, die
sie in Project
Web App
definiert
haben, nicht
mehr als 256
Felder
hinzufügen.
256
Anzahl der Klauseln in einem 50
Ansichtsfilter
Beschränkung Ein Benutzer
kann einer
Ansicht
keinen Filter
mit mehr als
50 Klauseln
hinzufügen.
127
Performance and capacity technical case
studies (SharePoint Server 2010) (in
englischer Sprache)
This section contains technical case studies that describe specific deployments of
Microsoft SharePoint Server 2010. Compare the scenarios in these documents to your
planned workload and usage characteristics. If your planned design is similar, you can
use the documented deployment as a starting point for your own installation.
These articles include information about environments, such as:
 Environment specifications, such as hardware, farm topology, and configuration

The workload used for data generation, including the number and class of users, and
farm usage characteristics

Farm dataset, including database contents, Search indexes, and external data
sources

Health and performance data specific to the environment

Performance data and recommendations for how to determine the hardware,
topology, and configuration you need to deploy a similar environment, and how to
optimize your environment for appropriate capacity and performance characteristics
Before reading these articles, it is important that you understand the key concepts behind
capacity management in SharePoint Server 2010. For more information, see Capacity
management and sizing for SharePoint Server 2010 (in englischer Sprache).
In this section:
 Publishing


Microsoft SharePoint Server 2010-Veröffentlichungsumgebung mit
Unternehmensintranet: Technische Fallstudie
Describes the published intranet environment used by employees at Microsoft.
Enterprise Intranet Collaboration


Enterprise intranet collaboration environment technical case study (SharePoint
Server 2010) (in englischer Sprache)
Describes an environment that hosts mission-critical team sites and publishing
portals for internal organizations, teams, and projects.
 Enterprise intranet collaboration environment lab study (SharePoint Server 2010)
(in englischer Sprache)
Describes lab testing performed on a similar environment to the enterprise
Intranet collaboration environment.
Departmental Collaboration

Departmental collaboration environment technical case study (SharePoint Server
2010) (in englischer Sprache)
128

Describes a departmental collaboration environment used by employees of one
department inside Microsoft.
 Divisional portal environment lab study (SharePoint Server 2010) (in englischer
Sprache)
Describes lab testing performed on a similar environment to the departmental
collaboration environment.
Social


Social environment technical case study (SharePoint Server 2010) (in englischer
Sprache)
Describes an environment that hosts My Sites that present employee information
to the wider organization. The environment serves as a central location for
personal sites and shared documents.
Microsoft SharePoint Server 2010 social environment: Lab study
Provides guidance on performance and capacity planning for a My Site and
social computing portal based on SharePoint Server 2010.
129
Microsoft SharePoint Server 2010Veröffentlichungsumgebung mit
Unternehmensintranet: Technische
Fallstudie
In diesem Dokument wird eine spezielle Bereitstellung von Microsoft SharePoint Server
2010 beschrieben. Hierzu gehören folgende Elemente:
 Spezifikationen für die Umgebung der technischen Fallstudie, wie z. B. Hardware,
Farmtopologie und Konfiguration.

Die Arbeitsauslastung, die die Anzahl und die Art der Benutzer oder Clients
beinhaltet, sowie die Nutzungsmerkmale für die Umgebung.

Farmdataset der technischen Fallstudie, einschließlich Datenbankinhalten und
Suchindizes.
 Integritäts- und Leistungsdaten speziell für die Umgebung.
Inhalt dieses Artikels:
 Vorabinformationen

Einführung in diese Umgebung

Spezifikationen

Arbeitsauslastung

Dataset

Integritäts- und Leistungsdaten
Vorabinformationen
Vor der Lektüre dieses Dokuments sollten Sie unbedingt mit den wichtigsten Konzepten
der Kapazitätsverwaltung in SharePoint Server 2010 vertraut sein. In der folgenden
Dokumentation finden Sie Informationen zur empfohlenen Vorgehensweise bei der
Kapazitätsverwaltung sowie Kontextinformationen für die effiziente Verwendung der
Angaben in diesem Dokument. Außerdem werden die in diesem Dokument verwendeten
Begriffe definiert.
Weitere konzeptionelle Informationen zu Leistung und Kapazität, die beim Verständnis
des Kontexts der Daten in dieser technischen Fallstudie hilfreich sein können, finden Sie
in den folgenden Dokumenten:
 Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht)

SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und grenzen
130
Einführung in diese Umgebung
In diesem Whitepaper wird eine SharePoint Server 2010-Umgebung bei Microsoft
beschrieben. Vergleichen Sie anhand dieses Dokuments Ihre geplanten Auslastungsund Nutzungsmerkmale. Wenn Ihr geplanter Entwurf ähnlich ist, können Sie die hier
beschriebene Bereitstellung als Ausgangspunkt für Ihre eigene Installation verwenden.
Dieses Dokument enthält Folgendes:
 Spezifikationen, einschließlich Hardware, Topologie und Konfiguration.

Arbeitsauslastung, also die Anforderungen an die Farm, einschließlich der Anzahl
von Benutzern und der Nutzungsmerkmale.

Dataset, einschließlich Datenbankgrößen.
 Integritäts- und Leistungsdaten speziell für die Umgebung.
Dieses Dokument ist Teil einer Reihe von Performance and capacity technical case
studies (SharePoint Server 2010) (in englischer Sprache) zu SharePoint-Umgebungen
bei Microsoft.
Bei
der in diesem Dokument beschriebenen SharePoint Server 2010-Umgebung handelt es
sich um eine Produktionsumgebung in einem auf verschiedene Standorte verteilten
Großunternehmen. Mitarbeiter zeigen verschiedene Inhalte an, wie z. B. Nachrichten,
technische Artikel, Mitarbeiterprofile, Dokumentation und Schulungsressourcen. Mithilfe
dieser Umgebung führen Mitarbeiter auch Suchabfragen für alle SharePointUmgebungen im Unternehmen aus. Mitarbeiter erhalten täglich E-Mails mit Links zu
Artikeln in der Umgebung, und viele Mitarbeiter legen diese Umgebung als Startseite im
Browser fest.
48.000 Einzelbenutzer besuchen die Umgebung an einem geschäftigen Tag und
generieren in Spitzenzeiten bis zu 345 Anforderungen pro Sekunde. Da es sich hierbei
um eine Intranetwebsite handelt, sind alle Benutzer authentifiziert. Inhalte werden zwar
mithilfe eines Modells mit einer einzelnen Umgebung und dem Autor vor Ort
veröffentlicht, aber das Veröffentlichungsverfahren der Umgebung gibt an, dass alle
Entwurfsinhalte nachts zu einem bestimmten Zeitpunkt mit geringer Auslastung
veröffentlicht werden.
In diesem Dokument wird die Veröffentlichungsumgebung des Unternehmensintranets an
einem typischen Tag beschrieben.
131
Spezifikationen
Dieser Abschnitt enthält ausführliche Informationen zur Hardware, Software, Topologie
und Konfiguration der Umgebung für die Fallstudie.
Hardware
Dieser Abschnitt enthält Informationen zu den in dieser Umgebung verwendeten
Servercomputern.
Hinweis:
Diese Umgebung wurde für Vorabversionsbuilds von SharePoint Server 2010 und
anderen Produkten skaliert. Deshalb weist die bereitgestellte Hardware eine höhere
Kapazität auf, als für die typischen Anforderungen dieser Umgebung erforderlich wäre.
Diese Hardware wird nur beschrieben, um zusätzlichen Kontext für diese Umgebung zu
liefern und als Ausgangspunkt für ähnliche Umgebungen zu dienen.
Sie müssen unbedingt Ihre eigene Kapazitätsverwaltung basierend auf den geplanten
Auslastungs- und Nutzungsmerkmalen vornehmen. Weitere Informationen zum
Kapazitätsverwaltungsprozess finden Sie unter Kapazitätsverwaltung und
Größengestaltung für SharePoint Server 2010 (Übersicht).
Webserver
Es gibt vier Webserver in der Farm, mit jeweils identischer Hardware. Mit drei Servern
werden Inhalte bereitgestellt, und der vierte Server ist ein dediziertes
Suchdurchforstungsziel.
Webserver
WFE1-4
Prozessor(en)
2 Quad-Core mit 2,33 GHz
RAM
32 GB
Betriebssystem
Windows Server 2008, 64-Bit
Größe des SharePoint-Laufwerks
300 GB
Anzahl der Netzwerkkarten
2
Geschwindigkeit der Netzwerkkarte
1 Gigabit
Authentifizierung
Windows NTLM
Lastenausgleichstyp
Hardwarelastenausgleich
Softwareversion
SharePoint Server 2010 (Vorabversion)
Lokal ausgeführte Dienste
Zentraladministration
Eingehende E-Mails von Microsoft
SharePoint Foundation
Microsoft SharePoint Foundation132
Webserver
WFE1-4
Webanwendung
Microsoft SharePoint FoundationWorkflowtimerdienst
Suchabfrage- und
Websiteeinstellungsdienst
SharePoint Server-Suche
Von einer Verbunddienstfarm genutzte
Dienste
Benutzerprofildienst
Web Analytics-Webdienst
Business Data Connectivity-Dienst
Verwalteter Metadatenwebdienst
Anwendungsserver
In der Farm sind keine Anwendungsserver vorhanden. Lokale Dienste werden auf den
Webservern gehostet. Andere Dienste werden von einer Verbunddienstfarm genutzt.
Datenbankserver
Es gibt einen SQL-Cluster mit zwei Datenbankservern, mit jeweils identischer Hardware.
Einer der Server ist aktiv, und der andere Server ist aus Redundanzgründen passiv.
Datenbankserver
DB1-2
Prozessor(en)
4 Quad-Core mit 2,4 GHz
RAM
32 GB
Betriebssystem
Windows Server 2008, 64-Bit
Speicherung und Geometrie
(1,25 TB * 6) + 3 TB
Datenträger 1-4: SQL-Daten
Datenträger 5: Protokolle
Datenträger 6: TempDB
Anzahl der Netzwerkkarten
2
Geschwindigkeit der Netzwerkkarte
1 Gigabit
Authentifizierung
Windows NTLM
Softwareversion
SQL Server 2008
Topologie
Das folgende Diagramm veranschaulicht die Topologie für diese Farm.
133
Konfiguration
134
In der folgenden Tabelle sind geänderte Einstellungen aufgeführt, die sich auf die
Leistung oder Kapazität in der Umgebung auswirken.
Einstellung
Wert
Websitesammlungsve Ein
rwaltung:
Ausgabecache der
Websitesammlung
Hinweise
Durch Aktivieren des Ausgabecaches wird die
Servereffizienz verbessert, indem Aufrufe von
häufig angeforderten Daten in der Datenbank
reduziert werden.
Cacheprofil für die
Websitesammlung
(auswählen)
Schreibern erlauben, zwischengespeicherten
Intranet
(Website für Inhalt anzuzeigen ist aktiviert, wodurch das
Standardverhalten außer Kraft gesetzt wird, dass
die
Zusammena Seiten von Benutzern mit
rbeit)
Bearbeitungsberechtigung nicht
zwischengespeichert werden.
Objektcache (Aus |
n MB)
Ein –
500 MB
Die Standardeinstellung ist 100 MB. Durch
Anheben des Werts für diese Einstellung können
zusätzliche Daten im Arbeitsspeicher des FrontEnd-Webservers gespeichert werden.
Verwendungsdienst: 5 Tage
Ablaufverfolgungsproto
koll – Anzahl der Tage,
die Protokolldateien
gespeichert werden
(Standard: 14 Tage)
Die Standardeinstellung ist 14 Tage. Durch Senken
des Werts für diese Einstellung kann auf dem
Server, auf dem die Protokolldateien gespeichert
werden, Speicherplatz gespart werden.
Schwellenwert für
1 Sekunde
Abfrageprotokollierun
g:
Microsoft SharePoint
Foundation-Datenbank
– 1 Sekunde für
"QueryLoggingThreshol
d" konfigurieren
Die Standardeinstellung ist 5 Sekunden. Durch
Senken des Werts für diese Einstellung kann
Bandbreite und CPU auf dem Datenbankserver
gespart werden.
Datenbankserver –
Standardinstanz:
Max. Grad an
Parallelität
Der Standardwert ist 0. Um eine optimale Leistung
sicherzustellen, wird empfohlen, die Option Max.
Grad an Parallelität für Datenbankserver, die
SharePoint Server 2010-Datenbanken hosten, auf
1 festzulegen. Weitere Informationen zum
Festlegen von Max. Grad an Parallelität finden Sie
unter max degree of parallelism
Option(http://go.microsoft.com/fwlink/?linkid=18
9030&clcid=0x407).
1
135
Arbeitsauslastung
In diesem Abschnitt wird die Arbeitsauslastung beschrieben, also die Anforderungen an
die Farm, einschließlich der Anzahl von Benutzern und der Nutzungsmerkmale.
Arbeitsauslastungsmerkmale
Wert
Durchschn. Anforderungen pro Sekunde
100
Durchschn. Anforderungen pro Sekunde zu 226
Spitzenzeiten (11–15 Uhr)
Gesamtanzahl eindeutiger Benutzer pro Tag 33.580
Durchschnittliche Anzahl gleichzeitiger
Benutzer
172
Maximale Anzahl gleichzeitiger Benutzer
376
Gesamtanzahl der Anforderungen pro Tag
3.800.000
In der folgenden Tabelle wird die Anzahl von Anforderungen für jeden Benutzer-Agent
angezeigt.
Benutzer-Agent
Anforderungen
Prozentsatz
Browser
3.261.563
97,09 %
DAV
2.418
0,07 %
Suche (Durchforsten)
92.322
2,75 %
OneNote
1.628
0,05 %
Outlook
961
0,03 %
Word
449
0,01 %
Dataset
In diesem Abschnitt wird das Farmdataset der Fallstudie, einschließlich
Datenbankinhalten und Suchindizes, beschrieben.
Datasetmerkmale
Wert
Datenbankgröße (kombiniert)
49,9 GB
BLOB-Größe
22,2 GB
136
Datasetmerkmale
Wert
Anzahl der Inhaltsdatenbanken
3
Anzahl der Webanwendungen
3
Anzahl der Websitesammlungen
4
Anzahl der Websites
797
Suchindexgröße (Anzahl der Elemente)
275.000
Integritäts- und Leistungsdaten
Dieser Abschnitt enthält Integritäts- und Leistungsdaten speziell für die Umgebung der
Fallstudie.
Allgemeine Leistungsindikatoren
Metrik
Wert
Verfügbarkeit (Betriebszeit)
99,95 %
Fehlerrate
0,05 %
Durchschn. belegter Arbeitsspeicher
1,08 GB
Maximal belegter Arbeitsspeicher
2,60 GB
Suchdurchforstungen in % des
Datenverkehrs (Suchclientanforderungen /
Gesamtanforderungen)
6%
ASP.NET-Anforderungen in Warteschlange 0,00
In den folgenden Diagrammen sind die durchschnittliche CPU-Auslastung und die
Wartezeit für diese Umgebung dargestellt.
137
In diesem Dokument wird die Wartezeit in vier Kategorien unterteilt. In der Regel wird das
50. Quantil der Wartezeit zum Messen der Reaktionszeit des Servers verwendet. Dies
bedeutet, dass die Hälfte der Anforderungen innerhalb der Reaktionszeit ausgeführt
werden. Mit dem 95. Quantil der Wartezeit werden normalerweise Spitzen bei den
Reaktionszeiten des Servers gemessen. Dies bedeutet, dass 95 % der Anforderungen
138
innerhalb der Reaktionszeit ausgeführt werden und demnach bei 5 % der Anforderungen
langsamere Reaktionszeiten auftreten.
Datenbank-Leistungsindikatoren
Achten Sie beim Interpretieren von Datenbankstatistiken für diese
Unternehmensveröffentlichungsumgebung darauf, dass die meisten Besucher über
Leseberechtigung verfügen.
Metrik
Wert
Verhältnis von Lese-/Schreibvorgängen (E/A 99,999 : 0,001
pro Datenbank)
Durchschnittliche Länge der
Datenträgerwarteschlange
0,35
Länge der Datenträgerwarteschlange:
Lesevorgänge
34
Länge der Datenträgerwarteschlange:
Schreibvorgänge
2,5
Lesevorgänge/s
131,33
Schreibvorgänge/s
278,33
SQL-Kompilierungen/s
2,36
SQL-Neukompilierungen/s
94,80
SQL-Sperren: Durchschnittliche Wartezeit
0 ms
SQL-Sperren: Sperrenwartezeit
0 ms
SQL-Sperren: Deadlocks/s
0
SQL-Latches: Durchschnittliche Wartezeit
0,25 ms
SQL-Cachetrefferrate
>99 %
139
Enterprise intranet collaboration
environment technical case study
(SharePoint Server 2010) (in englischer
Sprache)
This article describes a specific deployment of Microsoft SharePoint Server 2010, that
includes the following:
 Technical case study environment specifications, such as hardware, farm topology
and configuration.

The workload, that includes the number, and types, of users or clients, and
environment usage characteristics.

Technical case study farm dataset, that includes database contents and search
indexes.
 Health and performance data that is specific to the environment.
In this article:
 Prerequisite information

Introduction to this environment

Specifications

Workload

Dataset

Health and Performance Data
Prerequisite information
Before reading this document, make sure that you understand the key concepts behind
SharePoint Server 2010 capacity management. The following documentation will help
you learn about the recommended approach to capacity management and provide
context for helping you understand how to make effective use of the information in this
document, and also define the terms used throughout this document.
For more conceptual information about performance and capacity that you might find
valuable in understanding the context of the data in this technical case study, see the
following documents:
 Capacity management and sizing for SharePoint Server 2010 (in englischer Sprache)

SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und grenzen
140
Introduction to this environment
This white paper describes an actual SharePoint Server 2010 environment at Microsoft.
Use this document to compare to your planned workload and usage characteristics. If
your planned design is similar, you can use the deployment described here as a starting
point for your own installation.
This document includes the following:
 Specifications, which include hardware, topology, and configuration.

Workload, which is the demand on the farm that includes the number of users, and
the usage characteristics.

Dataset that includes database sizes.
 Health and performance data that is specific to the environment.
This document is part of a series of Performance and capacity technical case studies
(SharePoint Server 2010) (in englischer Sprache) about SharePoint environments at
Microsoft.
The
SharePoint environment described in this document is a production environment at a
large, geographically distributed company. The environment hosts very important team
sites and publishing portals for internal teams for enterprise collaboration, organizations,
teams, and projects. Sites created in this environment are used as communication
portals, applications for business solutions, and general collaboration. Self-service site
creation is used to provision site collections. Custom code is not permitted.
As many as 88,900 unique users visit the environment on a busy day, generating up to
669 requests per second (RPS) during peak hours. Because this is an intranet site, all
users are authenticated.
The information that is provided in this document reflects the enterprise intranet
publishing environment on a typical day.
Specifications
This section provides detailed information about the hardware, software, topology, and
configuration of the case study environment.
Hardware
141
This section provides details about the server computers that were used in this
environment.
Hinweis:
This environment is scaled to accommodate pre-release builds of SharePoint Server
2010 and other products. Hence, the hardware deployed has larger capacity than
necessary to serve the demand typically experienced by this environment. This hardware
is described only to provide additional context for this environment and serve as a
starting point for similar environments.
It is important to conduct your own capacity management based on your planned
workload and usage characteristics. For more information about the capacity
management process, see Capacity management and sizing for SharePoint Server 2010
(in englischer Sprache).
Web Servers
There are four Web servers in the farm, each with identical hardware. Three serve
content, and the fourth is a dedicated search crawl target.
Web Server
WFE1-4
Processor(s)
2 quad core @ 2.33 GHz
RAM
32 GB
OS
Windows Server® 2008, 64 bit
Size of the SharePoint drive
205 GB
Number of network adapters
2
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Load balancer type
Hardware load balancing
Software version
SharePoint Server 2010 (pre-release
version)
Services running locally
Central Administration
Microsoft SharePoint Foundation Incoming
E-Mail
Microsoft SharePoint Foundation Web
Application
Microsoft SharePoint Foundation Workflow
Timer Service
Search Query and Site Settings Service
SharePoint Server Search
142
Web Server
WFE1-4
Services consumed from a federated
Services farm
User Profile Service
Web Analytics Web Service
Business Data Connectivity Service
Managed Metadata Web Service
Application Server
There are four application servers in the farm, each with identical hardware.
Application Server
APP1-4
Processor(s)
4 six core @ 2.40 GHz
RAM
64 GB
OS
Windows Server 2008, 64 bit
Size of the SharePoint drive
300 GB
Number of network adapters
1
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Load balancer type
Hardware load balancing
Software version
SharePoint Server 2010 (pre-release
version)
Services running locally
Office Web Apps
Excel
PowerPoint
Secure Store
Usage and Health
State Service
Database Servers
There is a SQL cluster with 2 database servers, each with identical hardware, one of the
servers is active and the other is passive for redundancy.
Database Server
DB1-2
Processor(s)
4 quad core @ 2.4 GHz
RAM
32 GB
143
Database Server
DB1-2
OS
Windows Server 2008, 64-bit
Storage and geometry
(1.25 TB * 7) + 3 TB
Disk 1-4: SQL Data
Disk 5: Logs
Disk 6: TempDB
Number of network adapters
2
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Software version
SQL Server 2008
Topology
The following diagram shows the topology for this farm.
144
Configuration
145
The following table enumerates settings that were changed that affect performance or
capacity in the environment.
Setting
Value
Notes
Usage Service
5 days The default is 14 days. Lowering this setting can save
disk space on the server where the log files are
Trace Log – days to store
stored.
log files (default: 14 days)
QueryLoggingThreshold 1
The default is 5 seconds. Lowering this setting can
second
save bandwidth and CPU on the database server.
SharePoint Foundation
Database – change
QueryLoggingThreshold
to 1 second
1
Database Server –
Default Instance
Max degree of parallelism
The default is 0. To ensure optimal performance, we
strongly recommend that you set max degree of
parallelism to 1 for database servers that host
SharePoint Server 2010 databases. For more
information about how to set max degree of
parallelism, see max degree of parallelism
Option(http://go.microsoft.com/fwlink/?LinkId=189030).
Workload
This section describes the workload, which is the demand on the farm that includes the
number of users, and the usage characteristics.
Workload Characteristics
Value
Average Requests per Second (RPS)
157
Average RPS at peak time (11 AM-3 PM)
350
Total number of unique users per day
69,702
Average concurrent users
420
Maximum concurrent users
1,433
Total # of requests per day
18,866,527
This table shows the number of requests for each user agent.
User Agent
Requests
Percentage of
Total
Search (crawl)
6,384,488
47%
DAV
2,446,588
18%
146
User Agent
Requests
Percentage of
Total
Browser
730,139
5%
OneNote
665,334
5%
Office Web Applications
391,599
3%
SharePoint Designer
215,695
2%
Dataset
This section describes the case study farm dataset that includes database sizes and
Search indexes.
Dataset Characteristics
Value
Database size (combined)
7.5 TB
BLOB size
6.8 TB
Number of content databases
87
Number of Web applications
2
Number of site collections
34,423
Number of sites
101,598
Search index size (number of items)
23 million
Health and Performance Data
This section provides health and performance data that is specific to the Case Study
environment.
General Counters
Metric
Value
Availability (uptime)
99.1%
Failure Rate
0.9%
Average memory used
3.4 GB
Maximum memory used
16.1 GB
Search Crawl % of Traffic (Search client
requests / total requests)
47%
147
Metric
Value
ASP.NET Requests Queued
0.00
The following charts show the average CPU utilization and latency for this environment:
148
In this document, latency is divided into four categories. The 50th percentile latency is
typically used to measure the server‘s responsiveness. It means that half of the requests
are served within that response time. The 95th percentile latency is typically used to
measure spikes in server response times. It means that 95% of requests are served
within that response time, and therefore 5% of the requests experience slower response
times.
Database counters
Metric
Value
Read/Write Ratio (IO Per Database)
99.8 : 0.2
Average Disk queue length
2.3
Disk Queue Length: Reads
2
Disk Queue Length: Writes
0.3
Disk Reads/sec
131.33
Disk Writes/sec
278.33
SQL Compilations/second
9.9
SQL Re-compilations/second
0.07
SQL Locks: Average Wait Time
225 ms
SQL Locks: Lock Wait Time
507 ms
SQL Locks: Deadlocks Per Second
3.8
SQL Latches: Average Wait Time
14.3 ms
SQL Server: Buffer Cache Hit Ratio
74.3%
149
Enterprise intranet collaboration
environment lab study (SharePoint
Server 2010) (in englischer Sprache)
This article contains guidance on performance and capacity planning for an enterprise
intranet collaboration solution that is based on Microsoft SharePoint Server 2010. It
includes the following:
 Lab environment specifications, such as hardware, farm topology and configuration

Test farm dataset

Test results analysis which should help you determine the hardware, topology and
configuration that you must have to deploy a similar environment, and optimize your
environment for appropriate capacity and performance characteristics
In this article:
 Introduction to this environment

Glossary

Overview

Specifications

Results and Analysis
Introduction to this environment
This document provides guidance about scaling out and scaling up servers in a
SharePoint Server 2010 enterprise intranet collaboration solution, based on a testing
environment at Microsoft. Capacity planning informs decisions on purchasing hardware
and making system configurations to optimize your solution.
Different scenarios have different requirements. Therefore, it is important to supplement
this guidance with additional testing on your own hardware and in your own environment.
If your planned design and workload resembles the environment described in this
document, you can use this document to draw conclusions about scaling your
environment up and out.
This document includes the following:
 Specifications, which include hardware, topology, and configuration

The workload, which is the demand on the farm, includes the number of users, and
the usage characteristics

The dataset, such as database sizes

Test results and analysis for scaling out Web servers

Test results and analysis for scaling up Web servers

Test results and analysis for scaling out database servers
150

Comparison between Microsoft Office SharePoint Server 2007 and SharePoint
Server 2010 about throughput and effect on the web and database servers
The SharePoint Server 2010 environment described in this document is a lab
environment that mimics a production environment at a large company. The production
environment hosts very important team sites and publishing portals for internal teams for
enterprise collaboration, organizations, teams, and projects. Employees use that
production environment to track projects, collaborate on documents, and share
information within their organization. The environment includes a large amount of small
sites used for ad-hoc projects and small teams. For details about the production
environment, see Enterprise intranet collaboration environment technical case study
(SharePoint Server 2010) (in englischer Sprache).
Before reading this document, make sure that you understand the key concepts behind
capacity management in SharePoint Server 2010. The following documentation will help
you learn about the recommended approach to capacity management and provide
context for helping you understand how to make effective use of the information in this
document, and also define the terms used throughout this document.
 Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht)

SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und grenzen
Also, we encourage you to read the following:
 Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server
2010)
Glossary
There are some specialized terms that you will encounter in this document. Here are
some key terms and their definitions.
 RPS: Requests per second. The number of requests received by a farm or server in
one second. This is a common measurement of server and farm load.
Note that requests differ from page loads; each page contains several components,
each of which creates one or more requests when the page is loaded. Therefore, one
page load creates several requests. Typically, authentication checks and events
using insignificant resources are not counted in RPS measurements.
 Green Zone: This is the state at which the server can maintain the following set of
criteria:

The server-side latency for at least 75% of the requests is less than 1 second.

All servers have a CPU Utilization of less than 50%.
Hinweis:
Because this lab environment did not have an active search crawl running, the database
server was kept at 40% CPU Utilization or lower, to reserve 10% for the search crawl
load. This assumes Microsoft SQL Server Resource Governor is used in production to
limit Search crawl load to 10% CPU.


Failure rate is less than 0.01%.
Red Zone (Max): This is the state at which the server can maintain the following set
of criteria:
151

HTTP request throttling feature is enabled, but no 503 errors (Server Busy) are
returned.

Failure rate is less than 0. 1%.

The server-side latency is less than 3 seconds for at least 75% of the requests.

Database server CPU utilization is less than 80%, which allows for 10% to be
reserved for the Search crawl load, limited by using SQL Server Resource
Governor.

AxBxC (Graph notation): This is the number of Web servers, application servers,
and database servers respectively in a farm. For example, 8x1x2 means that this
environment has 8 Web servers, 1 application server, and 2 database servers.

MDF and LDF:
SQL Server physical files. For more information, see Files
and Filegroups Architecture.
Overview
This section provides an overview to our scaling approach, to the relationship between
this lab environment and a similar case study environment, and to our test methodology.
Scaling approach
This section describes the specific order that we recommend for scaling servers in your
environment, and is the same approach we took for scaling this lab environment. This
approach will enable you to find the best configuration for your workload, and can be
described as follows:
 First, we scaled out the Web servers. These were scaled out as far as possible under
the tested workload, until the database server became the bottleneck and was
unable to accommodate any more requests from the Web servers.

Second, we scaled out the database server by moving half of the content databases
to another database server. At this point, the Web servers were not creating
sufficient load on the database servers. Therefore, they were scaled out additionally.

In order to test scale up, we tried another option which is scaling up the Web servers
instead of scaling them out. Scaling out the Web servers is generally preferred over
scaling them up because scaling out provides better redundancy and availability.
Correlating the lab environment with a production environment
The lab environment outlined in this document is a smaller scale model of a production
environment at Microsoft, and although there are significant differences between the two
environments, it can be useful to examine them side by side because both are enterprise
collaboration environments where the patterns observed should be similar.
The lab environment contains a subset of the data from the production environment, and
also some modifications to the workload. This influences the test results with regard to
Web server memory usage, because the object cache on the production environment
receives a larger amount of hits on unique sites, and therefore uses more memory. The
lab environment also has less data, and most of it is cached in memory as opposed to
the production environment which carries over seven terabytes of data, so that the
database server on the production environment is required to perform more disk reads
than the database server in the lab environment. Similarly, the hardware that was used in
the lab environment is significantly different from the production environment it models,
152
because there is less demand on those resources. The lab environment relies on more
easily available hardware.
To get a better understanding of the differences between the environments, read the
Specifications section in this document, and compare it to the specifications in the
Enterprise intranet collaboration environment technical case study (SharePoint Server
2010) (in englischer Sprache).
Methodology and Test Notes
This document provides results from a test lab environment. Because this was a lab
environment and not a production environment, we were able to control certain factors to
show specific aspects of performance for this workload. In addition, certain elements of
the production environment, listed here, were left out of the lab environment to simplify
testing overhead. We do not recommend omitting these elements for production
environments.
 Between test runs, we modified only one variable at a time, to make it easy to
compare results between test runs.

The database servers that were used in this lab environment were not part of a
cluster because redundancy was not necessary for the purposes of these tests.

Search crawl was not running during the tests, whereas it might be running in a
production environment. To take this into account, we lowered the SQL Server CPU
utilization in our definition of ‗Green Zone‘ and ‗Max‘ to accommodate the resources
that a search crawl would have consumed if it were running at the same time with our
tests. To learn more about this, read Speicher- und SQL Server-Kapazitätsplanung
und -Konfiguration (SharePoint Server 2010).
Specifications
This section provides detailed information about the hardware, software, topology, and
configuration of the lab environment.
Hardware
The following sections describe the hardware that was used in this lab environment.
Web and Application servers
There are from one to eight Web servers in the farm, plus one Application server.
Web Server
WFE1-8 and APP1
Processor(s)
2 quad-core 2.33 GHz processors
RAM
8 GB
Operating system
Windows 2008 Server R2
Size of the SharePoint drive
80 GB
Number of network adapters
2
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
153
Web Server
WFE1-8 and APP1
Load balancer type
Windows NLB
Services running locally
WFE 1-8: Basic Federated Services. This
included the following: Timer Service, Admin
Service, and Trace Service. APP1: Word
Automation Services, Excel Services and
SandBoxed Code Services.
Database Servers
There are from two to three database servers, up to two running the default SQL Server
instance housing the content databases, and one running the logging database. The
logging database is not tracked in this document.
Hinweis:
If you enable usage reporting, we recommend that you store the logging database on a
separate Logical Unit Number (LUN). For large deployments and some medium
deployments, a separate LUN will not be sufficient, as the demand on the server’s CPU
may be too high. In that case, you will need a separate database server box for the
logging database. In this lab environment, the logging database was stored in a separate
instance of SQL Server, and its specifications are not included in this document.
Database Server – Default Instance
DB1-2
Processor(s)
4 dual-core 3.19 GHz processors
RAM
32 GB
Operating system
Windows 2008 Server R2
Storage and geometry
Direct Attached Storage (DAS)
Internal Array with 5 x 300GB 10krpm disk
External Array with 15 x 450GB 15krpm disk
6 x Content Data (External RAID0, 2
spindles 450GB each)
2 x Content Logs (Internal RAID0, 1 spindle
300GB each)
1 x Temp Data (Internal RAID0, 2 spindles
150GB each)
1 x Temp Log (Internal RAID0, 2 spindles
150GB each)
2 x Backup drive (Internal RAID0, 1 spindle
each, 300GB each)
154
Database Server – Default Instance
DB1-2
Number of network adapters
1
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Software version
SQL Server 2008 R2 (pre-release version)
Topology
The following diagram shows the topology in this lab environment:
155
Configuration
156
To allow for the optimal performance, the following configuration changes were made in
this lab environment.
Setting
Value
Notes
On
The default is Off. Enabling Blob Caching improves
server efficiency by reducing calls to the database
server for static page resources that may be frequently
requested.
Site Collection
Blob Caching
Database
Server – Default
Instance
Max degree of 1
parallelism
The default is 0. To ensure optimal performance, we
strongly recommend that you set max degree of
parallelism to 1 for database servers that host
SharePoint Server databases. For more information
about how to set max degree of parallelism, see max
degree of parallelism
Option(http://go.microsoft.com/fwlink/?LinkId=189030).
Workload
The transactional mix for the lab environment described in this document resembles the
workload characteristics of a production environment at Microsoft. For more information
about the production environment, see Enterprise intranet collaboration environment
technical case study (SharePoint Server 2010) (in englischer Sprache).
Here are the details of the mix for the lab tests run against SharePoint Server 2010
compared to the production environment. Although there are some minor differences in
the workloads, both represent a typical transactional mix on an enterprise collaboration
environment.
157
Dataset
The dataset for the lab environment described in this document is a subset of the dataset
from a production environment at Microsoft. For more information about the production
environment, see Enterprise intranet collaboration environment technical case study
(SharePoint Server 2010) (in englischer Sprache).
Dataset Characteristics
Value
Database size (combined)
130 GB
BLOB size
108.3 GB
Number of content databases
2
Number of site collections
181
Number of Web applications
1
158
Dataset Characteristics
Value
Number of sites
1384
Results and Analysis
The following results are ordered based on the scaling approach described in the
Overview section of this document.
Web Server Scale Out
This section describes the test results that were obtained when we scaled out the number
of Web servers in this lab environment.
Test methodology

Add Web servers of the same hardware specifications, keeping the rest of the farm
the same.

Measure RPS, latency, and resource utilization.
Analysis
In our testing, we found the following:
 The environment scaled up to four Web servers per database server. However, the
increase in throughput was non-linear especially on addition of the fourth Web server.

After four Web servers, there are no additional gains to be made in throughput by
adding more Web servers because the bottleneck at this point was the database
server CPU Utilization.

The average latency was almost constant throughout the whole test, unaffected by
the number of Web servers and throughput.
Hinweis:
The conclusions described in this section are hardware specific, and the same
throughput might have been achieved by a larger number of lower-end hardware, or a
smaller number of higher-end hardware. Similarly, changing the hardware of the
database server would affect the results. To get an idea on how much of a difference the
hardware of the Web servers can affect these results, see the Web Server Scale Up
section.
Results graphs and charts
In the following graphs, the x axis shows the change in the number of Web servers in the
farm, scaling from one Web server (1x1x1) to five Web servers (5x1x1).
1. Latency and RPS
The following graph shows how scaling out (adding Web servers) affects latency and
RPS.
159
2. Processor utilization
The following graph shows how scaling out the Web servers affects processor utilization
on the Web server(s) and the database server.
160
3. SQL Server I/O operations per section (IOPs) for MDF and LDF files
The following graphs show how the IOPs on the content databases change as the
number of Web servers is scaled out. These are measured by looking at the following
performance counters:
 PhysicalDisk: Disk Reads / sec
 PhysicalDisk: Disk Writes / sec
In this lab environment, we determined that our data on IOPs was not representative of a
production environment because our dataset was so small that we could fit much more of
it in cache than would be possible in the production environment we are modeling. We
calculated projected reads by multiplying the value of the data we had from the lab for
writes/second by the ratio of reads to writes in our production environment. The results in
this section are averages. But there are also spikes that occur during certain operations
which have to be accounted for. To learn more about how to estimate IOPs needed, see
Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server
2010).
Maximum:
161
Green Zone:
Example of how to read these graphs:
162
An organization with a workload similar to that described in this document that expects
300 RPS to be their green zone, could use 3x1x1 topology, and would use approximately
600 Physical Disk reads/sec on the MDF file.
Database Server Scale Out
This section describes the test results that were obtained when we scaled out the number
of database servers in this lab environment.
Test methodology

Have two content databases on one database server, and then split them to two
servers to effectively double the processor cores and memory available to the
database servers in the environment.

Keep the total IOPs capacity constant even while adding a database server. This
means that the number of reads/sec and writes/sec that the disks could perform for
each content database did not change despite splitting the content onto two
database servers instead of one.
Analysis

The first bottleneck in the 4x1x2 environment was the database server CPU
utilization. There was close to a linear scale when we added more processor and
memory power.

Scaling to four Web servers and 2 database servers did not provide much additional
RPS because the CPU utilization on the Web servers was close to 100%.

When we scaled out database servers (by adding one additional database server)
and added four Web servers, performance scaled almost linearly. The bottleneck at
that point shifted from being the database server CPU utilization to the content
database disk IOPs.

No additional tests were performed in this lab environment to scale out past 8x1x2.
However we expect that additional IOPs capacity would additionally increase
throughput.

A correlation between the IOPs used and the RPS achieved by the tests was
observed
Results graphs and charts
In the following graphs, the x axis is always showing four Web servers together with 1
application server and 1 database server (4x1x1) scaling out to eight Web servers
together with two database servers (8x1x2). Some also show 1x1x1 or 4x1x2.
1. Latency and RPS
The following graph shows how scaling out both Web servers and database servers
affects latency and RPS.
163
2. Processor utilization
The following graphs show how scaling out affects processor utilization.
164
3. Memory utilization at scale out
Throughout our testing, we‘ve observed that the larger the number of site collections in
an environment, the more the memory consumed. For example, in the tests here where
181 site collections were accessed, the main w3wp process used up 1.8 GB of RAM. For
more examples, see the Performance and capacity technical case studies (SharePoint
Server 2010) (in englischer Sprache). Additional content about memory requirements for
increased numbers of site collections is under development. Check back for new and
updated content.
4. SQL Server I/O operations per section (IOPs) for MDF and LDF files
The following graphs show how the IOPs change as both the number of Web servers and
the number of database servers is scaled out.
Maximum RPS
165
Green Zone RPS
Web server Scale Up
This section describes the test results that were obtained when we scaled up the Web
servers in this lab environment.
166
Test methodology

Add more Web server processors, but keep the rest of the farm the same.
Analysis

Scale is linear up to eight processor cores.

Tests show that the environment can take advantage of a twenty-four core box,
although there is some degradation as twenty-four cores are approached.
Results graphs and charts
In the following graph, the x axis is the number of processors and the amount of RAM on
the Web server. The following graph shows how scaling up (adding processors) affects
RPS on the Web server.
Comparing SharePoint Server 2010 and Office SharePoint Server
2007
This section provides information about how the capacity testing for this workload varied
between SharePoint Server 2010 and Microsoft Office SharePoint Server 2007.
Workload
To compare SharePoint Server 2010 with Microsoft Office SharePoint Server 2007, a
different test mix was used than the one outlined in the Specifications section, because
some SharePoint Server 2010 operations were not available in Microsoft Office
SharePoint Server 2007. The test mix for Microsoft Office SharePoint Server 2007 is
167
inspired by the same production environment that the SharePoint Server 2010 tests
follow. However this was recorded before the upgrade to SharePoint Server 2010 on that
environment.
The following graph shows the test mix for the lab and production environments for
Microsoft Office SharePoint Server 2007.
Test methodology

The tests performed for this comparison were performed by creating an Microsoft
Office SharePoint Server 2007 environment, testing it with the workload outlined
earlier in this section, and then upgrading the content databases to SharePoint
Server 2010 without changing the clients using the environment, nor doing a visual
upgrade. This upgraded environment was then re-tested for the SharePoint Server
2010 results with the same test mix which includes only Microsoft Office SharePoint
Server 2007 operations.

The dataset was not modified after the content database upgrade for the SharePoint
Server 2010 tests.

The test mix for Microsoft Office SharePoint Server 2007 excludes any new
SharePoint Server 2010 specific operations, and resembles the enterprise intranet
collaboration solution on the same production environment for Microsoft Office
SharePoint Server 2007, as described under the Workload section.
Analysis

When the same number of Web servers are stressed to their maximum throughput
on SharePoint Server 2010 and Microsoft Office SharePoint Server 2007, SharePoint
Server 2010 achieves 20% less throughput compared to Microsoft Office SharePoint
Server 2007.
168

When the Web servers were scaled out to maximize the database server usage,
SharePoint Server 2010 was able to achieve 25% better throughput compared to
Microsoft Office SharePoint Server 2007. This reflects the improvements that were
made in SharePoint Server 2010 to sustain larger deployments.

When the web servers were scaled out to maximize the database server usage,
SharePoint Server 2010 was SQL Server CPU Utilization bound, whereas Microsoft
Office SharePoint Server 2007 was Lock bound on the database tier. This means
that increasing the processing power available to the database servers enables
SharePoint Server 2010 to achieve better throughput than would be possible with the
same hardware using Microsoft Office SharePoint Server 2007. This is caused by the
locking mechanisms in the database in Microsoft Office SharePoint Server 2007
which are unaffected by improved hardware so that we were unable to push the
database server‘s CPU Utilization past 80%.

As a result of these findings outlined earlier in this section, on Microsoft Office
SharePoint Server 2007 the maximum throughput possible was achieved in a 5x0x1
topology whereas in SharePoint Server 2010 the maximum throughput possible with
the same workload was achieved in a 7x0x1 topology, and yielded a 25% increased
total RPS.
Results graphs and charts
The following graph shows the throughput without scaling out Web servers.
The following graph shows the throughput when Web servers were at maximum scale
out.
169
170
Departmental collaboration environment
technical case study (SharePoint Server
2010) (in englischer Sprache)
This document describes a specific deployment of Microsoft SharePoint Server 2010. It
includes the following:
 Technical case study environment specifications, such as hardware, farm topology
and configuration

The workload that includes the number, and types, of users or clients, and
environment usage characteristics

Technical case study farm dataset that includes database contents and Search
indexes
 Health and performance data that is specific to the environment
In this article:
 Prerequisite information

Introduction to this environment

Specifications

Workload

Dataset

Health and Performance Data
Prerequisite information
Before reading this document, make sure that you understand the key concepts behind
SharePoint Server 2010 capacity management. The following documentation will help
you learn about the recommended approach to capacity management and provide
context for helping you understand how to make effective use of the information in this
document, and also define the terms used throughout this document.
For more conceptual information about performance and capacity that you might find
valuable in understanding the context of the data in this technical case study, see the
following documents:
 Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht)

SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und grenzen
Introduction to this environment
This white paper describes an actual SharePoint Server 2010 environment at Microsoft.
Use this document to compare with your planned workload and usage characteristics. If
171
your planned design is similar, you can use the deployment described here as a starting
point for your own installation.
This document includes the following:
 Specifications, which include hardware, topology and configuration

Workload, which is the demand on the farm that includes the number of users, and
the usage characteristics

Dataset that includes database sizes
 Health and performance data that is specific to the environment
This document is part of a series of Performance and capacity technical case studies
(SharePoint Server 2010) (in englischer Sprache) about SharePoint environments at
Microsoft.
The
SharePoint Server 2010 environment described in this document is a production
environment at a large, geographically distributed company. Employees use this
environment to track projects, collaborate on documents, and share information within
their department. This environment is also used for internal testing, and is frequently
upgraded to the latest SharePoint Server pre-release versions as they become available.
As many as 9,000 unique users visit the environment on a busy day, generating up to
470 requests per second (RPS) during peak hours. Because this is an intranet site, all
users are authenticated.
The information that is provided in this document reflects the departmental collaboration
environment on a typical day.
Specifications
This section provides detailed information about the hardware, software, topology, and
configuration of the case-study environment.
Hardware
This section provides details about the server computers that were used in this
environment.
172
Hinweis:
This environment is scaled to accommodate pre-release builds of SharePoint Server
2010 and other products. Hence, the hardware deployed has larger capacity than
necessary to serve the demand typically experienced by this environment. This hardware
is described only to provide additional context for this environment and serve as a
starting point for similar environments.
It is important to conduct your own capacity management based on your planned
workload and usage characteristics. For more information about the capacity
management process, see Kapazitätsverwaltung und Größengestaltung für SharePoint
Server 2010 (Übersicht).
Web Servers
There are four Web servers in the farm, each with identical hardware. Three serve
content, and the fourth is a dedicated search crawl target.
Web Server
WFE1-2
WFE3-4
Processor(s)
2 quad core @ 2.33 GHz
2 quad core @
2.33 GHz
RAM
32 GB
16 GB
Operating system
Windows Server 2008, 64 bit
Windows
Server 2008, 64
bit
Size of the SharePoint drive
3x146GB 15K SAS (3 RAID 1
Disks) Disk 1: OS Disk 2: Swap
and BLOB Cache Disk 3: Logs and
Temp directory
3x146GB 15K
SAS (3 RAID 1
Disks) Disk 1:
OS Disk 2: Swap
and BLOB Cache
Disk 3: Logs and
Temp directory
Number of network adapters
2
2
Network adapter speed
1 Gigabit
1 Gigabit
Authentication
Windows NTLM
Windows NTLM
Load balancer type
Hardware load balancing
Hardware load
balancing
Software version
SharePoint Server 2010 (prerelease version)
SharePoint
Server 2010
(pre-release
version)
Services running locally
Search Query
WFE3 – No
173
Web Server
WFE1-2
WFE3-4
services
WFE4 – Search
crawl target
Application Server
There are four application servers in the farm.
Web Server
APP1-3
APP4
Processor(s)
2 quad core @ 2.33 GHz
2 quad core @
2.33 GHz
RAM
16 GB
16 GB
Operating system
Windows Server 2008, 64 bit
Windows
Server 2008, 64
bit
Size of the SharePoint drive
3x146GB 15K SAS (3 RAID 1
Disks) Disk 1: OS Disk 2: Swap
and BLOB Cache Disk 3: Logs and
Temp directory
2x136GB 15K
SAS (RAID 0)
4x60GB SSD,
SATA (RAID 5)
Disk 1: OS Disk
2: Swap and
BLOB Cache
Disk 3: Logs and
Temp directory
Number of network adapters
2
2
Network adapter speed
1 Gigabit
1 Gigabit
Authentication
Windows NTLM
Windows NTLM
Load balancer type
Hardware load balancing
Hardware load
balancing
Software version
SharePoint Server 2010 (prerelease version)
SharePoint
Server 2010
(pre-release
version)
Services running locally
APP1 – Central Administration and Search Crawler
all applications except for Office
Web Applications
APP2 – All applications (including
Office Web Applications)
APP3 – Office Web Applications
174
Database Servers
There are three database servers, one running the default SQL Server instance housing
the content databases, one running the Usage and Web Analytics databases, and one
running the Search databases.
Database
DB1 – Default Instance
DB2
DB3
Processor(s)
4 quad core @ 3.2 GHz
2 quad core 2 quad core
@ 3.2 GHz @ 3.2 GHz
RAM
32 GB
16 GB
Operating system
Windows
Windows Server 2008 SP1, 64 Windows
Server 2008 Server 2008
bit
SP1, 64 bit SP1, 64 bit
Storage and geometry
5x146GB 15K SAS + SAN
Disk 1: OS (2 disk RAID 10)
Disk 2: Swap (2 disk RAID 10)
Disk 3: Direct Attached
Storage (16 disk RAID 10,
Temp DB data) SAS 146 GB
15K
Disk 4: Direct Attached
Storage (16 disk RAID 10,
Temp DB data) SAS 146 GB
15K
Disk 5-15: SAN using fiber
connection. When possible,
one database per two disks.
Separating logs and data
between LUNs. 15K drives.
32 GB
6x450GB
15K SAS
Directly
attached
14x146GB
15K SAS
Disk 1:
Usage logs
and OS
Disk 2:
Usage data
2x136GB
15K SAS
(RAID 0)
6x60GB
SSD, SATA
(RAID 5)
Disk 1: OS
Disk 2:
Swap and
BLOB
Cache
Disk 3:
Logs and
Temp
directory.
Solid state
drives. 660GB Solid
state drives
(RAID 5)
Number of network adapters 2
2
2
Network adapter speed
1 Gigabit
1 Gigabit
1 Gigabit
Authentication
Windows NTLM
Windows
NTLM
Windows
NTLM
Software version
SQL Server 2008
SQL Server SQL Server
2008
2008 R2
Topology
The following diagram shows the topology for this farm.
175
Configuration
176
The following table enumerates settings that were made that affect performance or
capacity in the environment.
Setting
Value
Notes
Site collection:
On
Object Caching (On |
Disabled
Off)
Disabled
Anonymous Cache
On – 100GB
Profile (select)
60 seconds
Anonymous Cache
Profile (select)
Object Cache (Off | n
MB)
Cross List Query Cache
Changes (Every Time |
Every n seconds)
Enabling the output cache improves server
efficiency by reducing calls to the database for
data that is frequently requested.
Site collection cache
profile (select)
Intranet
(Collaboration
Site)
“Allow writers to view cached content” is
checked, bypassing the ordinary behavior of not
letting people with edit permissions to have
their pages cached.
Object Cache (Off | n
MB)
On – 500 MB
The default is 100 MB. Increasing this setting
enables additional data to be stored in the frontend Web server memory.
Usage Service:
Trace Log – days to
store log files (default:
14 days)
5 days
The default is 14 days. Lowering this setting
can save disk space on the server where the
log files are stored.
Query Logging
1 second
Threshold:
Microsoft SharePoint
Foundation Database –
configure
QueryLoggingThreshold
to 1 second
The default is 5 seconds. Lowering this setting
can save bandwidth and CPU on the database
server.
Database Server –
Default Instance:
Max degree of
parallelism
The default is 0. To ensure optimal
performance, we strongly recommend that you
set max degree of parallelism to 1 for database
servers that host SharePoint Server 2010
databases. For more information about how to
set max degree of parallelism, see max degree
of parallelism Option
(http://go.microsoft.com/fwlink/?LinkId=189030).
1
177
Workload
This section describes the workload, which is the demand on the farm that includes the
number of users, and the usage characteristics.
Workload Characteristics
Value
Average Requests per Second (RPS)
165
Average RPS at peak time (11 AM-3 PM)
216
Total number of unique users per day
9186
Average concurrent users
189
Maximum concurrent users
322
Total # of requests per day
7,124,943
This table shows the number of requests for each user agent.
User Agent
Requests
Percentage of
Total
Search (crawl)
4,373,433
67.61%
Outlook
897,183
13.87%
OneNote
456,917
7.06%
DAV
273,391
4.23%
Browser
247,303
3.82%
Word
94,465
1.46%
SharePoint Workspaces
70,651
1.09%
Office Web Applications
45,125
0.70%
Excel
8,826
0.14%
Access
1,698
0.03%
Dataset
This section describes the case study farm dataset that includes database sizes and
Search indexes.
Dataset Characteristics
Value
178
Dataset Characteristics
Value
Database size (combined)
1.8 TB
BLOB size
1.68 TB
Number of content databases
18
Total number of databases
36
Number of site collections
7,499
Number of Web applications
7
Number of sites
42,457
Search index size (number of items)
4.6 million
Health and Performance Data
This section provides health and performance data that is specific to the case study
environment.
General Counters
Metric
Value
Availability (uptime)
99.9995%
Failure Rate
0.0005%
Average memory used
0.89 GB
Maximum memory used
5.13 GB
Search Crawl % of Traffic (Search client
requests / total requests)
82.5%
The following charts show the average CPU utilization and latency for this environment:
179
In this document, latency is divided into four categories. The 50th percentile latency is
typically used to measure the server‘s responsiveness. It means that half of the requests
180
are served within that response time. The 95th percentile latency is typically used to
measure spikes in server response times. It means that 95% of requests are served
within that response time, and therefore, 5% of the requests experience slower response
times.
Database Counters
Metric
Value
Average Disk queue length
1.42
Disk Queue Length: Reads
1.38
Disk Queue Length: Writes
0.04
Disk Reads/sec
56.51
Disk Writes/sec
17.60
SQL Compilations/second
13.11
SQL Re-compilations/second
0.14
SQL Locks: Average Wait Time
294.56 ms
SQL Locks: Lock Wait Time
867.53 ms
SQL Locks: Deadlocks Per Second
1.87
SQL Latches: Average Wait Time
5.10 ms
SQL Cache Hit Ratio
99.77%
181
Divisional portal environment lab study
(SharePoint Server 2010) (in englischer
Sprache)
This document provides guidance on performance and capacity planning for a divisional
portal based on Microsoft SharePoint Server 2010. It includes the following:
 Test environment specifications, such as hardware, farm topology and configuration

Test farm dataset

Test data and recommendations for how to determine the hardware, topology and
configuration that you must have to deploy a similar environment, and how to
optimize your environment for appropriate capacity and performance characteristics
In this article:
 Introduction to this environment

Glossary

Overview

Specifications

Results and analysis
Introduction to this environment
This document outlines the test methodology and results to provide guidance for capacity
planning of a typical divisional portal. A divisional portal is a SharePoint Server 2010
deployment where teams mainly do collaborative activities and some content publishing.
This document assumes a "division" to be an organization inside an enterprise with 1,000
to 10,000 employees.
Different scenarios will have different requirements. Therefore, it is important to
supplement this guidance with additional testing on your own hardware and in your own
environment. If your planned design and workload resembles the environment described
in this document, you can use this document to draw conclusions about scaling your
environment up and out.
When you read this document, you will understand how to do the following:
 Estimate the hardware that is required to support the scale that you need to support:
number of users, load, and the features enabled.

Design your physical and logical topology for optimal reliability and efficiency. High
Availability/Disaster Recovery are not covered in this document.

Understand the effect of ongoing search crawls on RPS for a divisional portal
deployment.
The SharePoint Server 2010 environment described in this document is a lab
environment that mimics a production environment at a large company. For details about
182
the production environment, see Departmental collaboration environment technical case
study (SharePoint Server 2010) (in englischer Sprache).
Before reading this document, make sure that you understand the key concepts behind
capacity management in SharePoint Server 2010. The following documentation will help
you learn about the recommended approach to capacity management and provide
context for helping you understand how to make effective use of the information in this
document, and also define the terms used throughout this document.
 Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht)

SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und grenzen
Also, we encourage you to read the following:
 Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server
2010)
Glossary
There are some specialized terms that you will encounter in this document. Here are
some key terms and their definitions.
 RPS: Requests per second. The number of requests received by a farm or server in
one second. This is a common measurement of server and farm load.
Note that requests differ from page loads; each page contains several components,
each of which creates one or more requests when the page is loaded. Therefore, one
page load creates several requests. Typically, authentication checks and events
using insignificant resources are not counted in RPS measurements.
 Green Zone: This is the state at which the server can maintain the following set of
criteria:

The server-side latency for at least 75% of the requests is less than .5 second.

All servers have a CPU Utilization of less than 50%.
Hinweis:
Because this lab environment did not have an active search crawl running, the database
server was kept at 40% CPU Utilization or lower, to reserve 10% for the search crawl
load. This assumes Microsoft SQL Server Resource Governor is used in production to
limit Search crawl load to 10% CPU.


Failure rate is less than 0.01%.
Red Zone (Max): This is the state at which the server can maintain the following set
of criteria:

HTTP request throttling feature is enabled, but no 503 errors (Server Busy) are
returned.

Failure rate is less than 0. 1%.

The server-side latency is less than 1 second for at least 75% of the requests.

Database server CPU utilization is less than or equal to 75%, which allows for
10% to be reserved for the Search crawl load, limited by using SQL Server
Resource Governor.

All Web servers have a CPU Utilization of less than or equal to 75%.
183

AxBxC (Graph notation): This is the number of Web servers, application servers,
and database servers respectively in a farm. For example, 2x1x1 means that this
environment has 2 Web servers, 1 application server, and 1 database server.

MDF and LDF:
SQL Server physical files. For more information, see Files
and Filegroups Architecture.
Overview
This section provides an overview to our assumptions and our test methodology.
Assumptions
For our testing, we made the following assumptions:
 In the scope of this testing, we did not consider disk I/O as a limiting factor. It is
assumed that an infinite number of spindles are available.

The tests model only peak time usage on a typical divisional portal. We did not
consider cyclical changes in traffic seen with day-night cycles. That also means that
timer jobs which generally require scheduled nightly runs are not included in the mix.

There is no custom code running on the divisional portal deployment in this case. We
cannot guarantee behavior of custom code/third-party solutions installed and running
in your divisional portal.

For the purpose of these tests, all of the services databases and the content
databases were put on the same instance of Microsoft SQL Server. The usage
database was maintained on a separate instance of SQL Server.

For the purpose of these tests, BLOB cache is enabled.

Search crawl traffic is not considered in these tests. But to factor in the effects of an
ongoing search crawl, we modified definitions of a healthy farm. (Green-zone
definition to be 40 percent for SQL Server to allow for 10 percent tax from Search
crawls. Similarly, we used 80 percent SQL Server CPU as the criteria for max RPS.)
Test methodology
We used Visual Studio Team System for Test 2008 SP2 to perform the performance
testing. The testing goal was to find the performance characteristic of green zone, max
zone and various system stages in between for each topology. Detailed definitions of
"max zone" and "green zone" are given in the Glossary as measured by specific values
for performance counters, but in general, a farm configuration performing around "max
zone" breakpoint can be considered under stress, whereas a farm configuration
performing "green zone" breakpoint can be considered healthy.
The test approach was to start by using the most basic farm configuration and run a set
of tests. The first test is to gradually increase the load on the system and monitor its
performance characteristic. From this test we derived the throughput and latency at
various user loads and also identified the system bottleneck. After we had this data, we
identified at what user load did the farm exhibit green zone and max zone characteristics.
We ran separate tests at those pre-identified constant user loads for a longer time. These
tests ensured that the farm configuration can provide constant green zone and max zone
performance at respective user loads, over longer period of time.
Later, while doing the tests for the next configuration, we scaled out the system to
eliminate bottlenecks identified in previous run. We kept iterating in this manner until we
hit SQL Server CPU bottleneck.
184
We started off with a minimal farm configuration of 1 Web server /application server and
1 database server. Through multiple iterations, we finally ended at 3 Web servers, 1
application server, 1 database server farm configuration, where the database server CPU
was maxed out. Below you will find a quick summary and charts of tests we performed on
each iteration to establish green zone and max zone for that configuration. That is
followed by comparison of green zone and max zone for different iterations, from which
we derive our recommendations.
The SharePoint Admin Toolkit team has built a tool that is named "Load Test Toolkit
(LTK)" which is publically available for customers to download and use.
Specifications
This section provides detailed information about the hardware, software, topology, and
configuration of the lab environment.
Hardware
The table that follows presents hardware specs for the computers that were used in this
testing. Every Web server that was added to the server farm during multiple iterations of
the test complies with the same specifications.
Web server
Application
Server
Processor(s)
[email protected]
[email protected] 4px4c@
3.19GHz
RAM
8 GB
8 GB
32 GB
Number of network
adapters
2
2
1
Network adapter speed
1 Gigabit
1 gigabit
1 Gigabit
Load balancer type
F5 - Hardware load balancer Not applicable
Not
applicable
ULS Logging level
Medium
Not
applicable
Medium
Database
Server
Software
The table that follows explains software installed and running on the servers that were
used in this testing effort.
Web Server
Operating System
Application
Server
Windows Server 2008 R2 x64 Windows
Server 2008
R2 x64
185
Database
Server
Windows
Server 2008
x64
Web Server
Application
Server
Database
Server
Software version
SharePoint Server 2010 and SharePoint
SQL Server
Office Web Applications, pre- Server 2010 2008 R2
release versions
and Office
CTP3
Web
Applications,
pre-release
versions
Authentication
Windows NTLM
Windows
NTLM
Load balancer type
F5 - Hardware load balancer
Not applicable Not
applicable
ULS Logging level
Medium
Medium
Not
applicable
Anti-Virus Settings
Disabled
Disabled
Disabled
Services running locally
Microsoft SharePoint
Foundation Incoming E-Mail
Microsoft SharePoint
Foundation Web Application
Microsoft SharePoint
Foundation Workflow Timer
Service
Search Query and Site
Settings Service
SharePoint Server Search
Central
Not
Administration applicable
Excel
Services
Managed
Metadata
Web Service
Microsoft
SharePoint
Foundation
Incoming EMail
Microsoft
SharePoint
Foundation
Web
Application
Microsoft
SharePoint
Foundation
Workflow
Timer Service
PowerPoint
Services
Search Query
and Site
Settings
Service
186
Windows
NTLM
Web Server
Application
Server
Database
Server
SharePoint
Server
Search
Visio
Graphics
Services
Word Viewing
Service
The table indicates which services are provisioned in the test environment. Other
services such as the User Profile service and Web Analytics are not provisioned.
Topology and configuration
The following diagram shows the topology used for the tests. We changed the number of
Web servers from 1 to 2 to 3, as we moved between iterations, but otherwise the
topology remained the same.
187
Dataset and disk geometry
188
The test farm was populated with about 1.62 Terabytes of content, distributed across five
different sized content databases. The following table explains this distribution:
Content database
1
2
3
4
5
Content database size
36 GB
135 GB
175 1.2
75
GB terabytes GB
Number of sites
44
74
9
Number of webs
1544
2308
2242 2041
1178
RAID configuration
0
0
0
0
0
Number of spindles for
MDF
1
1
5
3
1
Number of spindles for
LDF
1
1
1
1
1
9
222
Transactional mix
The following are important notes about the transactional mix:
 There are no My Sites provisioned on the divisional portal. Also, the User Profile
service, which supports My Sites, is not running on the farm. The transactional mix
does not include any My Site page/web service hits or traffic related to Outlook Social
Connector.

The test mix does not include any traffic generated by co-authoring on documents.

The test mix does not include traffic from Search Crawl. However this was factored
into our tests by modifying the Green-zone definition to be 40 percent SQL Server
CPU usage instead of the standard 50 percent to allow for 10 percent for the search
crawl. Similarly, we used 80 percent SQL Server CPU as the criteria for max RPS.
The following table describes the overall transaction mix. The percentages total 100.
Feature or Service
Operation
Read/write
Percentage
of mix
ECM
Get static files
r
8.93%
View home page
r
1.52%
Display/Edit upsize list item and r
new forms
0.32%
Download file by using "Save
as"
1.39%
Microsoft InfoPath
Microsoft OneNote 2010
r
Open
r
Microsoft Office OneNote 2007
file
189
13.04%
Feature or Service
Operation
Read/write
Percentage
of mix
Search
Search through
OSSSearch.aspx or
SearchCenter
r
4.11%
Workflow
Start autostart workflow
w
0.35%
Microsoft Visio
Render Visio file in PNG/XAML r
0.90%
Office Web Applications PowerPoint
Render Microsoft PowerPoint, r
scroll to 6 slides
0.05%
Office Web Applications Word
Render and scroll Microsoft
Word doc in PNG/Silverlight
r
0.24%
Microsoft SharePoint
Foundation
List – Check out and then
check in an item
w
0.83%
List - Get list
r
0.83%
List - Outlook sync
r
1.66%
List - Get list item changes
r
2.49%
List - Update list items and
adding new items
w
4.34%
Get view and view collection
r
0.22%
Get webs
r
1.21%
Browse to Access denied page r
0.07%
View Browse to list feeds
r
0.62%
Browse to viewlists
r
0.03%
Browse to default.aspx (home r
page)
1.70%
Browse to Upload doc to doc lib w
0.05%
Browse to List/Library's default r
view
7.16%
Delete doc in doclib using DAV w
0.83%
Get doc from doclib using DAV r
6.44%
Lock and Unlock a doc in doclib w
using DAV
3.32%
Propfind list by using DAV
r
4.16%
Propfind site by using DAV
r
4.16%
190
Feature or Service
Operation
Read/write
Percentage
of mix
List document by using FPSE
r
0.91%
Upload doc by using FPSE
w
0.91%
Browse to all site content page r
0.03%
View RSS feeds of lists or wikis r
2.03%
Excel Services
Render small/large Excel files
1.56%
Workspaces
WXP - Cobalt internal protocol r
23.00%
Full file upload using WXP
0.57%
r
w
Results and analysis
This section describes the test methodology and results to provide guidance for capacity
planning of a typical divisional portal.
Results from 1x1 farm configuration
Summary of results

On a 1 Web server and 1 database server farm, in addition to Web server duties, the
same computer was also acting as application server. Clearly this computer (still
called Web server) was the bottleneck. As presented in the data here, the Web
server CPU reached around 86% utilization when the farm was subjected to user
load of 125 users by using the transactional mix described earlier in this document.
At that point, the farm exhibited max RPS of 101.37.

Even at a small user load, Web server utilization was always too high to consider this
farm as a healthy farm. For the workload and dataset that we used for the test, we do
not recommend this configuration as a real deployment.

Going by definition of "green zone", there is not really a "green zone" for this farm. It
is always under stress, even at a small load. As for "max zone", at the smallest load,
where the farm was in "max zone", the RPS was 75.

Because the Web server was the bottleneck due to its dual role as an application
server, for the next iteration, we separated out the application server role onto its own
computer.
Performance counters and graphs
The following table presents various performance counters captured during testing a 1x1
farm at different steps in user load.
User Load
50
75
100
RPS
74.958
89.001
95.79 101.37
Latency
0.42
0.66
0.81 0.81
191
125
User Load
50
75
100
Web server CPU
79.6
80.1
89.9 86
Application server CPU
N/A
N/A
N/A
Database server CPU
15.1
18.2
18.6 18.1
75th Percentile (sec)
0.3
0.35
0.55 0.59
95th Percentile (sec)
0.71
0.77
1.03 1
The following chart shows the RPS and latency results for a 1x1 configuration.
The following chart shows performance counter data in a 1x1 configuration.
192
125
N/A
Results from 1x1x1 farm configuration
Summary of results

On a 1 Web server, 1 application server and 1 database server farm, the Web server
was the bottleneck. As presented in the data in this section, the Web server CPU
reached around 85% utilization when the farm was subjected to user load of 150
users by using the transactional mix described earlier in this document. At that point,
the farm exhibited max RPS of 124.1.

This configuration delivered "green zone" RPS of 99, with 75th percentile latency
being 0.23 sec, and the Web server CPU hovering around 56 % utilization. This
indicates that this farm can healthily deliver an RPS of around 99. "Max zone" RPS
delivered by this farm was 123 with latencies of 0.25 sec and the Web server CPU
hovering around 85%.

Because the Web server CPU was the bottleneck in this iteration, we relived the
bottleneck by adding another the Web server for the next iteration.
Performance counters and graphs
The following table presents various performance counters captured during testing a
1x1x1 farm, at different steps in user load.
User Load
25
50
193
75
100
125
150
User Load
25
50
75
100
125
RPS
53.38
91.8
112.2 123.25 123.25 124.1
Latency
34.2
56
71.7 81.5
84.5
84.9
Web server CPU
23.2
33.8
34.4 32
30.9
35.8
Application server CPU 12.9
19.7
24.1 25.2
23.8
40.9
Database server CPU
0.22
0.23
0.27 0.32
0.35
0.42
75th Percentile (sec)
0.54
0.52
0.68 0.71
0.74
0.88
The following chart shows RPS and latency results for a 1x1x1 configuration.
The following chart shows performance counter data in a 1x1x1 configuration.
194
150
Results from 2x1x1 farm configuration
Summary of results

On a 2 Web server, 1 application server and 1 database server farm, the Web server
was the bottleneck. As presented in the data in this section, Web server CPU
reached around 76% utilization when the farm was subjected to user load of 200
users by using the transactional mix described earlier in this document. At that point,
the farm exhibited max RPS of 318.

This configuration delivered "green zone" RPS of 191, with 75th percentile latency
being 0.37 sec, and Web server CPU hovering around 47 % utilization. This indicates
that this farm can healthily deliver an RPS of around 191. "Max zone" RPS delivered
by this farm was 291 with latencies of 0.5 sec and Web server CPU hovering around
75%.

Because the Web server CPU was the bottleneck in this iteration, we relived the
bottleneck by adding another Web server for the next iteration.
Performance counters and graphs
The following table presents various performance counters captured during testing a
2x1x1 farm, at different steps in user load.
User Load
40
80
195
115
150
175
200
User Load
40
80
115
150
175
200
RPS
109
190
251 287
304
318
Latency
0.32
0.37
0.42 0.49 0.54 0.59
Web server CPU
27.5
47.3
61.5 66.9 73.8 76.2
Application server CPU
17.6
29.7
34.7 38
Database server CPU
21.2
36.1
43.7 48.5 52.8 56.2
75th Percentile (sec)
0.205
0.23
0.27 0.3
95th Percentile (sec)
0.535
0.57
0.625 0.745 0.645 0.57
The following chart shows RPS and latency results for a 2x1x1 configuration.
The following chart shows performance counter data in a 2x1x1 configuration.
196
45
45.9
0.305 0.305
Results from 3x1x1 farm configuration
Summary of results

On a 3 Web server, 1 application server and 1 database server farm, finally, the
database server CPU was the bottleneck. As presented in the data in this section,
database server CPU reached around 76% utilization when the farm was subjected
to user load of 226 users by using the transactional mix described earlier in this
document. At that point, the farm exhibited max RPS of 310.

This configuration delivered "green zone" RPS of 242, with 75th percentile latency
being 0.41 sec, and database server CPU hovering around 44% utilization. This
indicates that this farm can healthily deliver an RPS of around 242. "Max zone" RPS
delivered by this farm was 318 with latencies of 0.5 sec and database server CPU
hovering around 75%.
 This was the last configuration in the series.
Performance counters and graphs
The following table presents various performance counters captured during testing a
3x1x1 farm, at different steps in user load.
User Load
66
103
141
RPS
193.8
218.5
269.8 275.5 318.25 310
197
17
202
226
User Load
66
103
141
17
202
Latency
0.3
0.41
0.47 0.58 0.54
0.78
Web server CPU
33
38.3
45.8 43.3 51
42.5
Application server CPU
28
32.6
46.5 40
45.1
43.7
Database server CPU
41.6
44.2
52.6 48
61.8
75
75th Percentile (sec)
0.22
0.24
0.30 0.65 0.78
0.87
95th Percentile (sec)
0.49
0.57
0.72 1.49 0.51
1.43
The following chart shows RPS and latency results in a 3x1x1 configuration.
The following chart shows performance counter data for a 3x1x1 configuration.
198
226
Comparison
From the iterative tests we performed, we found out the points at which a configuration
enters max zone or green zone. Here‘s a table of those points.
The table and charts in this section provide a summary for all the results that were
presented earlier in this article.
Topology
1x1
1x1x1
2x1x1 3x1x1
Max RPS
75
123
291
318
Green Zone RPS
Not applicable
99
191
242
Max Latency
0.29
0.25
0.5
0.5
Green Zone Latency
0.23
0.23
0.37 0.41
The following chart shows a summary of RPS at different configurations.
199
The following chart shows a summary of latency at different configurations.
200
A note on disk I/O
Disk I/O based bottlenecks are not considered while prescribing recommendations in this
document. However, it is still interesting to observe the trend. Here are the numbers:
Configuration
1x1
1x1x1
2x1x1 3x1x1
Max RPS
75
154
291
318
Reads/Sec
38
34
54
58
Writes/Sec
135
115
230
270
Because we ran the tests in durations of 1 hour and the test uses only a fixed set of
sites/webs/document libraries and so on, SQL Server could cache all the data. Thus, our
testing caused very little Read IO. We see more write I/O operations that read. It is
important to be aware that this is an artifact of the test methodology, and not a good
representation of real deployments. Most of the typical divisional portals would have more
read operations 3 to 4 times more than write operations.
The following chart shows I/Ops at different RPS.
201
Tests with Search incremental crawl
As we mentioned before, all the tests until now were run without Search crawl traffic. In
order to provide information about how ongoing search crawl can affect performance of a
farm, we decided to find out the max user RPS and corresponding user latencies with
search crawl traffic in the mix. We added a separate Web server to 3x1x1 farm,
designated as a crawl target. We saw a 17% drop in RPS compared to original RPS
exhibited by 3x1x1.
In a separate test, on the same farm, we used Resource Governor to limit available
resources to search crawl 10%. We saw that as Search uses lesser resources, the max
RPS of the farm climbs up by 6%.
Baseline 3x1x1
Only
No
10%
Incremental Resource Resource
Crawl
Governor Governor
RPS
318
N/A
276
294.5
Percent RPS difference
from baseline
0%
N/A
83%
88%
Database server CPU (%)
83.40
8.00
86.60
87.3
SA Database server CPU
3.16
2.13
3.88
4.2
202
Baseline 3x1x1
Only
No
10%
Incremental Resource Resource
Crawl
Governor Governor
Web server CPU (%)
53.40
0.30
47.00
46.5
Application server CPU
(%)
22.10
28.60
48.00
41.3
16.50
15.00
12.1
(%)
Crawl Web server CPU (%) 0.50
The following chart shows results from tests with incremental Search crawl turned on.
203
Wichtig:
Here we are only talking about incremental crawl, on a farm where there are not very
many changes to the content. It is important to be aware that 10% resource utilization will
be insufficient for a full search crawl. It may also prove to be less if there are too many
changes. It is definitely not advised to limit resource utilization to 10% if you are running a
full search crawl, or your farm generally sees a high volume of content changes between
crawls.
Summary of results and recommendations
To paraphrase the results from all configurations we tested:
 With the configuration, dataset and test workload we had selected for the tests, we
could scale out to maximum 3 Web servers before SQL Server was bottlenecked on
CPU. The absolute max RPS we could reach that point was somewhere around 318.

With each additional Web server, increase in RPS was almost linear. We can
extrapolate that as long as SQL Server is not bottlenecked, you can add more Web
servers and additional increase in RPS is possible.

Latencies are not affected much as we approached bottleneck on SQL Server.

Incremental Search crawl directly affects RPS offered by a configuration. The effect
can be minimized by using Resource Governor.
Using the results, here are few recommendations on how to achieve even larger scale if
you must have more RPS from your divisional portal:
 1x1 farm can deliver up to 75 RPS. However, it is usually stressed. It‘s not a
recommended configuration for a divisional portal in production.

Separate out content databases and services databases on separate instances of
SQL Server: In the test workload used in tests, when SQL Server was bottlenecked
on CPU, only 3% of the traffic was to the services databases. Thus this step would
have achieved slightly better scale out than what we saw. But, in general, increase in
scale out by separating out content databases and services databases is directly
proportional to the traffic to services database in your farm.

Separate out individual content databases on separate instances of SQL Server. In
the dataset used for testing, we had 5 content databases, all located on the same
instance of SQL Server. By separating them out on different computers, you will be
spreading CPU utilization across multiple computers. Therefore, you will see much
larger RPS numbers.

Finally when SQL Server is bottlenecked on CPU, adding more CPU to SQL Server
can increase RPS potential of the farm almost linearly.
How to translate these results into your deployment
In this article, we discussed results as measured by RPS and latency, but how do you
apply these in the real world? Here‘s some math based on our experience from divisional
portal internal to Microsoft.
A divisional portal in Microsoft which supports around 8000 employees collaborating
heavily, experiences an average RPS of 110. That gives a Users to RPS ratio of ~72
204
(that is, 8000/110). Using the ratio, and the results discussed earlier in this article, we can
estimate how many users a particular farm configuration can support healthily:
Farm configuration
"Green Zone" RPS
Approximate
number of users
it can support
1x1x1
99
7128
2x1x1
191
13452
3x1x1
242
17424
Of course, this is only directly applicable if your transactional mix and hardware is exactly
same as the one used for these tests. Your divisional portal may have different usage
pattern. Therefore, the ratio may not directly apply. However, we expect it to be
approximately applicable.
About the authors
Gaurav Doshi is a Program Manager for SharePoint Server at Microsoft.
Raj Dhrolia is a Software Test Engineer for SharePoint Server at Microsoft.
Wayne Roseberry is a Principal Test Lead for SharePoint Server at Microsoft.
205
Social environment technical case study
(SharePoint Server 2010) (in englischer
Sprache)
This document describes a specific deployment of Microsoft SharePoint Server 2010. It
includes the following:
 Technical case study environment specifications, such as hardware, farm topology
and configuration

The workload that includes the number, and types, of users or clients, and
environment usage characteristics

Technical case study farm dataset that includes database contents and Search
indexes
 Health and performance data that is specific to the environment
In this article:
 Prerequisite information

Introduction to this environment

Specifications

Workload

Dataset

Health and Performance Data
Prerequisite information
Before reading this document, make sure that you understand the key concepts behind
SharePoint Server 2010 capacity management. The following documentation will help
you learn about the recommended approach to capacity management and provide
context for helping you understand how to make effective use of the information in this
document, and also define the terms used throughout this document.
For more conceptual information about performance and capacity that you might find
valuable in understanding the context of the data in this technical case study, see the
following documents:
 Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht)

SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und grenzen
Introduction to this environment
This white paper describes an actual SharePoint Server 2010 environment at Microsoft.
Use this document to compare with your planned workload and usage characteristics. If
206
your planned design is similar, you can use the deployment described here as a starting
point for your own installation.
This document includes the following:
 Specifications, which include hardware, topology and configuration

Workload, which is the demand on the farm that includes the number of users, and
the usage characteristics

Dataset that includes database sizes
 Health and performance data specific to the environment
This document is part of a series of Performance and capacity technical case studies
(SharePoint Server 2010) (in englischer Sprache) about SharePoint environments at
Microsoft.
The
SharePoint Server 2010 environment described in this document is a production
environment at a large, geographically distributed company. This environment hosts
SharePoint My Sites that connect employees with one another and the information that
they need. Employees use this environment to present personal information such as
areas of expertise, past projects, and colleagues to the wider organization. The
environment also hosts personal sites and documents for viewing, editing, and
collaboration. My Sites are integrated with Active Directory Domain Services (AD DS) to
provide a central location that can be accessed from the browser and various client
applications.
As many as 72,000 unique users visit the environment on a busy day, generating up to
180 requests per second (RPS) during peak hours. Because this is an intranet site, all
users are authenticated.
The information that is provided in this document reflects the enterprise social
environment on a typical day.
Specifications
This section provides detailed information about the hardware, software, topology, and
configuration of the case-study environment.
Hardware
207
This section provides details about the server computers that were used in this
environment.
Hinweis:
This environment is scaled to accommodate pre-release builds of SharePoint Server
2010 and other products. Hence, the hardware deployed has larger capacity than
necessary to serve the demand typically experienced by this environment. This hardware
is described only to provide additional context for this environment and serve as a
starting point for similar environments.
It is important to conduct your own capacity management based on your planned
workload and usage characteristics. For more information about the capacity
management process, see Kapazitätsverwaltung und Größengestaltung für SharePoint
Server 2010 (Übersicht).
Web Servers
There are three Web servers in the farm, each with identical hardware. Two serve
content, and the third is a dedicated search crawl target.
Web Server
WFE1-3
Processor(s)
2 quad core @ 2.33 GHz
RAM
16 GB
Operating system
Windows Server 2008, 64 bit
Size of the SharePoint drive
400 GB
Number of network adapters
2
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Load balancer type
Hardware load balancing
Software version
SharePoint Server 2010 (pre-release
version)
Services running locally
Central Administration
Microsoft SharePoint Foundation Incoming
E-Mail
Microsoft SharePoint Foundation Web
Application
Microsoft SharePoint Foundation Workflow
Timer Service
Search Query and Site Settings Service
SharePoint Server Search
208
Web Server
WFE1-3
Services consumed from a federated
services farm
User Profile Service
Web Analytics Web Service
Business Data Connectivity Service
Managed Metadata Web Service
Application Server
There are two application servers in the farm, each with identical hardware.
Application Server
APP1-4
Processor(s)
2 quad core @ 2.33 GHz
RAM
16 GB
OS
Windows Server 2008, 64 bit
Size of the SharePoint drive
400 GB
Number of network adapters
1
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Load balancer type
Hardware load balancing
Software version
SharePoint Server 2010 (pre-release
version)
Services running locally
Office Web Apps
Excel
PowerPoint
Secure Store
Usage and Health
State Service
Database Servers
There is a SQL cluster with two database servers, each with identical hardware. One of
the servers is active and the other is passive for redundancy.
Database Server
DB1-2
Processor(s)
4 quad core @ 2.4 GHz
RAM
64 GB
209
Database Server
DB1-2
Operating system
Windows Server 2008, 64 bit
Storage and geometry
(1.25 TB * 6)
Disk 1-4: SQL Data
Disk 5: Logs
Disk 6: TempDB
Number of network adapters
2
Network adapter speed
1 @ 100MB, 1 @ 1GB
Authentication
Windows NTLM
Software version
SQL Server 2008
Topology
The following diagram shows the topology for this farm.
210
Configuration
211
The following table enumerates settings that were changed that affect performance or
capacity in the environment.
Setting
Value
Notes
Usage Service:
5 days The default is 14 days. Lowering this setting can save
disk space on the server where the log files are
Trace Log – days to store
stored.
log files (default: 14 days)
QueryLoggingThreshold 1
The default is 5 seconds. Lowering this setting can
second
save bandwidth and CPU on the database server.
Microsoft SharePoint
Foundation Database –
configure
QueryLoggingThreshold
to 1 second
1
Database Server –
Default Instance
Max degree of parallelism
The default is 0. To ensure optimal performance, we
strongly recommend that you set max degree of
parallelism to 1 for database servers that host
SharePoint Server 2010 databases. For more
information about how to set max degree of
parallelism, see max degree of parallelism
Option(http://go.microsoft.com/fwlink/?LinkId=189030).
Workload
This section describes the workload, which is the demand on the farm that includes the
number of users, and the usage characteristics.
Workload Characteristics
Value
Average Requests per Second (RPS)
64
Average RPS at peak time (11 AM-3 PM)
112
Total number of unique users per day
69,814
Average concurrent users
639
Maximum concurrent users
1186
Total # of requests per day
4,045,677
This table shows the number of requests for each user agent.
User Agent
Requests
212
Percentage of
Total
User Agent
Requests
Percentage of
Total
Outlook Social Connector Browser 1,808,963
44.71%
Search (crawl)
704,569
17.42%
DAV
459,491
11.36%
OneNote
266,68
6.59%
Outlook
372,574
9.21%
Browser
85,913
2.12%
Word
38,556
0.95%
Excel
30,021
0.74%
Office Web Applications
20,314
0.50%
SharePoint Workspaces
19,017
0.47%
Dataset
This section describes the case study farm dataset that includes database sizes and
Search indexes.
Dataset Characteristics
Value
Database size (combined)
1.5 TB
BLOB size
1.05 TB
Number of content databases
64
Number of Web applications
1
Number of site collections
87,264
Number of sites
119,400
Search index size (number of items)
5.5 million
Health and Performance Data
This section provides health and performance data that is specific to the case study
environment.
General Counters
213
Metric
Value
Availability (uptime)
99.61%
Failure Rate
0.39%
Average memory used
0.79 GB
Maximum memory used
4.53 GB
Search Crawl % of Traffic (Search client
requests / total requests)
17.42%
The following charts show average CPU utilization and latency for this environment.
214
In this document, latency is divided into four categories. The 50th percentile latency is
typically used to measure the server‘s responsiveness. It means that half of the requests
are served within that response time. The 95th percentile latency is typically used to
measure spikes in server response times. It means that 95% of requests are served
within that response time, and therefore, 5% of the requests experience slower response
times.
Database Counters
215
Metric
Value
Read/Write Ratio (IO Per Database)
99.854 : 0.146
Average Disk queue length
8.702
Disk Queue Length: Reads
30.518
Disk Queue Length: Writes
4.277
Disk Reads/sec
760.886
Disk Writes/sec
180.644
SQL Compilations/second
3.129
SQL Re-compilations/second
0.032
SQL Locks: Average Wait Time
125 ms
SQL Locks: Lock Wait Time
33.322 ms
SQL Locks: Deadlocks Per Second
0
SQL Latches: Average Wait Time
0 ms
SQL Cache Hit Ratio
20.1%
216
Ergebnisse der Leistungs- und
Kapazitätstests und Empfehlungen
(SharePoint Server 2010)
Dieser Abschnitt enthält eine Reihe von Whitepaper und Artikeln, in denen die
Auswirkungen bestimmter Featuregruppen von Microsoft SharePoint Server 2010 auf
Leistung und Kapazität beschrieben werden. In diesen Whitepaper und Artikeln finden
Sie Informationen zu den Leistungs- und Kapazitätsmerkmalen des Features und wie
diese von Microsoft getestet wurden:
 Testfarmmerkmale

Testergebnisse

Empfehlungen

Problembehandlung bei Leistung und Skalierbarkeit
Hinweis:
Die Whitepaper werden aktualisiert und als Artikel neu veröffentlicht. Wenn Sie ein
Whitepaper von dieser Seite herunterladen, sind bei der Neuveröffentlichung als Artikel
möglicherweise aktualisierte Informationen verfügbar.
Vor der Lektüre dieser Whitepaper und Artikel sollten Sie unbedingt mit den wichtigsten
Konzepten der Kapazitätsverwaltung in SharePoint Server 2010 vertraut sein. Weitere
Informationen finden Sie unter Capacity management and sizing for SharePoint Server
2010 (in englischer Sprache).
In der folgenden Tabelle werden die verfügbaren Whitepaper und Artikel beschrieben.
Wenn der Inhalt als Whitepaper verfügbar ist, ist dieses unter Ergebnisse der Leistungsund Kapazitätstests und Empfehlungen für SharePoint Server 2010 als Microsoft WordDokument verfügbar.
Thema
Beschreibung
Access Services
Enthält Informationen, wie sich die Verwendung von Access
Services auf Topologien mit SharePoint Server 2010
auswirkt. Den Artikel finden Sie unter Estimate performance
and capacity requirements for Access Services in
SharePoint Server 2010 (in englischer Sprache).
Business Connectivity
Services
Enthält Informationen zum Speicherbedarf von Business
Connectivity Services in Topologien mit SharePoint Server
2010. Laden Sie dieses Whitepaper herunter
(BCSCapacityPlanningDoc.docx).
217
Thema
Beschreibung
Übersicht über Caches
Enthält Informationen, wie die drei SharePoint Server 2010Caches zur Umsatzsteigerung und damit zur Erfüllung Ihrer
unternehmerischen Anforderungen beitragen. Laden Sie
dieses Whitepaper herunter
(SharePointServerCachesPerformance.docx).
Excel Services in Microsoft Enthält Anweisungen zur Planung von Excel Services in
SharePoint Server 2010
Microsoft SharePoint Server 2010. Den Artikel finden Sie
unter Estimate performance and capacity requirements for
Excel Services in SharePoint Server 2010 (in englischer
Sprache).
InfoPath Forms Services
Enthält Informationen zum Speicherbedarf von InfoPath
Forms Services in Topologien mit SharePoint Server 2010.
Laden Sie dieses Whitepaper herunter
(InfoPath2010CapacityPlanningDoc.docx).
Umfangreiche Listen
Enthält Hinweise zur Leistung umfangreicher
Dokumentbibliotheken und Listen. Dieses Dokument gilt
speziell für SharePoint Server 2010, wobei jedoch die
behandelten Drosselungslimits auch für Microsoft
SharePoint Foundation 2010 gelten. Laden Sie dieses
Whitepaper herunter
(DesigningLargeListsMaximizingListPerformance.docx).
Umfangreiche
Dokumentrepositorys
Enthält Informationen zur Leistung von umfangreichen
Dokumentrepositorys im Hinblick auf SharePoint Server
2010. Laden Sie dieses Whitepaper herunter
(LargeScaleDocRepositoryCapacityPlanningDoc.docx).
Meine Website und
thematische
Computerfeatures
Enthält Informationen zum Speicherbedarf von Meine
Website und sonstigen thematischen Computerfeatures in
Topologien mit SharePoint Server 2010. Laden Sie dieses
Whitepaper herunter
(MySitesSocialComputingCapacityPlanningDoc.docx).
Office Web Apps
Enthält Informationen zum Speicherbedarf von Office Web
Apps in Topologien mit SharePoint Server 2010. Laden Sie
dieses Whitepaper herunter
(OfficeWebAppsCapacityPlanningDoc.docx).
PerformancePoint-Dienste
Enthält Informationen zum Speicherbedarf von
PerformancePoint-Diensten in Topologien mit SharePoint
Server 2010. Den Artikel finden Sie unter Schätzen der
Leistungs- und Kapazitätsanforderungen für
PerformancePoint-Dienste
Suchdienst
Enthält Kapazitätsplanungsinformationen für
unterschiedliche Bereitstellungen des Suchdiensts in
SharePoint Server 2010, einschließlich kleiner, mittlerer und
218
Thema
Beschreibung
großer Farmen. Laden Sie dieses Whitepaper herunter
(SearchforSPServer2010CapacityPlanningDoc.docx).
Falls Sie FAST Search Server 2010 for SharePoint als
Lösung für die Suche in Unternehmen verwenden, finden
Sie weitere Informationen unter Plan for performance and
capacity (FAST Search Server 2010 for SharePoint).
Visio Services
Enthält Informationen zum Speicherbedarf von Visio
Services in Topologien mit SharePoint Server 2010. Laden
Sie dieses Whitepaper herunter
(VisioServicesCapacityPlanningDoc.docx).
Web Analytics
Enthält Informationen zum Speicherbedarf des Web
Analytics-Diensts in Topologien mit SharePoint Server
2010. Die Artikel finden Sie unter Capacity requirements for
Web Analytics Shared Service in SharePoint Server 2010
(in englischer Sprache).
Web Content Management Enthält Informationen zur Leistungs- und Kapazitätsplanung
für eine Web Content Management-Lösung. Den Artikel
finden Sie unter Schätzen der Leistungs- und
Kapazitätsanforderungen für Web Content Management in
SharePoint Server 2010.
Word Automation Services
Enthält Informationen zur Kapazitätsplanung für Word
Automation Services in SharePoint Server 2010. Laden Sie
dieses Whitepaper herunter
(WASCapacityPlanningDoc.docx).
Workflow
Enthält Informationen zum Speicherbedarf von Workflow in
Topologien mit SharePoint Server 2010. Laden Sie dieses
Whitepaper herunter
(WorkflowCapacityPlanningDoc.docx).
219
Estimate performance and capacity
requirements for Access Services in
SharePoint Server 2010 (in englischer
Sprache)
This article provides guidance on the footprint that usage of Access Services in Microsoft
SharePoint Server 2010 has on topologies that are running Microsoft SharePoint Server
2010.
In this article:
 Test farm characteristics

Test results

Recommendations

Troubleshooting
Test farm characteristics
This section describes the dataset that was used during the testing; the workloads that
were placed on the product during performance gathering; the hardware that was used
during the testing; and the topology for how that hardware was deployed.
Dataset
Access Services capacity and performance is highly dependent on the makeup of the
applications that are hosted on the service. The size of tables and the complexity of
queries often have the most effect on capacity and performance. The testing used
representative sizes and complexities, but every application and dataset is different. The
capacity and performance will depend on the applications that are being used, their
specific complexity, and the data size.
To evaluate the capacity profile, Access Services applications were simulated on a farm
dedicated to Access Services (no other SharePoint tests were running). The farm
contained the following representative sites:
 1,500 Access Services applications that have a ―Small‖ size profile; 100 items
maximum per list.

1,500 Access Services applications that have a ―Medium‖ size profile; 2,000 items
maximum per list.

1,500 Access Services applications that have a ―Large‖ size profile; 10,000 items
maximum per list.
Each application is made up of multiple lists, and the other lists are appropriately sized
based on this largest list. Access Services can handle more data than 10,000 items. This
number for the ―Large‖ profile was chosen because it was expected that larger
applications would not be common.
220
The applications were evenly distributed among the following applications:
 Contacts A simple contact management application, dominated by a single list.

Projects A simple task and project tracking applications, dominated by two lists
(projects and tasks associated with each project).

Orders A simple order entry system, similar to the Northwind Traders sample of
Microsoft Access, but scaled down, and included many interrelated lists (orders,
order details, invoices, invoice details, purchase orders, purchase order details, and
so on).
Workload
To simulate application usage, workloads were created to perform one or more of the
following operations:
 Opening forms

Paging through the forms

Filtering and sorting data sheets

Updating, deleting and inserting records

Publishing application
 Render reports
Each workload includes ―think time‖ between user actions, ranging from 5 to 20 seconds.
This differs from other SharePoint capacity planning documents. Access Services is
stateful; memory cursors and record sets were maintained between user interactions. It
was important to simulate a full user session and not merely individual requests. For a
single user workload, there is an average of two requests per second.
The following table shows the percentages used to determine which application and
which size of application to use.
Small
Medium
Large
Contacts
16%
10%
9%
Projects
18%
12%
10%
Orders
11%
8%
6%
Green and red zone definitions
For each configuration, two tests were ran to determine a ―green zone‖ and a ―red zone.‖
The green zone is the recommended throughput that can be sustained. The red zone is
the maximum throughput that can be tolerated for a short time, but should be avoided.
The green zone was defined as a point at which the test being run consumes at most half
the bottlenecking resource. In this case, the bottlenecking resource was %CPU on any of
the three tiers: front-end Web server, application server (Access Data Services), or
database server (SQL Server). First, the bottleneck was identified for a particular
configuration. If the bottleneck was Access Data Services CPU, we made sure that the
green zone test consumed CPU on the Access Data Services computers in a range
between 40 and 50 percent.
221
For the red zone, a point was selected at which the maximum throughput was reached.
This proved to be a CPU range between 80 and 90 percent. When searching for
bottleneck, we looked at %CPU, memory usage (private bytes), disk queue length,
network I/O, and other resources that could result in a bottleneck.
Both the green and red zone tests were run for 1 hour at a fixed user load.
Your results might vary
The specific capacity and performance figures presented in this article will differ from
figures in a real-world environment. This simulation is only an estimate of what actual
users might do. The figures presented are intended to provide a starting point for the
design of an appropriately scaled environment. After you have completed the initial
system design, you should test the configuration to determine whether the system will
support the factors in your environment.
Hardware setting and topology
Lab Hardware
To provide a high level of test-result detail, several farm configurations were used for
testing. Farm configurations ranged from one to four front-end Web servers, one to four
application servers (if there is Access Services or Access Data Services), and a single
database server computer that is running Microsoft SQL Server 2008. In addition, testing
was performed by using four client computers. All server computers were 64-bit. All client
computers were 32-bit.
The following table lists the specific hardware that was used for the testing.
Machine role
CPU
Memory
Network Disk
Front-end Web server
2 processor, 4 core 2.33 GHz 8 GB
1 gig
2
spindles
RAID 5
Application server (Access
Data Services)
2 processor, 4 core 2.33 GHz 8 GB
1 gig
2
spindles
RAID 5
Database server (SQL
Server)
4 processor, 4 core 2.6 GHz 32GB
1 gig
Direct
Attached
Storage
(DAS)
attached
RAID 0
for each
Logical
Unit
Number
(LUN)
Topology
From our experience, CPU on the application sever tier, where Access Data Services is
running, is an important limiting factor for throughput. We varied our topology by adding
222
additional Access Data Services computers until it was no longer the bottleneck, and then
added a front-end Web server to obtain even more throughput.
 1x1: One front-end Web server computer to one Access Data Services computer

1x2: One front-end Web server computer to two Access Data Services computers

1x3: One front-end Web server computer to three Access Data Services computers

1x4: One front-end Web server computer to four Access Data Services computers

2x1: Two front-end Web server computers to one Access Data Services computer

2x2: Two front-end Web server computers to two Access Data Services computers
 2x4: Two front-end Web server computers to four Access Data Services computers
The computer running SQL Server is a relatively strong computer and at no time did it
become the bottleneck (although it started to approach CPU saturation on our 2x4 test),
so we did not vary this in our topologies. Depending on the queries that are a part of a
real-world application mix, it is expected that the database server (SQL Server) tier could
become the bottleneck.
Reporting Services was running in connected mode for all of our tests, running in the
application server (Access Data Services) tier.
Test results
The following tables show the test results of Access Services. For each group of tests,
only certain specific variables are changed to show the progressive impact on farm
performance.
All the tests reported in this article were conducted with think time or wait time. This
differs from the capacity planning results for other parts of SharePoint.
For information about bottlenecks of Access Services, see Common bottlenecks and their
causes later in this article.
Overall scale
The following table and graph summarize the impact of adding additional front-end Web
servers and dedicated Active Data Services computers to the farm. These throughput
numbers are specifically for the Active Data Services computers. They do not reflect the
impact on the overall farm.
Topology
Baseline solution maximum (RPS)
Baseline
recommended
(RPS)
1x1
25
15
1x2
54
29
1x3
82
45
1x4
88
48
2x1
25
15
2x2
55
29
223
Topology
Baseline solution maximum (RPS)
Baseline
recommended
(RPS)
2x4
116
58
224
Recommended results
The following graph shows the results for recommended sustainable throughput.
225
As described earlier in this article, adding the fourth Access Data Services computer
shifts the bottleneck to the front-end Web server, and that adding a second front-end
Web server resolves the resource constraint on the front-end Web server tier. This would
imply, that 1x1, 1x2, and 1x3 are reasonable configurations. However, when the fourth
Access Data Services computer is added, a front-end Web server should also be added.
Because scaling is in a linear manner (straight line between from 1x1 to 1x4), it can be
assumed that the addition of a seventh Access Data Services computer would also imply
the addition of a third front-end Web server, and so on, to satisfy the needs of the farm.
Remember that these results are based on a simulated work load only, and that an actual
deployment should be monitored to find the point at which additional front-end Web
servers are needed to support additional Access Data Services computers. Also, the
front-end Web servers are dedicated to Access Services, and in reality the front-end Web
servers are likely shared with other SharePoint workloads. The following graph shows the
results.
226
The following graph shows the response time at this throughput level. The response time
is very fast, at less than ¼ second on average per request.
227
These results show that the SQL Server computer was not a bottleneck, because adding
a second front-end Web server resolved the resource shortage, and the SQL Server CPU
was always less than 50 percent. However, be aware that the instance of SQL Server is
shared with other SharePoint services and SharePoint itself, and so the cumulative effect
might drive CPU or disk I/O queue lengths to the point that they do become a bottleneck.
Maximum
The following graph shows the results, in which throughput was pushed beyond what
could be sustained.
In this graph we see that again a second front-end Web server was needed to maximum
the usefulness of the fourth Access Data Services computer. Again, your results might
vary, because this is highly dependent on the applications and their usage patterns.
228
In this case, the response time is increased, as the overall system is under stress.
However, these levels are still approximately one second, and acceptable to most users.
It might seem odd that with four Access Data Services computers, two front-end Web
servers have an increased response time than one front-end Web server. This is
because the overall throughput of the system is increased with two front-end Web
servers.
229
SQL Server is again not a limiting factor here, because adding the second front-end Web
server put us back on a linear scaling line. However, we are reaching almost 90 percent
CPU usage on the instance of SQL Server. Therefore, there is very little headroom
remaining. If we were to add a fifth Access Data Services computer, the SQL Server
computer likely would have become the bottleneck.
230
Detailed results
The following tables show the detailed results for the recommended configurations.
Overall
1x1
1x2
1x3
Req/Sec
14.96
28.76 45.22 48.01 14.85 28.77 58.02
Tests/Sec
2.00
3.81
Average Latency
235.80
241.21 247.21 244.87 240.70 242.26 250.94
6.11
1x4
6.42
2x1
1.99
2x2
3.81
2x4
7.80
Average front- 1x1
end Web
server tier
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
24.40
41.02
43.62
6.31
12.48
26.18
13.82
231
Average front- 1x1
end Web
server tier
1x2
Max w3wp
9.46E+08
Private Bytes
2.31E+08 1.49E+09 1.55E+09 8.43E+08 9.84E+08 1.19E+09
Average
1x1
application
server
(Access Data
Services) tier
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
46.30
42.83
43.74
34.51
46.56
43.45
42.13
%CPU w3wp 33.61
31.15
30.71
24.29
33.48
31.64
29.72
%CPU RS
7.94
9.17
6.84
9.03
8.02
8.71
8.62
1x3
1x4
2x1
2x2
2x4
Max total
4.80E+09
Private Bytes
4.89E+09 4.91E+09 4.62E+09 5.32E+09 4.82E+09 5.07E+09
Max w3wp
2.10E+09
Private Bytes
1.97E+09 2.04E+09 1.86E+09 2.00E+09 2.00E+09 2.07E+09
Max RS
1.78E+09
Private Bytes
2.00E+09 1.97E+09 1.86E+09 2.30E+09 1.89E+09 2.02E+09
Database
server (SQL
Server) tier
(single
computer)
1x1
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
12.07
18.64
32.53
36.05
9.89
21.42
47.46
Avg Private
Bytes
2.96E+10
3.22E+10 3.25E+10 3.25E+10 2.89E+10 3.22E+10 3.25E+10
Max Private
Bytes
3.26E+10
3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10
Avg Disk
0.74
Queue Length
Total
1.18
1.64
1.77
0.67
1.24
The following tables show the detailed results for the maximum configurations.
232
2.18
Overall
1x1
1x2
1x3
Req/Sec
14.96
28.76 45.22 48.01 14.85 28.77 58.02
Tests/Sec
2.00
3.81
Average Latency
235.80
241.21 247.21 244.87 240.70 242.26 250.94
6.11
1x4
6.42
2x1
1.99
2x2
3.81
2x4
7.80
Average front- 1x1
end Web
server tier
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
24.40
41.02
43.62
6.31
12.48
26.18
13.82
Max w3wp
9.46E+08
Private Bytes
2.31E+08 1.49E+09 1.55E+09 8.43E+08 9.84E+08 1.19E+09
Average
1x1
application
server
(Access Data
Services) tier
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
46.30
42.83
43.74
34.51
46.56
43.45
42.13
%CPU w3wp 33.61
31.15
30.71
24.29
33.48
31.64
29.72
%CPU RS
7.94
9.17
6.84
9.03
8.02
8.71
8.62
Max total
4.80E+09
Private Bytes
4.89E+09 4.91E+09 4.62E+09 5.32E+09 4.82E+09 5.07E+09
Max w3wp
2.10E+09
Private Bytes
1.97E+09 2.04E+09 1.86E+09 2.00E+09 2.00E+09 2.07E+09
Max RS
1.78E+09
Private Bytes
2.00E+09 1.97E+09 1.86E+09 2.30E+09 1.89E+09 2.02E+09
Database
server (SQL
Server) tier
(single
computer)
1x1
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
12.07
18.64
32.53
36.05
9.89
21.42
47.46
Avg Private
Bytes
2.96E+10
3.22E+10 3.25E+10 3.25E+10 2.89E+10 3.22E+10 3.25E+10
233
Database
server (SQL
Server) tier
(single
computer)
1x1
1x2
Max Private
Bytes
3.26E+10
3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10
Avg Disk
0.74
Queue Length
Total
1.18
1x3
1x4
1.64
1.77
2x1
0.67
2x2
1.24
2x4
2.18
Recommendations
This section provides general performance and capacity recommendations.
Access Services capacity and performance is highly dependent on the makeup of the
applications that are hosted on the service. The size of tables and the complexity of
queries often have the most effect. The testing used representative sizes and
complexities, but every application and dataset is different. Therefore, the capacity and
performance will depend on the applications in use, their specific complexity, and the
data size.
Hardware recommendations
Access Services uses standard hardware for both front-end Web servers and application
servers; no special requirements are necessary. General SharePoint Server 2010
guidelines for CPU number, speed, and memory are applicable for computers in the
application server (Access Data Services) tier.
Scaled-up and scaled-out topologies
To increase the capacity and performance of one of the starting-point topologies, you can
do one of two things. You can either scale up by increasing the capacity of your existing
servers or scale out by adding additional servers to the topology. This section describes
the general performance characteristics of several scaled-out topologies.
The sample topologies represent the following common ways to scale out a topology for
an Access Services scenario:
 To provide for more user load, check the CPU for the existing Access Services
application servers. Add additional CPUs or cores, or both, to these servers if it is
possible. Add more Access Services server computers as needed. This can be done
to the point that the front-end Web server has become the bottleneck, and then add
front-end Web servers as needed.

In our tests, memory on the front-end Web server tier and application server (Access
Data Services) tier was not a bottleneck. Depending on the size of the result sets,
memory could become an issue. However, we do not expect that to be the norm.
Track the private bytes for the Access Data Services w3wp process, as described
here.
234

In our tests, SQL Server was not a bottleneck. However, our tests were run in
isolation from other SharePoint Server 2010 services. SQL Server CPU and disk I/O
should be monitored and additional servers or spindles added as needed.
Performance-related Access Services settings
One way to control the performance characteristics of Access Services is to limit the size
and complexity of queries that can be performed. Access Services provides a set of
configurable throttles for controlling queries. Each of the following queries can be set
through SharePoint Central Administration. (In the Application Management section,
click Manage Service Applications, and then click Access Services.)
In general, how much data that has to be retrieved from SharePoint to perform a query
will have a significant effect on performance. This can be controlled in several ways.
First, the inputs to a query can be limited:
 Maximum Sources per Query
 Maximum Records per Table
Second, the resulting size of a query can be limited:
 Maximum Columns per Query

Maximum Rows per Query
 Allow Outer Joins
In addition to the size of the query (data size in and out), the processing complexity on
the data can be controlled, to reduce the CPU load on the application server (Access
Data Services) tier:
 Maximum Calculated Columns per Query
 Maximum Order by Clauses per Query
Obviously, the previous settings will affect the applications that can be run on the server.
For example, if an application is written with 40 output columns from a query, and the
settings are below this level, the application will throw a runtime error. A balance between
user need and acceptable performance must be struck, and is highly dependent on the
kind of Access applications that are expected to be run on the farm.
One additional, more extreme measure can be taken. SharePoint Server 2010 supports a
set of query operations natively, which Access Services augments to cover a broader set
of application scenarios. For Access Services to improve queries from SharePoint, there
is the potential that a large amount of data might have to be retrieved from the
SharePoint content database. Instead, Access Services can be set to stick with only
query operations, which can be natively supported by SharePoint. Therefore, avoiding
the data fetch required for more complex operations:
 Allow Non-Remotable Queries
Optimizations
Common bottlenecks and their causes
During performance testing, several different common bottlenecks were revealed. A
bottleneck is a condition in which the capacity of a particular constituent of a farm is
reached. This causes a plateau or decrease in farm throughput.
The table in Troubleshooting later in this article lists some common bottlenecks and
describes their causes and possible resolutions.
Performance monitoring
235
To help you determine when you have to scale up or scale out the system, use
performance counters to monitor the health of the system. Use the information in the
following tables to determine which performance counters to monitor, and to which
process the performance counters should be applied.
Front-end Web servers
The following table shows performance counters and processes to monitor for Web
servers in your farm.
Performance counter
Apply to object
Notes
% Processor Time
Processor(_Total)
Shows the
percentage of
elapsed time that
this thread used
the processor to
execute
instructions.
Private Bytes
Process(w3wp)
This value should
not approach the
Max Private
Bytes set for
w3wp processes.
Iif it does,
additional
investigation is
needed into what
component is
using the
memory.
Access Data Services
The following table shows performance counters and processes to monitor for application
servers, or Access Data Services (Access Data Services) in this case, within your farm.
Performance counter
Apply to object
Notes
% Processor Time
Processor(_Total)
Shows the
percentage of
elapsed time that
this thread used
the processor to
execute
instructions.
% Processor Time
Process(w3wp)
The Access Data
Services runs
within its own
236
Performance counter
Apply to object
Notes
w2wp process,
and it will be
obvious which
w2wp process
this is as it will be
getting the bulk
of the CPU time.
Avg. Disk Queue Length
PhysicalDisk(_Total)
% Processor Time
Process(ReportingServicesService) Reports are
handled by SQL
Server Reporting
Services. If too
many reports are
being run, or if
the reports are
very complex,
then the CPU
and Private
Bytes for this
process will be
high.
Private Bytes
Process(w3wp)
Private Bytes
Process(ReportingSrevicesService) Reports are
handled by SQL
237
Watch for too
much disk writing
because of
logging.
Access Services
caches the
results of queries
in memory, until
the user’s
session expires
(the time-out for
which is
configurable). If
a large amount
of data is being
processed
through the
Access Data
Services,
memory
consumption for
the Access Data
Services’ w3wp
will increase.
Performance counter
Apply to object
Notes
Server Reporting
Services. If too
many reports are
being run, or
reports are very
complex, the
CPU and Private
Bytes for this
process will be
high.
Database servers
The following table shows performance counters and processes to monitor for database
servers in your farm.
Performance counter
Apply to object
Notes
% Processor Time
Processor(_Total)
Shows the
percentage of
elapsed time that
this thread used
the processor to
execute
instructions.
% Processor Time
Process(sqlservr)
Average values
larger than 80
percent indicate
that processor
capacity on the
database server
is insufficient.
Private Bytes
Process(sqlservr)
Shows the
average amount
of memory being
consumed by
SQL Server.
Avg. Disk Queue Length
PhysicalDisk(_Total)
Shows the
average disk
queue length; the
database
requests waiting
to be committed
to disk. This is
often a good
indicator that the
238
Performance counter
Apply to object
Notes
instance of SQL
Server is
becoming
overloaded, and
that possibly
additional disk
spindles would
help distribute
the load.
Troubleshooting
The following table lists some common bottlenecks and describes their causes and
possible resolutions.
Bottleneck
Cause
Resolution
Access Data
Services CPU
Access Services
Increase the number of CPUs or cores, or
depends on a large both, in the existing Access Data Services
amount of
computers. Add additional Access Data
processing in the
Services computers if possible.
application server
tier. If a 1x1, 1x2, or
1x3 configuration is
used, the first
bottleneck
encountered will
likely be the CPU on
the Access Data
Services servers.
Web server CPU
usage
When a Web server This issue can be resolved in one of two ways.
is overloaded with You can add more Web servers to the farm to
user requests,
distribute user load, or you can scale up the
average CPU usage Web server or servers by adding higher-speed
will approach 100
processors.
percent. This
prevents the Web
server from
responding to
requests quickly and
can cause timeouts
and error messages
on client computers.
Database server
disk I/O
When the number of Distributing data files across multiple physical
I/O requests to a
drives allows for parallel I/O. The blog
239
Bottleneck
Cause
Resolution
hard disk exceeds SharePoint Disk Allocation and Disk I/O
(http://go.microsoft.com/fwlink/?LinkId=129557)
the disk’s I/O
contains useful information about resolving
capacity, the
disk I/O issues.
requests will be
queued. As a result,
the time to complete
each request
increases.
Reporting Services The Reporting
CPU utilization
Services process is
using a large share
of the CPU
resources.
Dedicate a computer to Reporting Services,
taking load from the application server (Access
Data Services) tier (connected mode) or the
front-end Web server tier (local mode).
240
Estimate performance and capacity
requirements for Excel Services in
SharePoint Server 2010 (in englischer
Sprache)
This article describes the effects of using Excel Services in Microsoft SharePoint Server
2010 on topologies running Microsoft SharePoint Server 2010. You can use this
information to better scale your deployments based on your latency and throughput
requirements.
Hinweis:
It is important to be aware that the specific capacity and performance figures presented in
this article will differ from the figures in real-world environments. The figures presented
are intended to provide a starting point for the design of an appropriately scaled
environment. After you have completed your initial system design, test the configuration
to determine whether the system will support the needs of your environment.
In this article:
 Test farm characteristics

Test Results
 Recommendations
For general information about how to plan and run your capacity planning for SharePoint
Server 2010, see Capacity management and sizing for SharePoint Server 2010 (in
englischer Sprache).
Test farm characteristics
This section describes the dataset, workloads, hardware settings, topology, and test
definitions that were used during the performance and capacity testing of Excel Services.
Dataset
Excel Services capacity and performance is highly dependent on the makeup of the
workbooks that are hosted on the service. The size of the workbook and the complexity
of calculations have the most impact. Our testing used representative sizes and
complexities, but every workbook is different, and your capacity and performance
depends on the actual workbooks you use, and their specific size and complexity.
We simulated Excel workbooks on a farm dedicated to Excel to evaluate our capacity
profile. Note that no other SharePoint Server tests were running during our capacity
profile tests. Within this farm, we used three buckets of workbooks – Small, Large, and
Very Large – based on workbook size and complexity:
241
Workbook Characteristics
Small
Large
Very
Large
Sheets
1-3
1-5
1-20
Columns
10-20
10-500
101,000
Rows
10-40
10-10,000
10030,000
Calculated Cells
0-20%
0-70%
0-70%
Number of Formats
1-10
1-15
1-20
Tables
0-1
0-2
0-5
Charts
0-1
0-4
0-4
Workbook Uses External Data
0%
20%
50%
Workbook Uses a Pivot Table
0%
3%
3%
Workbook Uses Conditional
Formats
0%
10%
20%
This test farm included 2,000 SharePoint Server sites. Each site contained one small,
one large, and one very large workbook. The distribution of the workbooks on the
SharePoint Server pages was 10% small workbooks and 90% large and very large
workbooks. Additionally, the test farm dataset included SharePoint Server pages that
contained 1-5 Excel Web Parts.
Workload
To simulate application usage, workloads were created to perform one or more of the
following operations:
Action Mix
Small Workbook
Large Workbook
View
50%
70%
Edit
35%
15%
Collaborative Viewing
10%
10%
Collaborative Editing
5%
5%
In addition, 17% of all the workbooks included external data. For large and very large
workbooks that included external data, refreshes were performed 80% of the time; small
workbooks do not include external data.
Each workload includes think time between user actions of 10 seconds. Think time refers
to user action delays that simulate how long a user might take to perform the actions.
242
This differs from other SharePoint Server 2010 capacity planning documents. Excel
Services is stateful —the workbook is maintained in memory between user interactions
— making it important to simulate a full user session and not merely individual requests.
On average, there are 0.2 requests per second for a single user workload.
We randomly selected one of the 2,000 sites to run the test for each workload. We used
the percentages in the following table to select application and application size, within
that site.
Workbook Selection
Use Percentage
Small Workbook
30%
Large Workbook
55%
Dashboard
10%
Very Large Workbook
5%
Green and Red Zone definitions
For each configuration two zones were determined before throughput tests were
performed. One zone was the green zone or recommended zone in which throughput can
be sustained. The other zone was the red zone or maximum zone in which throughput
can be tolerated for a short time but should be avoided.
To determine our red and green zone user loads, we first conducted a step test and then
stopped when the following conditions were met:
 Green zone We stopped at the point when any of the computers in our farm (Web
front-end, Dienste für Excel-Berechnungen, or Microsoft SQL Server) exceeded 50%
CPU usage or the response time for the overall system exceeded 1 second.

Red Zone We stopped at the point where the successful RPS for the Dienste für
Excel-Berechnungen computers in the farm was at a maximum. Past this point, the
overall throughput for the farm started to decrease and/or we would start to see
failures from one of the tiers. Often the maximum private bytes in Dienste für ExcelBerechnungen would be exceeded when throughput was in the red zone.
After conducting the step tests, we retreated from these maximum values to run a longer
constant load test of 1 hour. We stopped the green zone test when 75% of the load was
used. We peaked in the red zone step test when we used 65% of the load. If the green
zone test was limited by memory, and the CPU usage percentage never exceeded 50%,
we instead used 75% of the load number calculated for the red zone.
The average response time was less than .25 seconds for both green and red zones, and
for both scale-out and scale-up tests.
Hardware Settings and Topology
This section describes the kinds of computer hardware we used in our lab and the farm
configuration topologies that we used in our tests.
Lab Hardware
Several farm configurations were used for our testing to provide a high level of test-result
detail. The farm configurations ranged from one to three Web front-end servers, one to
243
three application servers for Excel Services and Dienste für Excel-Berechnungen, and a
single database server computer that is running Microsoft SQL Server 2008. Additionally,
our tests used four client computers. All servers were 64-bit, and the client computers
were 32-bit.
The following table lists the specific hardware that we used for testing.
Machine Role
CPU
Memory
Network
Web front-end server
2 proc/4 core 2.33 GHz Intel
Xeon
8 GB
1 gig
Dienste für Excel-Berechnungen 2 proc/4 core 2.33 GHz Intel
Xeon
8 GB
1 gig
SQL Server
16 GB
1 gig
4 proc/4 core 2.6 GHz Intel
Xeon
Topology
Our testing experience indicates that memory on the Dienste für Excel-Berechnungen tier
and CPU on the Web front-end server tier are the most important limiting factors for
throughput. Be aware that your experience may vary. As a result, we varied the number
of computer servers in both tiers for the scale-out tests.
We deployed a topology of 1:1 for the Dienste für Excel-Berechnungen and Web frontend servers for the scale-up tests, and then varied the number of processors and
available memory in the Dienste für Excel-Berechnungen computers.
Dienste für Excel-Berechnungen is not especially demanding on the SQL Server instance
running SharePoint Server 2010, as the workbook is read a binary large object (BLOB)
from SharePoint Server 2010 and put in memory on the Dienste für Excel-Berechnungen
tier (and additionally disk cached). At no time did SQL Server become a bottleneck. For
all tests, bottleneck is defined as a state in which the capacity of a particular component
of a farm is reached.
Test Results
The following tables show the test results of Excel Services in Microsoft SharePoint
Server 2010. For each group of tests, only certain specific variables are changed to show
the progressive effect on farm performance.
Note that all the tests reported on in this article were conducted with think or wait time
(think time equals 10 seconds between user actions). This differs from the capacity
planning results for other parts of SharePoint Server 2010.
For information about Excel Services bottlenecks, see the Common bottlenecks and their
causes section in this article.
Overall Scale
The table here summarizes the effect of adding additional Web Front-End and dedicated
Dienste für Excel-Berechnungen computers to the farm. These throughput numbers are
specifically for the Dienste für Excel-Berechnungen computers, and do not reflect the
effect on the overall farm.
244
Topology
Baseline Maximum (RPS)
Baseline
Recommended
(RPS)
1x1
38
31
1x2
35
26
1x3
28
21
2x1
57
35
2x2
62
46
2x3
52
39
3x1
51
32
3x2
81
69
3x3
83
64
245
Recommended Results
The following chart shows our results for recommended sustainable throughput.
246
The previous chart shows that there is overhead associated with adding Web front-end
computers to the farm. However, this is offset as Dienste für Excel-Berechnungen
computers are added. A single Web front-end became the bottleneck after adding two
additional Dienste für Excel-Berechnungen computers. This Web front-end bottleneck
reversed any benefit that was gained from the additional capacity of adding a second and
third Dienste für Excel-Berechnungen computer. Also notice that three Web front-end
247
computers did not add any more throughput, as Dienste für Excel-Berechnungen became
the limiting factor.
Notice in the previous chart that as Web front-end computers are added, the CPU load
on each computer is reduced significantly. Note too, that with two Web front-end
computers and three Dienste für Excel-Berechnungen computers, the CPU load is
reaching the maximum seen for a single Web front-end computer. This implies that
adding another Dienste für Excel-Berechnungen computer would make the Web frontend tier the limiting factor. Remember that these results are for the ―recommended‖ load.
This is why the CPU load is maxing out at around 35% instead of at an increased level.
Maximum Results
The following chart shows our results for maximum peak throughput.
248
Similar to our recommended results, we see that a single Web front-end computer is the
limiting factor as we add a second and third Dienste für Excel-Berechnungen computer.
Also notice that exactly as with the recommended results, adding a third Web front-end
computer does not add to throughput as Dienste für Excel-Berechnungen is the limiting
factor after the second Web front-end computer is added.
249
The results in the previous chart show that multiple Web front-end computers do not
become as heavily loaded as a single Web front-end computer configuration. This
indicates that the Dienste für Excel-Berechnungen computers are the bottleneck after the
second Web front-end computer is added.
Detailed Results
This section shows details for the recommended and maximum results obtained in our
tests.
Recommended Results
The following tables show the recommended results of our tests.
Overall
1x1
1x2
250
1x3
2x1
2x2
2x3
3x1
3x2
3x3
Overall
1x1
1x2
1x3
Client Successful
RPS
30.56
34.55 31.67 26.03 45.94 68.37 20.71 38.82 63.70
Client Response
Time (sec.)
0.22
0.18 0.19 0.16 0.19 0.20 0.15 0.15 0.17
TPS
1.58
1.77 1.61 1.40 2.38 3.54 1.08 2.03 3.25
1x3
2x1
2x1
2x2
2x3
2x2
2x3
3x1
3x2
3x1 3x2
3x3
Web Front-end Tier
1x1
1x2
3x3
% CPU (average
over all Web Frontend computers
33.73
37.64 33.84 14.61 23.95 36.90 7.54 13.12 21.75
Dienste für 1x1
ExcelBerechnung
en Tier
1x2
1x3
2x1
2x2
2x3
3x1
3x2
3x3
% CPU
30.56
(average
over all
Dienste für
ExcelBerechnung
en
computers)
34.55
31.67
26.03
45.94
68.37
20.71
38.82
63.70
Peak
5.94E+ 5.82E+ 5.79E+ 5.87E+ 6.09E+ 5.92E+ 5.79E+ 5.91E+ 5.85E+
Private
09
09
09
09
09
09
09
09
09
Bytes
(maximum
over all
Dienste für
ExcelBerechnung
en
computers)
Maximum Results
The following tables show the maximum results of our tests.
Overall
1x1
1x2
251
1x3
2x1
2x2
2x3
3x1
3x2
3x3
Overall
1x1
1x2
Client Successful
RPS
37.85
56.70 51.17 35.19 62.04 81.31 27.79 51.62 82.58
Client Response
Time (sec.)
0.19
0.28 0.23 0.16 0.20 0.25 0.16 0.16 0.22
TPS
1.92
2.96 2.59 1.81 3.21 4.60 1.41 2.72 4.30
Web Front-end Tier
1x1
1x2
% CPU (average
41.08
over all Web Frontend computers
1x3
1x3
2x1
2x1
2x2
2x2
2x3
2x3
3x1
3x1
3x2
3x3
3x2
3x3
67.78 58.59 19.44 34.11 45.97 10.19 17.79 28.69
Dienste für 1x1
ExcelBerechnung
en Tier
1x2
1x3
% CPU
24.99
(average
over all
Dienste für
ExcelBerechnung
en
computers)
18…44 10.96
2x1
2x2
2x3
3x1
3x2
3x3
23.57
20.56
17.77
18.97
17.04
18.10
Peak
5.91E+ 5.85E+ 5.91E+ 5.88E+ 5.99E+ 6.502E+ 5.94E+ 5.94E+ 6.04E+
Private
09
09
09
09
09
09
09
09
09
Bytes
(maximum
over all
Dienste für
ExcelBerechnung
en
computers)
Scale Up Test results
We also measured the effect of adding CPUs and memory to the Dienste für ExcelBerechnungen tier. For these tests, a 1x1 topology was used.
252
Our results in the previous chart show that adding additional CPUs was helpful but did
not significantly affect the overall throughput.
253
The red zone line in the previous chart shows however, that adding memory does have a
significant effect on throughput, especially at peak times. In this test, the same hardware
was used throughout. However, the Maximum Private Bytes for the Excel Services
process was limited. Since workbooks are kept in memory, the size of the workbooks has
a significant effect on how many workbooks, and also how many users, any Dienste für
Excel-Berechnungen computer can support.
Recommendations
This section provides general performance and capacity recommendations for hardware,
Excel Services settings, common bottlenecks and troubleshooting.
Note that Excel Services capacity and performance is highly dependent on the makeup of
the workbooks that are hosted on the service. The size of the workbook and the
complexity of calculations have the most effect. Our testing used representative sizes
and complexities, but every workbook is different, and your capacity and performance
depends on the specific size and complexity of the workbooks you use.
254
Hardware Recommendations
Excel Services uses standard hardware for both Web front-end servers and application
servers, there are no special requirements. General SharePoint Server 2010 guidelines
on CPU number, speed, and memory are applicable for computers in the Dienste für
Excel-Berechnungen tier. Note that one of the first bottlenecks an Dienste für ExcelBerechnungen computer is likely to encounter is memory and this may require you to add
resources. Before you do, we recommend that you test with a representative set of
workbooks from your organization, as the size and complexity of workbooks have a large
effect on how much more capacity the addition of memory is likely to have.
To increase the capacity and performance of one of the starting-point topologies, you can
do one of two things. You can either scale up by increasing the capacity of your existing
servers or scale out by adding additional servers to the topology. This section describes
the general performance characteristics of several scaled-out topologies.
The sample topologies represent the following common ways to scale out a topology for
an Excel Services scenario:
 To provide for more user load, check the CPU and memory for the existing Excel
Services application servers. Add additional memory if the CPU is not a concern, or
add CPUs if memory is not a concern. If both memory and CPU are reaching their
upper limits, additional Dienste für Excel-Berechnungen computers may be
necessary. Add additional Dienste für Excel-Berechnungen or application servers
until the point that the Web front-end servers become the bottleneck, and then add
Web front-end servers as needed.

In our tests, SQL Server was not a bottleneck. Excel Services does not make large
demands on the database tier, as workbooks are read and written as whole
documents, and also workbooks are held in memory throughout the user‘s session.
Performance-Related Excel Services Settings
One of the ways to control the performance characteristics of Excel Services is to control
how memory is used. Each of the global settings in the following list are set through
SharePoint Server 2010 Central Administration > Application Management: Manage
Service Applications > Excel Services-Anwendung > Global Settings:
 Maximum Private Bytes — By default, Dienste für Excel-Berechnungen will use up
to 50% of the memory on the computer. If the computer is shared with other services,
it may make sense to lower this number. If the computer is not being shared and is
dedicated to Dienste für Excel-Berechnungen, and is indicating that memory may be
a limiting factor, increasing this number may make sense. In any event,
experimenting by adjusting this number can guide the administrator to making the
necessary changes in order to better scale up.

Memory Cache Threshold — Dienste für Excel-Berechnungen will cache unused
objects (for example, read-only workbooks for which all sessions have timed out) in
memory. By default, Dienste für Excel-Berechnungen will use 90% of the Maximum
Private Bytes for this purpose. Lowering this number can improve overall
performance if the server is hosting other services in addition to Dienste für ExcelBerechnungen. Increasing this number increases the chances that the workbook
being requested will already be in memory and will not have to be reloaded from the
SharePoint Server content database.
255

Maximum Unused Object Age — By default, Dienste für Excel-Berechnungen will
keep objects in the memory cache as long as possible. To reduce the Dienste für
Excel-Berechnungen memory usage, in particular with other services that are running
on the same computer, it may make more sense to impose a limit on how long
objects are cached in memory.
There are also settings available to control the maximum size of a workbook and the
lifetime of a session, which in turn control how long a workbook is held in memory. These
settings are associated with each trusted location and are not global. These settings can
be set through SharePoint Server 2010 Central Administration > Application
Management: Manage Service Applications > Excel Services-Anwendung > Trusted
Locations, and then edit the settings for each trusted location in the Workbook Properties
section on the Edit Trusted File Location page.

Maximum Workbook Size
 Maximum Chart or Image Size
By default, Dienste für Excel-Berechnungen is limited to 10 MB or smaller workbooks and
1 MB or smaller charts/images. Obviously using larger workbooks and larger
charts/images puts more strain on the available memory of the Dienste für ExcelBerechnungen tier computers. However, there may be users in your organization that
need these settings to be increased for Dienste für Excel-Berechnungen to work with
their particular workbooks.
 Session Timeout — By decreasing the session time out, memory is made available
for either the unused object cache or other services faster.

Volatile Function Cache Lifetime — Volatile functions are functions that can
change their value with each successive recalculation of the workbook, for example
date/time functions, random number generators, and so on. Because of the load this
could generate on the server, Dienste für Excel-Berechnungen does not recalculate
these values for each recalculation, instead caching the last values for a short time
period. Increasing this lifetime can reduce the load on the server. However, this
depends on having workbooks that use volatile functions.

Allow External Data — Dienste für Excel-Berechnungen can draw on external data
sources. However, the time that is required to draw upon the external source can be
significant, with potentially a large amount of data returned. If external data is
allowed, there are several additional settings that can help throttle the effect of this
feature.
Common bottlenecks and their causes
During performance testing, several different common bottlenecks were revealed.
Bottlenecks are defined as a state in which the capacity of a particular component of a
farm is reached. This causes a plateau or decrease in farm throughput.
The following table lists some common bottlenecks and describes their causes and
possible resolutions.
Troubleshooting performance and scalability
Bottleneck
Cause
Resolution
Dienste für Excel-Berechnungen
Memory
Excel Services holds each
workbook in memory throughout
Scale Up with
more memory in
256
Bottleneck
Cause
Resolution
the user's session. A large number
of workbooks, or large workbooks,
can cause Dienste für ExcelBerechnungen to consume all
available memory causing the
actually consumed "Private Bytes"
to exceed "Maximum Private
Bytes."
the Dienste für
ExcelBerechnungen
tier computers, or
Scale Out with
the addition of
more Dienste für
ExcelBerechnungen
computers. The
choice will partly
depend on if
CPU is also
reaching a
maximum.
Dienste für Excel-Berechnungen
CPU
Excel Services can depend on a
large amount of processing in the
application tier, depending on the
number and complexity of
workbooks.
Increase the
number of CPUs
and/or cores in
the existing
Dienste für
ExcelBerechnungen
computers, or
add Dienste für
ExcelBerechnungen
computers.
Web server CPU usage
When a Web server is overloaded
with user requests, average CPU
usage will approach 100 percent.
This prevents the Web server from
responding to requests quickly and
can cause timeouts and error
messages on client computers.
This issue can be
resolved in one
of two ways. You
can add Web
servers to the
farm to distribute
user load, or you
can scale up the
Web server or
servers by
adding faster
processors.
Performance monitoring
To help you determine when you have to scale up or scale out the system, use
performance counters to monitor the health of the system. Use the information in the
following tables to determine which performance counters to monitor, and to which
process the performance counters should be applied.
Front-end Web server
257
The following table shows performance counters and processes to monitor for front-end
Web servers in your farm.
Performance Counter
Apply to object
Notes
% Processor Time
Processor (w3wp)
Shows the
percentage of
elapsed time that
this thread used
the processor to
execute
instructions.
% Processor Time
Processor (_Total)
Shows the
percentage of
elapsed time that
all threads on the
server computer
that used the
processor to
execute
instructions.
Private Bytes
Process (w3wp)
This value should
not approach the
Max Private
Bytes set for
w3wp processes.
If it does,
additional
investigation is
needed into what
component is
using the
memory.
Dienste für Excel-Berechnungen
The following table shows performance counters and processes to monitor for application
servers, or in this case Dienste für Excel-Berechnungen, within your farm.
Performance Counter
Apply to object
Notes
% Processor Time
Processor (_Total)
Shows the
percentage of
elapsed time that
all threads on the
server that used
the processor to
execute
258
Performance Counter
Apply to object
Notes
instructions.
% Processor Time
Processor (w3wp)
The Dienste für
ExcelBerechnungen
runs within its
own w3wp
process, and it
will be obvious
which w3wp
process this is as
it will be getting
the bulk of the
CPU time.
Average Disk Queue Length
PhysicalDisk(_Total)
Watch for too
much disk writing
because of
logging.
Private Bytes
Process(w3wp)
Excel Services
caches
workbooks in
memory, until the
user's session
expires (the time
out for which is
configurable). If a
large amount of
data is being
processed
through the
Dienste für
ExcelBerechnungen,
memory
consumption for
the Dienste für
ExcelBerechnungen
w3wp will
increase.
SQL Server
As we have previously described, Excel Services is light on the SQL Server tier, as
workbooks are read once into memory on the Dienste für Excel-Berechnungen tier during
the user's session. Follow general SharePoint Server guidelines for monitoring and
troubleshooting of the SQL Server tier.
259
Schätzen der Leistungs- und
Kapazitätsanforderungen für
PerformancePoint-Dienste
In diesem Artikel werden die Auswirkungen durch die Verwendung von PerformancePoint
Services auf Topologien beschrieben, auf denen Microsoft SharePoint Server 2010
ausgeführt wird.
Hinweis:
Dabei sollten Sie beachten, dass die in diesem Artikel genannten spezifischen
Kapazitäts- und Leistungsangaben von den Werten in tatsächlichen Umgebungen
abweichen. Die hier dargestellten Werte sollen einen Ausgangspunkt für die Entwicklung
einer korrekt skalierten Umgebung bilden. Nachdem Sie Ihren ersten Systementwurf
erstellt haben, testen Sie die Konfiguration, um zu ermitteln, ob das System die Faktoren
in Ihrer Umgebung unterstützt.
Inhalt dieses Artikels
 Testfarmmerkmale

Testergebnisse
 Empfehlungen
Allgemeine Informationen zur Durchführung der Kapazitätsplanung für SharePoint Server
2010 finden Sie unter Capacity management and sizing for SharePoint Server 2010 (in
englischer Sprache).
Testfarmmerkmale
Dataset
Das Dataset setzte sich aus einem Firmenportal zusammen, das mithilfe von SharePoint
Server 2010 und PerformancePoint Services mit einem einzelnen Dashboard mittlerer
Größe erstellt wurde. Das Dashboard enthielt zwei Filter, die mit einer Scorecard, zwei
Diagrammen und einem Raster verbunden waren. Das Dashboard basierte auf einer
einzelnen Microsoft SQL Server 2008 Analysis Services (SSAS)-Datenquelle, die die
AdventureWorks-Beispieldatenbanken als SQL Server 2008 Analysis Services-Cube
verwendeten.
In der nachfolgenden Tabelle werden der Typ und die Größe der einzelnen Elemente des
Dashboards beschrieben.
Name
Beschreibung
260
Größe
Name
Beschreibung
Größe
Filter 1
Elementauswahlfilter
7 Dimensionselemente
Filter 2
Elementauswahlfilter
20 Dimensionselemente
Scorecard
Scorecard
15
Dimensionselementzeilen
x 4 Spalten (2 KPIs)
Diagramm 1
Liniendiagramm
3 Datenreihen x 12
Spalten
Diagramm 2
Gestapeltes Balkendiagramm 37 Datenreihen x 3
Spalten
Raster
Analyseraster
5 Zeilen x 3 Spalten
Für das Dashboard mittlerer Größe wurde die Vorlage Kopfzeile und zwei Spalten
verwendet. Die Dashboardelementgrößen wurden entweder automatisch festgelegt oder
als bestimmter Prozentwert des Dashboards. Jedes Element auf dem Dashboard wurde
mit einer Zufallshöhe und -breite zwischen 400 und 500 Pixel dargestellt, um die
unterschiedlichen Größen von Webbrowserfenstern zu simulieren. Die Änderung der
Höhe und Breite der einzelnen Dashboardelemente ist wichtig, da Diagramme auf der
Grundlage der Größe der Webbrowserfenster dargestellt werden.
Testszenarien und Prozesse
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 Abschnitt "Testergebnisse" aufgeführt.
Testname
Testbeschreibung
Rendern eines Dashboards und fünfmaliges 1. Rendern des Dashboards.
zufälliges Ändern eines der beiden Filter mit 2. Auswählen eines der beiden Filter und
einer Pause von 15 Sekunden zwischen
zufälliges Auswählen eines Filterwerts
Interaktionen.
sowie Warten, bis das Dashboard
erneut gerendert wird.
3. Vier weitere Wiederholungen bei
zufälliger Auswahl eines der beiden
Filter und eines zufälligen Filterwerts.
Rendern eines Dashboards, Auswählen
1.
eines Diagramms und fünfmaliges Erweitern 2.
und Reduzieren mit einer Pause von
15 Sekunden zwischen Interaktionen.
3.
261
Rendern des Dashboards.
Auswählen eines zufälligen Elements in
einem Diagramm und dieses erweitern.
Auswählen eines anderen zufälligen
Elements im Diagramm und dieses
Testname
Testbeschreibung
reduzieren.
4. Auswählen eines anderen zufälligen
Elements im Diagramm und dieses
erweitern.
5. Auswählen eines anderen zufälligen
Elements im Diagramm und dieses
reduzieren.
Rendern eines Dashboards, Auswählen
eines Rasters und fünfmaliges Erweitern
und Reduzieren mit einer Pause von
15 Sekunden zwischen Interaktionen.
1. Rendern des Dashboards. Auswählen
eines zufälligen Elements in einem
Raster und Erweitern des Elements.
2. Auswählen eines anderen zufälligen
Elements im Raster und dieses
erweitern.
3. Auswählen eines anderen zufälligen
Elements im Raster und dieses
reduzieren.
4. Auswählen eines anderen zufälligen
Elements im Raster und dieses
erweitern.
Es wurde eine einzelne Testmischung bestehend aus den folgenden Prozentwerten
gestarteter Tests angewendet.
Testname
Testmischung
Rendern eines Dashboards und fünfmaliges 80%
zufälliges Ändern eines der beiden Filter.
10%
Rendern eines Dashboards, Auswählen
eines Diagramms und fünfmaliges Erweitern
sowie Reduzieren.
Rendern eines Dashboards, Auswählen
eines Rasters und fünfmaliges Erweitern
sowie Reduzieren.
10%
Die Microsoft Visual Studio 2008 Load Testing-Tools wurden zum Erstellen einer Reihe
von Webtests und Auslastungstests verwendet, bei denen Benutzer simuliert wurden, die
Filter zufällig ändern und in Rastern und Diagrammen navigieren. Bei den in diesem
Artikel verwendeten Tests wurde eine normale Verteilung von 15 sekündigen Pausen, so
genannten "Reaktionszeiten" zwischen Interaktionen sowie eine Reaktionszeit zwischen
Testiterationen von 15 Sekunden eingefügt. Durch Anwenden einer Last wurde eine
262
durchschnittliche Antwortzeit von zwei Sekunden für das Rendern einer Scorecard oder
eines Berichts erzielt. Die durchschnittliche Antwortzeit wurde über einen Zeitraum von
15 Minuten nach einer ersten Aufwärmphase von 10 Minuten gemessen.
Bei jeder neuen Testiteration wurde ein anderes Benutzerkonto aus einem Pool von fünf
Tausend Konten und eine zufällige IP-Adresse (mithilfe von IP-Wechsel in Visual Studio)
aus einem Pool von ca. 2.200 Adressen ausgewählt.
Die Testmischung wurde zweimal auf demselben Dashboard mittlerer Größe ausgeführt.
Beim ersten Durchgang wurde die Authentifizierung der Datenquellen so konfiguriert,
dass das unbeaufsichtigte Dienstkonto verwendet wurde, welches ein allgemeines Konto
zur Anforderung der Daten einsetzt. Die Datenergebnisse sind für mehrere Benutzer
identisch, und Caching kann von PerformancePoint Services zur Steigerung der Leistung
verwendet werden. Beim zweiten Durchgang wurde die Authentifizierung von
Datenquellen so konfiguriert, dass die Einzelbenutzeridentität verwendet wird; der SQL
Server Analysis Services-Cube wurde so konfiguriert, dass die dynamische Sicherheit
angewendet wird. In dieser Konfiguration wird die Identität des Benutzers von
PerformancePoint Services verwendet, um die Daten anzufordern. Da die
Datenergebnisse unterschiedlich sein könnten, kann kein Caching für Benutzer
verwendet werden. In bestimmten Fällen ist Caching für die Einzelbenutzeridentität
möglich, wenn die dynamische Sicherheit von Analysis Services nicht konfiguriert ist und
die Analysis Services-Rollen, denen Microsoft Windows-Benutzer und -Gruppen
zugeordnet sind, identisch sind.
Hardwareeinstellungen und -topologie
Laborhardware
Um ein hohes Maß an Details bei den Testergebnissen zu erzielen, wurden verschiedene
Farmkonfigurationen für die Tests verwendet. Die Farmkonfigurationen reichten von
einem bis zu drei Webservern, einem bis vier Anwendungsservern und einem einzelnen
Datenbankserver, auf dem Microsoft SQL Server 2008 ausgeführt wurde. Es wurde eine
Standard-Unternehmensinstallation von SharePoint Server 2010 durchgeführt.
In der folgenden Tabelle ist die jeweilige Hardware für die Tests aufgelistet.
Webserver
Anwendungsserver Computer, Computer,
auf dem auf dem
SQL
Analysis
Server
Services
ausgeführt ausgeführt
wird
wird
Prozessor(en)
2px4c @ 2,66 GHz
2px4c @ 2,66
GHz
2px4c @ 4px6c @
2,66 GHz 2,4 GHz
RAM
16 GB
32 GB
16 GB
Betriebssystem
Windows Server 2008
R2 Enterprise
Windows Server
2008 R2
Enterprise
Windows Windows
Server
Server
2008 R2 2008 R2
Enterprise Enterprise
NIC
1x1 Gigabit
1x1 Gigabit
1x1
263
64 GB
1x1
Webserver
Anwendungsserver Computer, Computer,
auf dem auf dem
SQL
Analysis
Server
Services
ausgeführt ausgeführt
wird
wird
Gigabit
Authentifizierung
NTLM und Kerberos
NTLM und
Kerberos
Gigabit
NTLM
NTLM
und
und
Kerberos Kerberos
Nach dem Skalieren der Farm auf mehrere Webserver wurde ein HardwareLastenausgleichsmodul zur Verteilung der Benutzerlast auf mehrere Webserver mithilfe
der Quelladressaffinität verwendet. Bei der Quelladressaffinität wird die IP-Quelladresse
eingehender Anforderungen und der Diensthost, an den diese als Lastenausgleich
verteilt wurden, aufgezeichnet und alle kommenden Transaktionen an denselben Host
geleitet.
Topologie
Die Ausgangstopologie setzte sich aus zwei physikalischen Servern zusammen, wobei
ein Server als Web- und Anwendungsserver und der zweite als Datenbankserver diente.
Diese Ausgangstopologie wird als Topologie mit zwei Rechnern (2M) oder als "1x0x1"Topologie bezeichnet, wobei die Anzahl der dedizierten Webserver zuerst aufgeführt ist,
gefolgt von den dedizierten Anwendungsservern und schließlich den Datenbankservern.
Webserver werden nachfolgend in diesem Dokument auch als Web-Front-Ends (WFE)
bezeichnet. Die Last wurde so lange angewendet, bis Einschränkungen auftraten. In der
Regel stellte die CPU des Web- oder des Anwendungsservers eine Einschränkung dar;
es wurden dann Ressourcen hinzugefügt, um diese Einschränkung zu überwinden. Die
Einschränkungen und Topologien wichen abhängig von der Konfiguration der
Datenquellenauthentifizierung entweder für das unbeaufsichtigte Dienstkonto oder die
Einzelbenutzeridentität mit dynamischer Cubesicherheit stark voneinander ab.
Testergebnisse
Die Testergebnisse enthalten drei wichtige Measures für die Definition der
PerformancePoint Services-Kapazität.
Measure
Beschreibung
Benutzeranzahl
Gesamtanzahl der von Visual Studio gemeldeten Benutzer.
Anforderungen pro Sekunde Gesamtanzahl der von Visual Studio gemeldeten RPS,
(RPS)
einschließlich aller Anforderungen und Anforderungen
statischer Dateien wie Bilder und Stylesheets.
Ansichten pro Sekunde
(VPS)
Gesamtanzahl der Ansichten, die PerformancePoint
Services rendern kann. Eine Ansicht ist ein beliebiger von
PerformancePoint Services gerenderter Filter, eine
Scorecard, ein Raster oder ein Diagramm oder eine
264
Measure
Beschreibung
beliebige Webanforderung der Renderingdienst-URL, die
RenderWebPartContent oder CreateReportHtml enthält.
Weitere Informationen zu CreateReportHtml und
RenderWebPartContent finden Sie in der
Protokollspezifikation für den Rendering-Dienst der
PerformancePoint-Dienste
(http://go.microsoft.com/fwlink/?linkid=200609&clcid=0x407).
IIS-Protokolle können nach diesen Anforderungen analysiert
werden, um die Kapazität von PerformancePoint Services
besser zu planen. Darüber hinaus kann mithilfe dieses
Measures eine Zahl bereitgestellt werden, die deutlich
weniger abhängig von der Dashboardzusammensetzung ist.
Ein Dashboard mit zwei Ansichten kann mit einem
Dashboard mit 10 Ansichten verglichen werden.
Tipp:
Bei Verwendung einer Datenquelle, die so konfiguriert ist, dass die Authentifizierung des
unbeaufsichtigten Dienstkontos verwendet wird, gilt für das Verhältnis zwischen
dedizierten Servern die Regel von einem Webserver zu jeweils zwei Anwendungsservern
mit PerformancePoint Services.
Tipp:
Bei Verwendung einer Datenquelle, die so konfiguriert ist, dass die
Einzelbenutzerauthentifizierung verwendet wird, gilt für das Verhältnis zwischen
dedizierten Servern die Regel von einem Webserver zu jeweils vier oder mehr
Anwendungsservern mit PerformancePoint Services.
Bei Topologien mit mehr als vier Anwendungsservern ist davon auszugehen, dass der
Analysis Services-Server den Engpass darstellt. Sie sollten die CPU-Auslastung und die
Abfragezeit des Analysis Services-Servers überwachen, um bestimmen zu können, ob
Analysis Services auf mehrere Server skaliert werden sollte. Durch Verzögerungen bei
der Abfragezeit auf dem Analysis Services-Server steigt die durchschnittliche Antwortzeit
von PerformancePoint Services deutlich über den gewünschten Schwellenwert von zwei
Sekunden.
Die nachfolgenden Tabellen enthalten eine Zusammenfassung der Testergebnisse
sowohl für die Authentifizierung über das unbeaufsichtigte Dienstkonto als auch die
Einzelbenutzerauthentifizierung bei einer horizontalen Skalierung von zwei auf sieben
Server. Ausführliche Ergebnisse, die zusätzliche Leistungsindikatoren umfassen, sind
nachfolgend in diesem Dokument aufgeführt.
Zusammenfassung der Authentifizierung über das unbeaufsichtigte Dienstkonto
265
Topologie (WFExAPPxSQL)
Benutzer
Anforderungen Ansichten
pro Sekunde pro
(RPS)
Sekunde
(VPS)
2M (1x0x1)
360
83
50
3M (1x1x1)
540
127
75
4M (1x2x1)
840
196
117
5M (1x3x1)
950
215
129
6M (2x3x1)
1.250
292
175
7M (2x4x1)
1.500
346
205
Zusammenfassung der Einzelbenutzerauthentifizierung
Topologie (WFExAPPxSQL)
Benutzer
Anforderungen Ansichten
pro Sekunde pro
(RPS)
Sekunde
(VPS)
2M (1x0x1)
200
47
27
3M (1x1x1)
240
56
33
4M (1x2x1)
300
67
40
5M (1x3x1)
325
74
44
Topologien mit 2M und 3M
Zur einfacheren Erläuterung der Hardwarekosten pro Transaktion und der
Antwortzeitkurve wurden die Auslastungstests mit vier steigenden Benutzerauslastungen
bis zur maximalen Benutzerauslastung für die 2M- und 3M-Topologien durchgeführt.
Authentifizierung über das unbeaufsichtigte Dienstkonto
Benutzeranzahl
50
150
250
Durchschnittl. WFE/APP-CPU 19,20%
57,70%
94,00% 96,70%
Anforderungen pro Sekunde 18
53
83
83
Ansichten pro Sekunde
31,72
49,27
49,67
0,15
0,38
2
10,73
Durchschnittl. Antwortzeit (s) 0,12
266
360
Einzelbenutzerauthentifizierung
Benutzeranzahl
50
100
150
Durchschnittl. WFE/APP-CPU 30,80%
61,30%
86,50% 93,30%
Anforderungen pro Sekunde 17
32
43
47
Ansichten pro Sekunde
19,32
26,04
27,75
0,45
0,81
2
10,3
Durchschnittl. Antwortzeit (s) 0,28
267
200
Ergebnisse 3M-Farm (1x1x1)
Authentifizierung über das unbeaufsichtigte Dienstkonto
Benutzeranzahl
100
250
400 540
Anforderungen pro Sekunde
36
87
124 127
Ansichten pro Sekunde
21
52
74
Durchschnittl. Antwortzeit (s)
0,12
0,18
0,65 2
Durchschnittl. WFE-CPU
11%
28%
43% 46%
Max. private Bytes des WFE
0,7 GB
vom SharePoint Server-W3WPArbeitsprozess mit
Internetinformationsdiensten
(Internet Information Services,
IIS).
1,4 GB
2,0 2,4
GB GB
Durchschnittl. APP-CPU
25%
62%
94% 95%
Max. private Bytes des APP
5,9 GB
10,8 GB
14,1 14,6
268
75
Benutzeranzahl
100
250
vom PerformancePoint
Services-W3WP-Arbeitsprozess
400 540
GB GB
Einzelbenutzerauthentifizierung
Benutzeranzahl
50
120
180 240
Anforderungen pro Sekunde
17
39
52
56
Ansichten pro Sekunde
10
23
31
33
Durchschnittl. Antwortzeit (s)
0,28
0,48
0,91 2
Durchschnittl. WFE-CPU
5%
12%
17% 19%
Max. private Bytes des WFE
0,78 GB
vom SharePoint Server-W3WPArbeitsprozess
1,3 GB
1,6 1,9
GB GB
Durchschnittl. APP-CPU
57%
81% 81%
25%
269
Benutzeranzahl
50
Max. private Bytes des APP
19 GB
vom PerformancePoint
Services-W3WP-Arbeitsprozess
120
180 240
20,1 GB
20,5 20,9
GB GB
Ergebnisse von 4M+ für die Authentifizierung
über das unbeaufsichtigte Dienstkonto
Beginnend mit einer 4M-Topologie wurde die Last angewendet, um eine
durchschnittliche Antwortzeit von zwei Sekunden für das Rendern einer Scorecard oder
eines Berichts zu erzielen. Im nächsten Schritt wurde ein zusätzlicher Server
hinzugefügt, um die Einschränkung (durch die CPU auf dem Web- oder
Anwendungsserver) zu umgehen; anschließend wurde die Testmischung erneut
ausgeführt. Diese Logik wurde so lange wiederholt, bis insgesamt sieben Server erreicht
waren.
270
4M (1x2x1)
5M (1x3x1)
6M
7M
(2x3x1) (2x4x1)
Benutzeranzahl
840
950
1.250 1.500
Anforderungen pro Sekunde
196
216
292
346
Ansichten pro Sekunde
117
131
175
206
Durchschnittl. WFE-CPU
77%
63%
54%
73%
Max. private Bytes des WFE
vom SharePoint ServerW3WP-Arbeitsprozess
2,1 GB
1,7 GB
2,1
GB
2,0
GB
Durchschnittl. APP-CPU
83%
94%
88%
80%
Max. private Bytes des APP
vom PerformancePoint
Services-W3WPArbeitsprozess
16 GB
12 GB
15 GB 15 GB
Ergebnisse von 4M+ für die
Einzelbenutzerauthentifizierung
Die gleichen Tests wurden für eine für die Einzelbenutzerauthentifizierung konfigurierte
Datenquelle wiederholt. Durch Hinzufügen eines Anwendungsservers, um eine Topologie
mit vier Anwendungsservern zu erstellen, kam es aufgrund der Abfrageverzögerungen
von Analysis Services nicht zu einem Anstieg der von PerformancePoint Services
unterstützten Benutzer oder Anforderungen pro Sekunde.
3M (1x1x1)
4M (1x2x1)
5M
6M
(1x3x1) (1x4x1)
Benutzeranzahl
240
300
325
325
Anforderungen pro Sekunde
56
67
74
74
Ansichten pro Sekunde
33
40
44
45
Durchschnittl. WFE-CPU
19%
24%
26%
12%
Max. private Bytes des WFE
vom SharePoint ServerW3WP-Arbeitsprozess
2,1 GB
1,9 GB
1,9
GB
1,5
GB
Durchschnittl. APP-CPU
89%
68%
53%
53%
Max. private Bytes des APP
vom PerformancePoint
Services-W3WPArbeitsprozess
20 GB
20 GB
20 GB 20 GB
271
Analysis Services-CPU
3M (1x1x1)
4M (1x2x1)
5M
6M
(1x3x1) (1x4x1)
17%
44%
57%
68%
Empfehlungen
Hardwareempfehlungen
Die Leistungsindikatoren für Arbeitsspeicher und Prozessoren in den Testtabellen sollten
für die Bestimmung der Hardwareanforderungen für eine Installation von
PerformancePoint Services verwendet werden. Für Webserver werden die empfohlenen
SharePoint Server 2010-Hardwareanforderungen von PerformancePoint Services
verwendet. Die Hardwareanforderungen für Anwendungsserver müssen möglicherweise
geändert werden, wenn PerformancePoint Services sehr viel Arbeitsspeicher benötigt.
Dies ist dann der Fall, wenn Datenquellen für die Einzelbenutzerauthentifizierung
konfiguriert werden oder wenn zu viele Dashboards mit langen Datenquellentimeouts
vom Anwendungsserver ausgeführt werden.
Der Datenbankserver stellte in den Tests keinen Engpass dar und erreichte einen
Höchstwert bei einer maximalen CPU-Auslastung von 31% unter dem über das
272
unbeaufsichtigte Dienstkonto authentifizierten 7M-Dashboard. Die PerformancePoint
Services-Inhaltsdefinitionen wie Berichte, Scorecards und KPIs werden in SharePointListen gespeichert und von PerformancePoint Services im Arbeitsspeicher
zwischengespeichert, wodurch die Auslastung des Datenbankservers sinkt.
Arbeitsspeicherbelegung
In bestimmten Konfigurationen kann PerformancePoint Services sehr viel Arbeitsspeicher
belegen, deshalb ist es wichtig, die Arbeitsspeichernutzung des PerformancePoint
Services-Anwendungspools zu überwachen. Verschiedene Elemente werden von
PerformancePoint Services im Arbeitsspeicher zwischengespeichert, einschließlich
Analysis Services und anderer Abfrageergebnisse der Datenquelle zur
Cachelebensdauer der Datenquelle (Standardeinstellung beträgt 10 Minuten). Wenn Sie
eine Datenquelle verwenden, die für die Authentifizierung über das unbeaufsichtigte
Dienstkonto konfiguriert wurde, werden diese Abfrageergebnisse nur einmal
zwischengespeichert und für mehrere Benutzer gemeinsam genutzt. Wenn Sie hingegen
eine Datenquelle verwenden, die für die Einzelbenutzerauthentifizierung und die
dynamische Cubesicherheit von Analysis Services konfiguriert wurde, werden die
Abfrageergebnisse einmal pro Benutzer pro Ansicht (also eine "pro Filter"-Kombination)
gespeichert.
Das ASP.NET-Cache-API ist das zugrundliegende Cache-API, das von
PerformancePoint Services verwendet wird. Der klare Vorteil, der sich aus der
Verwendung dieses APIs ergibt, liegt darin, dass der Cache von ASP.NET verwaltet wird
und auf der Grundlage von Arbeitsspeicherbegrenzungen Elemente entfernt (so
genanntes Kürzen), um Fehler aufgrund von unzureichendem Arbeitsspeicher zu
vermeiden. Die Standardbegrenzung für den Arbeitsspeicher liegt bei 60 Prozent des
physikalischen Arbeitsspeichers. Nach Erreichen diese Grenzwerts wurden Ansichten
von PerformancePoint Services zwar noch gerendert, doch stiegen die Antwortzeiten
während des kurzen Zeitraums deutlich an, während dem zwischengespeicherte Einträge
von ASP.NET entfernt wurden.
Der Leistungsindikator "ASP.NET-Anwendungen \ Cache-API-Kürzungen" des
Anwendungspools, der PerformancePoint Services hostet, kann zur Überwachung der
ASP.NET-Cachekürzungen verwendet werden, die aufgrund von hoher
Arbeitsspeicherauslastung stattfinden. Ist dieser Leistungsindikator größer als Null,
sollten Sie in der folgenden Tabelle nach möglichen Lösungen suchen.
Problem
Lösung
Nutzung des Anwendungsserverprozessors Hinzufügen von zusätzlichem physikalischen
ist niedrig; andere Dienste werden auf dem Arbeitsspeicher oder Begrenzen des
Anwendungsserver ausgeführt.
Arbeitsspeichers des ASP.NET-Caches.
Nutzung des Anwendungsserverprozessors
ist niedrig; nur PerformancePoint Services
wird auf dem Anwendungsserver
ausgeführt.
Konfigurieren der ASP.NETCacheeinstellungen, sodass mehr
Arbeitsspeicher vom Cache genutzt wird
(falls akzeptabel), oder Hinzufügen von
zusätzlichem Arbeitsspeicher.
Nutzung des Anwendungsserverprozessors Hinzufügen eines anderen
ist hoch.
Anwendungsservers.
273
Abfrageergebnisse und Cacheeinträge können von einer Datenquelle, die für die
Einzelbenutzerauthentifizierung konfiguriert wurde, freigegeben werden, wenn die
Analysis Services-Rollenmitgliedschaften der Benutzer identisch sind und die
dynamische Cubesicherheit nicht konfiguriert wurde. Dies ist ein neues Feature von
PerformancePoint Services in Microsoft SharePoint Server 2010. Wenn beispielsweise
Benutzer A der Rolle 1 und 2 angehört, Benutzer B der Rolle 1 und 2 angehört und
Benutzer C der Rolle 1, 2 und 3 angehört, können nur für Benutzer A und Benutzer B
Cacheeinträge gemeinsam genutzt werden. Wenn die dynamische Cubesicherheit
verwendet wird, können weder für Benutzer A und B noch für Benutzer C Cacheeinträge
gemeinsam genutzt werden.
Analysis Services
Beim Testen von PerformancePoint Services unter Verwendung der
Einzelbenutzerauthentifizierung wurden zwei Eigenschaften von Analysis Services
geändert, um die Durchsatzleistung bei mehreren Benutzern zu verbessern. In der
folgenden Tabelle werden die geänderten Eigenschaften und ihre neuen Werte
dargestellt.
Analysis Services-Eigenschaft
Wert
Arbeitsspeicher \ HeapTypeForObjects
0
Arbeitsspeicher \ MemoryHeapType
2
Durch diese beiden Speichereinstellungen wird Analysis Services für die Verwendung
des Windows-Heaps anstelle des Analysis Services-Heaps konfiguriert. Vor der
Änderung dieser Eigenschaften und bei zunehmender Benutzerauslastung stiegen die
Antwortzeiten deutlich von 0,2 Sekunden auf über 30 Sekunden an, während die CPUAuslastung der Web-, Anwendungs- und Analysis Services-Server niedrig blieb. Zur
Problembehandlung wurde die Abfragezeit mithilfe von dynamischen Analysis ServicesVerwaltungssichten erfasst, die einen Anstieg der einzelnen Abfragezeiten von
10 Millisekunden auf 5000 Millisekunden zeigten. Die oben genannten
Speichereinstellungen wurden aufgrund dieser Ergebnisse geändert.
Die Änderung dieser Einstellungen führt zu einer deutlichen Verbesserung des
Durchsatzes, bringt nach Angaben des Analysis Services-Teams jedoch nur geringe,
messbare Kosten für Einzelbenutzerabfragen mit sich.
Vor dem Ändern von Analysis Services-Eigenschaften sollten Sie das Dokument SQL
Server 2008-Whitepaper: Handbuch zur Leistungsoptimierung in Analysis Services
(http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x407) lesen. Sie erhalten hier
einen Einblick in optimale Methoden für die Verbesserung der Durchsatzleistung mit
mehreren Benutzern.
Häufige Engpässe und ihre Ursachen
Während der Leistungstests traten bestimmte Engpässe häufig auf. Ein Engpass ist ein
Zustand, bei dem die maximale Kapazität eines bestimmten Bestandteils einer Farm
erreicht wird. Dies hat ein Plateau oder eine Abnahme des Durchsatzes der Farm zur
274
Folge. Wenn eine hohe Prozessornutzung als Engpass auftrat, wurden zusätzliche
Server hinzugefügt, um den Engpass zu beseitigen. In der folgenden Tabelle sind einige
häufige Engpässe und mögliche Lösungen aufgeführt. Dabei wurde angenommen, dass
die Prozessornutzung niedrig war und keinen Engpass darstellte.
Möglicher
Engpass
Ursache und was
überwacht werden
sollte
Lösung
Leistung des
Analysis
ServicesSpeicherheaps
Standardmäßig wird
der eigene
Speicherheap von
Analysis Services
anstelle des
Windows-Heaps
verwendet, der nur
eine niedrige
Durchsatzleistung für
mehrere Benutzer
bietet. Überprüfen Sie
die Analysis ServicesAbfragezeiten mithilfe
dynamischer
Verwaltungssichten,
um festzustellen, ob
Abfragezeiten mit der
Benutzerauslastung
steigen und die
Analysis ServicesProzessornutzung
niedrig ist.
Ändern Sie Analysis Services so, dass der
Windows-Heap verwendet wird. Anleitungen
entnehmen Sie dem Abschnitt "Analysis
Services" weiter oben in diesem Artikel sowie
dem SQL Server 2008-Whitepaper: Handbuch
zur Leistungsoptimierung in Analysis Services
(http://go.microsoft.com/fwlink/?linkid=165486&c
lcid=0x407).
Analysis
ServicesAbfrage- und
Verarbeitungsthr
eads
Standardmäßig wird
die Anzahl der
Abfrage- und
Verarbeitungsthreads
für Abfragen von
Analysis Services
begrenzt. Bei lang
andauernden
Abfragen und hohen
Benutzerauslastunge
n werden
möglicherweise alle
verfügbaren Threads
verwendet.
Überwachen Sie die
Leistungsindikatoren
der Threads im
Leerlauf und der
Erhöhen Sie die Anzahl der für Abfragen und
Prozesse verfügbaren Threads. Anleitungen
entnehmen Sie dem Abschnitt "Analysis
Services" sowie dem SQL Server 2008Whitepaper: Handbuch zur
Leistungsoptimierung in Analysis Services
(http://go.microsoft.com/fwlink/?linkid=165486&c
lcid=0x407).
275
Möglicher
Engpass
Ursache und was
überwacht werden
sollte
Lösung
Auftragswarteschlang
e unter der Kategorie
"MSAS
2008:Threads".
Arbeitsspeicher In PerformancePoint Fügen Sie Arbeitsspeicher hinzu, oder erhöhen
von
Services werden die Sie die Standard-Cachespeicherbegrenzungen
Anwendungsserv Abfrageergebnisse
von ASP.NET. Weitere Hinweise entnehmen Sie
ern
von Analysis Services dem Abschnitt "Arbeitsspeicherbelegung" weiter
und anderen
oben in diesem Dokument. Weitere
Datenquellen während Informationen finden Sie auch im Dokument
der Lebensdauer des Einstellungen des ASP.NET-Cacheelements
Caches der
(http://go.microsoft.com/fwlink/?linkid=200610&c
Datenquelle
lcid=0x407) sowie in Thomas Marquardts
zwischengespeichert. Blogbeitrag über Hintergrundinfos zu den
Diese Elemente
Arbeitsspeicherbegrenzungen des ASP.NETkönnen sehr viel
Caches
Arbeitsspeicher
(http://go.microsoft.com/fwlink/?linkid=200611&c
beanspruchen.
lcid=0x407).
Überwachen Sie den
Leistungsindikator
"ASP.NETAnwendungen \
Cache-APIKürzungen" des
PerformancePoint
ServicesAnwendungspools,
um festzustellen, ob
Cachekürzungen
aufgrund von
niedrigem
Arbeitsspeicher von
ASP.NET erzwungen
werden.
Einstellungen
der WCFDrosselung
PerformancePoint
Services ist als WCFDienst implementiert.
Durch WCF wird die
maximale Anzahl
gleichzeitiger Aufrufe
als
Dienstdrosselungsver
halten eingeschränkt.
Obwohl lang
andauernde Abfragen
Falls erforderlich, ändern Sie das WCFDrosselungsverhalten (Windows Communication
Foundation). Informationen finden Sie unter
Drosselungsverhalten des WCF-Diensts
(http://go.microsoft.com/fwlink/?linkid=200612&c
lcid=0x407) und in Wenlong Dongs Blogbeitrag
über die WCF-Anforderungsdrosselung und
Serverskalierbarkeit
(http://go.microsoft.com/fwlink/?linkid=200613&c
lcid=0x407).
276
Möglicher
Engpass
Ursache und was
überwacht werden
sollte
Lösung
zu diesem Engpass
führen könnten, tritt
dieser Engpass nicht
häufig auf.
Überwachen Sie
Aufrufe der
Leistungsindikatoren
des WCF-/DienstModells, die für
PerformancePoint
Services ausstehen
und vergleichen Sie
sie mit der maximalen
Anzahl gleichzeitiger
Aufrufe.
Leistungsüberwachung
Um den richtigen Zeitpunkt für eine vertikale oder horizontale Skalierung des Systems zu
bestimmen, verwenden Sie Leistungsindikatoren zur Überwachung der Integrität des
Systems. PerformancePoint Services ist ein ASP.NET-WCF-Dienst und kann mithilfe
derselben Leistungsindikatoren wie zur Überwachung sonstiger ASP.NET-WCF-Dienste
überwacht werden. Verwenden Sie darüber hinaus die Informationen in den folgenden
Tabellen, um zusätzliche zu überwachende Leistungsindikatoren zu ermitteln und um
festzustellen, auf welchen Prozess die Leistungsindikatoren angewendet werden sollten.
Leistungsindikator
Indikatorinstan Hinweise
z
ASP.NETPerformanceP Wenn der Wert größer als Null ist, lesen Sie den
Anwendungen / Cache- oint Services- Abschnitt "Arbeitsspeicherbelegung" durch.
Anwendungsp
API-Kürzungen
ool
MSAS 2008:Threads / n/v
Abfragepoolthreads im
Leerlauf
Wenn der Wert gleich Null ist, lesen Sie die
Informationen im Abschnitt "Analysis Services"
sowie im SQL Server 2008-Whitepaper:
Handbuch zur Leistungsoptimierung in Analysis
Services
(http://go.microsoft.com/fwlink/?linkid=165486&cl
cid=0x407).
MSAS 2008:Threads / n/v
AbfragepoolAuftragswarteschlangen
Wenn der Wert größer als Null ist, lesen Sie die
Informationen im Abschnitt "Analysis Services"
sowie im SQL Server 2008-Whitepaper:
277
Leistungsindikator
Indikatorinstan Hinweise
z
länge
Handbuch zur Leistungsoptimierung in Analysis
Services
(http://go.microsoft.com/fwlink/?linkid=165486&cl
cid=0x407).
MSAS 2008:Threads / n/v
Verarbeitungspoolthrea
ds im Leerlauf
Wenn der Wert größer als Null ist, lesen Sie die
Informationen im Abschnitt "Analysis Services"
sowie im SQL Server 2008-Whitepaper:
Handbuch zur Leistungsoptimierung in Analysis
Services
(http://go.microsoft.com/fwlink/?linkid=165486&cl
cid=0x407).
MSAS 2008:Threads / n/v
VerarbeitungspoolAuftragswarteschlangen
länge
Wenn der Wert größer als Null ist, lesen Sie die
Informationen im Abschnitt "Analysis Services"
sowie im SQL Server 2008-Whitepaper:
Handbuch zur Leistungsoptimierung in Analysis
Services
(http://go.microsoft.com/fwlink/?linkid=165486&cl
cid=0x407).
WCF
PerformanceP
CountersServiceModelS ointervice
Dienstinstanz
3.0.0.0(*)\Ausstehende
Aufrufe
Wenn der Wert größer als Null ist, lesen Sie die
Informationen in WCF-Anforderungsdrosselung
und Serverskalierbarkeit
(http://go.microsoft.com/fwlink/?linkid=200613&cl
cid=0x407).
Siehe auch
Weitere Ressourcen
Plan for PerformancePoint Services (SharePoint Server 2010)
278
Capacity requirements for Web Analytics
Shared Service in SharePoint Server
2010 (in englischer Sprache)
Initial capacity testing was performed for a simulated midsized deployment of Microsoft
SharePoint Server 2010 and other applications that included 30,000 SharePoint entities.
This article describes the results of the capacity testing activities and contains guidance
on capacity management for the Web Analytics service application in SharePoint Server
2010.
In SharePoint Server 2010, the Web Analytics service application enables you to collect,
report, and analyze the usage and effectiveness of SharePoint Server 2010 sites. Web
Analytics features include reporting, Web Analytics workflow, and Web Analytics Web
Part. For more information, see Reporting and usage analysis overview.
The aspects of capacity planning that are described in this article include the following:
 Description of the architecture and topology.

Capacity planning guidelines based on the key factors such as total expected traffic
and number of SharePoint components.

Description of the other factors that affect the performance and capacity
requirements.
Before you continue to read this article, make sure that you understand key concepts
related to SharePoint Server 2010 capacity management. The resources that are listed in
this section can help you learn about frequently used terms and get an overview of the
recommended approach to capacity management. These resources can also help you
use the information that is provided in this article more effectively.
For more conceptual information about performance and capacity management, see the
following articles:
 Leistungs- und Kapazitätsverwaltung (SharePoint Server 2010)
 Capacity management and sizing for SharePoint Server 2010 (in englischer Sprache)
In this article:
 Introduction

Hardware specifications and topology

Capacity requirements
Introduction
Overview
As part of SharePoint Server 2010, the Web Analytics service application is a set of
features that you can use to collect, report, and analyze the usage and effectiveness of a
SharePoint Server 2010 deployment. You can organize SharePoint Web Analytics
reports into three main categories:
279

Traffic

Search
 Inventory
SharePoint Web Analytics reports are typically aggregated for various SharePoint
entities, such as sites, site collections, and Web applications for each farm. To view an
architectural overview of the Web Analytics service application in a SharePoint
deployment, see Architectural overview later in this article.
The Web Analytics shared service requires resources primarily at the application server
and database server level. This article does not cover the Web Server layer capacity
planning, because the Web Analytics service‘s capacity requirements are minimal at this
level.
This article contains the capacity requirements for several application servers and
Microsoft SQL Server based computers, according to the following criteria:
 Total expected site traffic (clicks, search queries, ratings).

Number of SharePoint components (Site, Site Collection, and Web Application) for
each farm.
Other less significant factors which can affect the capacity requirements are summarized
in Other factors later in this article.
Architectural overview
The following diagram (Figure 1) shows the flow of the site usage data from a Web
browser to the analytics databases, and then back to the Web browser as reports. The
usage data is logged to the usage files on the Web servers. The usage timer job calls the
Logging Web Service to submit the raw data from the usage files. The Logging Web
Service writes it to the staging database, where the raw data is stored for seven days
(this is not configurable). The Web Analytics components Log Batcher and User Behavior
Analyzer clean and process the raw data on the staging database. The Report
Consolidator runs one time every 24 hours. The Report Consolidator aggregates the raw
data from the staging database on various dimensions, and then writes it to the reporting
database. The aggregated data is stored in the reporting database for a default period of
25 months (this is configurable).
280
Figure 1. SharePoint Server 2010 Web Analytics architectural overview
The performance of the Logging Web Service primarily depends on the number of
application servers. (Scaling out is available for the application servers.) The
281
performance of the Log Batcher and User Behavior Analyzer depends primarily on the
analytics staging database. The Read and Write activities that are performed by all the
different components can cause the analytics staging database to slow down the
process. (Scaling out is available for the staging database.) The performance of the
Report Consolidator also primarily depends on the reporting database. (Scaling out of
reporting database is not supported.)
Hardware specifications and topology
This section provides detailed information about the hardware, software, topology, and
configuration of a case study environment.
Hardware
Hinweis:
This environment is scaled to accommodate prerelease builds of SharePoint Server 2010
and other products. Therefore, the deployed hardware has larger capacity than
necessary to serve the demand typically experienced by this environment. This hardware
is described only to provide additional context for this environment and serve as a
starting point for similar environments. It is important to conduct your own capacity
management based on your planned workload and usage characteristics. For more
information about the capacity management process, see Leistungs- und
Kapazitätsverwaltung (SharePoint Server 2010).
Web servers
This article does not cover the Web server layer capacity planning, because the Web
Analytic service‘s capacity requirements are minimal at this level.
Application servers
The following table describes the configuration of each application server. Based on the
site traffic and the number of SharePoint components that are involved, users will need
one or more application servers.
Application server
Minimum requirement
Processors
4 quad core @ 2.33 GHz
RAM
8 GB
Operating system
Windows Server 2008, 64 bit
Size of the SharePoint drive
300 GB
Number of network adapters
1
Network adapter speed
1 GB
Authentication
NTLM
Load balancer type
SharePoint Load Balancer
282
Application server
Minimum requirement
Software version
SharePoint Server 2010 (prerelease
version)
Services running locally

Central Administration

Microsoft SharePoint Foundation
Incoming E-mail

Microsoft SharePoint Foundation Web
Application

Microsoft SharePoint Foundation
Workflow Timer Service

Search Query and Site Settings Service

SharePoint Server Search

Web Analytics Data Processing Service

Web Analytics Web Service
Database servers
The following table describes the configuration of each database server. Instances of
SQL Server were required for both the staging and reporting databases.
Database server
Minimum requirement
Processors
4 quad core @ 2.4 GHz
RAM
32 GB
Operating system
Windows Server 2008, 64-bit
Disk size
3 terabytes
Hinweis:
Although we used this disk size for our
capacity testing, your environment will likely
require a much larger disk size to support
Web Analytics.
Number of network adapters
1
Network adapter speed
1 GB
Authentication
NTLM
Software version
SQL Server 2008
283
Topology
The following diagram (Figure 2) shows the Web Analytics topology.
284
Figure 2. Web Analytics topology
285
Capacity requirements
Testing methodology
This section presents the capacity requirements with regard to the total amount of site
traffic (this is measured by number of clicks, search queries, and ratings) per day that can
be supported by different numbers of application servers and SQL Server based
computers. The numbers presented currently are for a midsize SharePoint deployment
that has about 30,000 SharePoint entities. The Web Analytics shared service aggregates
the data for each day. Therefore, the data volume that is presented corresponds to the
total number of records (this is measured by number of clicks, search queries, and
ratings) that the SharePoint farm is expected to receive each day.
This section provides diagrams that show the daily site traffic that can be supported by
one, two, or three application servers (Figure 3) and the daily site traffic that can be
supported that corresponds to the various database configurations (Figure 4). In the
diagrams, data is shown by using two colors:
 Green Green values indicate the safe limit for the site traffic that can be processed
for the corresponding number of application servers and SQL Server based
computers.

Yellow Yellow values indicate the expected limit for the site traffic that can be
processed for the corresponding number of application servers and SQL Server
based computers.
The green and yellow values are estimates that are based on two key factors:
 Total site traffic, measured by number of page view clicks, search queries, and
ratings.

Number of SharePoint entities, such as sites, site collections, and Web applications,
for each farm.
The estimates also depend on other properties of the data and the data retention period
in the reporting database. For testing, the other properties of the data were maintained as
constant as described in Dataset description later in this section.
Also, in smaller SharePoint deployment environments, you can share the application
servers and SQL Server based computers together with other SharePoint services and
databases. This article contains information about the capacity of the application servers
and the SQL Server based computers that are in a test environment so that the Web
Analytics shared service is the only major service that is running on the servers. The
actual performance results for environments that actively use other shared services at the
same time running might vary.
To determine the capacity requirements for your environment, make sure that you
estimate the expected daily site traffic and the number of components that you might use
for a SharePoint deployment. Then, the number of application servers and SQL Server
based computers should be estimated independently, as shown in Figure 3 and Figure 4.
Dataset description
The dataset that was selected for the test environment is a mid-sized dataset that has
approximately 30,000 SharePoint components, which includes all web applications, site
collections, and sites. Other characteristics of the data that were kept constant in the
environment are also listed in the following table.
286
Dataset characteristics
Value
Number of SharePoint components
30,000
Number of unique users
117,000
Number of unique queries
68,000
Number of unique assets
500,000
Data size in the reporting database
200 GB
The total site traffic, measured by number of clicks, search queries, and ratings, was
increased as part of this case study to establish the number of records that can be
supported by the corresponding topology.
Wichtig:
Some typically used topologies generally exceed the capacity planning guidance. Those
topologies include the following:
 Team sites

My Site Web sites
 Self-provisioning portals
If you anticipate that you might exceed the capacity planning guidelines, we recommend
that you turn off the Web Analytics service application. For more information about how to
turn off a service application, see Starting or stopping a service.
Application servers
The following diagram (Figure 3) shows the daily site traffic that can be supported by one,
two, or three application servers. The site traffic is represented in millions of records
(each click, search query, or rating makes up a record) each day. The yellow line
represents the expected number of records for the corresponding topology, whereas the
green line represents the safe assumption for the number of records.
287
Figure 3. Daily site traffic vs. the application servers topology
The application servers are not very CPU-intensive or memory intensive. Thus, the CPU
and the memory usage are not summarized for this section.
SQL Server based computers
The following diagram (Figure 4) shows the daily site traffic that can be supported that
corresponds to the following configurations:
 One instance of SQL Server for both staging and reporting databases (1S+R).

Two instances of SQL Server, one staging database and one reporting database
(1S1R).
288

Three instances of SQL Server, two staging databases and one reporting database
(2S1R).
The site traffic is represented in millions of records (each click, search, or rating makes
up a record) each day. The yellow line represents the expected number of records for the
corresponding topology, whereas the green line represents the safe assumption for the
number of records.
Figure 4. Daily site traffic vs. SQL Server topology
The following table summarizes the CPU and memory usage of the various components
on the instances of SQL Server that are hosting the staging database and the reporting
database.
289
Configuration
1S+R
1S1R
1S1R
2S1R
2S1R
Staging + Reporting
Staging Reporting Staging Reporting
Total sum of percentage 19
of processor time for 8
processor computer
192
5.78
100
13.4
SQL Server buffer hit
ratio
99
100
100
100
100
% Disk time
7,142
535
5.28
59.3
98.2
Disk queue length
357
28.6
0.26
2.97
4.91
Other factors
Many other factors can affect the performance of various analytics components and can
affect the capacity planning. These factors primarily affect the performance of the Report
Extractor component because they can affect the size of the data aggregated each day.
The total size of the data in the reporting database also affects the performance of the
Reporting Extractor, although this is not significant because the data is partitioned daily.
Some of these other factors are as follows:
 Number of unique queries each day.

Number of unique users each day.

Total number of unique assets clicked each day.

Existing data size in the reporting warehouse, based on the data retention in the
warehouse.
The overall effect of these factors is less significant than the total data volume and the
number of site entities. However, it is important to conduct your own capacity
management based on your planned workload and usage characteristics. For more
information about the capacity management process, see Leistungs- und
Kapazitätsverwaltung (SharePoint Server 2010).
Remaining issues
There are current known issues that significantly affect the current performance of the
Web Analytics service application for deployments that have a large site hierarchy, which
includes approximately 100,000 or more SharePoint components. This article might be
updated with the capacity requirements for larger site hierarchies when more information
is available.
Siehe auch
Konzepte
Leistungs- und Kapazitätsverwaltung (SharePoint Server 2010)
Weitere Ressourcen
SharePoint 2010 Administration Toolkit (SharePoint Server 2010)
290
Schätzen der Leistungs- und
Kapazitätsanforderungen für Web
Content Management in SharePoint
Server 2010
Dieser Artikel enthält Hinweise zur Kapazitätsverwaltung von Microsoft SharePoint
Server 2010-Websites, bei denen die Veröffentlichungsinfrastruktur aktiviert wurde.
Dieses Dokument enthält spezifische Hinweise für SharePoint Server 2010; die
erläuterten Informationen beziehen sich nicht auf SharePoint Foundation.
In diesem Artikel werden die folgenden Szenarien erläutert:
 Eine Internetveröffentlichungssite - eine Website für die Präsenz eines
Unternehmens.
Diese Art von Website wird im Internet veröffentlicht und ermöglicht es anonymen
Internetbenutzern, Informationen über ein Unternehmen zu finden. Auf Websites wie
diese wird Branding angewendet, und die Inhalte werden stark gesteuert.
 Eine Intranetveröffentlichungssite - eine Website für interne Nachrichten.
Diese Art von Website wird intern innerhalb einer Organisation veröffentlicht. Ihre
Hauptaufgabe besteht darin, Informationen an authentifizierte Benutzer innerhalb der
Organisation weiterzugeben. Die Informationen in der Website können straff
verwaltet werden, wobei manche Bereiche möglicherweise weniger stark kontrolliert
werden.
 Ein Unternehmenswiki - ein Wissensrepository.
Bei einem Unternehmenswiki handelt es sich um eine Website mit einer einzelnen
Farm, die kontinuierlich anwächst, wenn Mitwirkende neue Seiten erstellen und diese
mit anderen Seiten verknüpfen, die möglicherweise bereits oder noch nicht
existieren. Unternehmenswikis werden in der Regel innerhalb einer Organisation
veröffentlicht. Diese Website ermöglicht es Benutzern innerhalb eines Unternehmens
oder einer Organisation, Wissen mithilfe einer Lösung, die in ihre SharePointUmgebung integriert ist und optimiert wird, zu erfassen und gemeinsam zu nutzen.
Nach der Lektüre dieses Dokuments sind Sie mit den folgenden Konzepten vertraut:
 Die Schlüsselmetriken (Durchsatz), die zur Unterstützung von vielen Lesevorgängen
maximiert werden sollten.

Verschiedene potenzielle Engpässe, die für die SharePoint Server 2010Bereitstellung mit Web Content Management relevant sind.

Die Bedeutung des Ausgabecaches bei der Maximierung des Durchsatzes.

Die Auswirkungen von Schreibvorgängen auf die Benutzerfreundlichkeit für
Endbenutzer beim Lesen.
Inhalt dieses Artikels
 Voraussetzungen
291

Testdetails und Ansatz

Web Content Management-Bereitstellungen

Optimierung

Testergebnisse und Empfehlungen

Informationen zu den Autoren
Voraussetzungen
Ehe Sie mit der Lektüre dieses Dokuments beginnen, sollten Sie mit den
Schlüsselkonzepten der SharePoint Server 2010-Kapazitätsverwaltung vertraut sein. Die
folgende Dokumentation bietet Informationen über den empfohlenen Ansatz für die
Kapazitätsverwaltung und enthält Kontext, der Ihnen dabei hilft, die Informationen in
diesem Dokument sinnvoll einzusetzen.
Weitere konzeptionelle Informationen zur Leistung und Kapazität, die sich für das
Verständnis des Kontexts der Daten in diesem Artikel als hilfreich erweisen können,
finden Sie in den folgenden Dokumenten:
 Kapazitätsverwaltung und Größenanpassung für SharePoint Server 2010

Technische Fallstudien zu Leistung und Kapazität (SharePoint Server 2010)
Testdetails und Ansatz
Bei jedem Test kommen Variablen aus der realen Welt vor, die zur Darstellung
bestimmter Empfehlungen abstrahiert wurden. Deshalb ist es äußerst wichtig, dass Sie
die Tests und Kontrollen in Ihrer eigenen Umgebung ausführen, um eine korrekte
Skalierung sicherzustellen, die an das zu erwartende Anforderungsvolumen angepasst
ist. Weitere Informationen zu den Konzepten der Kapazitätsverwaltung finden Sie unter
Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht).
In diesem Artikel wird die Leistung im Zusammenhang mit Websitesammlungs-Features,
der SharePoint Server-Veröffentlichungsinfrastruktur und dem Zwischenspeichern der
Ausgabe erläutert. Diese Features stehen nur zur Verfügung, wenn die SharePoint
Server-Veröffentlichungsinfrastruktur aktiviert ist. Dieses Feature ist standardmäßig für
die Veröffentlichungsportale aktiviert.
Dataset
Die Tests wurden mithilfe eines Datasets ausgeführt, das gemeinsame Eigenschaften mit
tatsächlichen Web Content Management-Bereitstellungen aufweist. Bei konstanter
Auslastung wurden verschiedene Seiten angefordert. In der folgenden Tabelle wird das
Dataset für diese Tests beschrieben.
Dataset
Objekt
Veröffentlichungssite
Größe der Inhaltsdatenbanken
2,63 GB
Anzahl der Inhaltsdatenbanken
1
Anzahl der Websitesammlungen
1
292
Objekt
Veröffentlichungssite
Anzahl der Webanwendungen
1
Anzahl der Websites
50
Seitenanzahl
20.000 Seiten, unterteilt in 20 Ordner mit
jeweils 1.000 Seiten
Zusammensetzung der Seiten
Artikelseiten in einfachem HTML mit
Verweisen auf zwei Bilder
Seitengröße
42 KB unkomprimiert; 12 KB komprimiert
Bilder
3.000 mit jeweils 30 KB bis 1,3 MB
Es wird die Konfiguration der Internetinformationsdienste (Internet Information Services,
IIS) empfohlen, damit Dateien immer komprimiert werden, anstelle der
Standardeinstellung zur dynamischen Komprimierung von Dateien. Wenn die
dynamische Komprimierung aktiviert ist, werden Seiten von IIS komprimiert, bis die CPUAuslastung über einen bestimmten Schwellenwert ansteigt. Die Komprimierung von
Seiten wird erst dann von IIS fortgesetzt, wenn die Auslastung wieder unter den
Schwellenwert sinkt. Die in diesem Artikel aufgeführten Tests wurden stets bei aktivierter
Komprimierung durchgeführt.
In diesem Testdataset wurden nur SharePoint Server 2010-Standardfeatures verwendet,
die zum Lieferumfang des Produkts gehören. Abgesehen von diesen Grundfeatures sind
in Ihrer Website vermutlich Anpassungen enthalten. Deshalb ist es wichtig, dass Sie die
Leistung Ihrer eigenen Lösung testen.
Hardware
Die Anzahl der Webserver in der Farm variierte von einem Test zum anderen. Bei jedem
Test wurde jedoch die identische Hardware verwendet. In der folgenden Tabelle wird die
Hardware von Web- und Anwendungsservern beschrieben, die bei diesen Tests
verwendet wurde.
Hardwarespezifikationen für Anwendungs- und Webserver
Webserver
Prozessoren
2 Quad-Core mit 2,33 GHz
RAM
8 GB
Betriebssystem
Windows Server 2008 (64-Bit)
Größe des SharePoint-Laufwerks
300 GB
Anzahl der Netzwerkadapter
2
Geschwindigkeit des Netzwerkadapters
1 Gigabit
Authentifizierung
Windows-Standardauthentifizierung
293
Webserver
Lastenausgleichstyp
Hardwarelastenausgleich
Softwareversion
SharePoint Server 2010 (Vorabversion)
Lokal ausgeführte Dienste
Zentraladministration
Eingehende Microsoft SharePoint
Foundation-E-Mail
Microsoft SharePoint FoundationWebanwendung
Microsoft SharePoint FoundationWorkflowtimerdienst
In der folgenden Tabelle wird die Hardware der Datenbankserver für diese Tests
beschrieben.
Hardwarespezifikationen für Datenbankserver
Datenbankserver
Prozessoren
4 Quad-Core mit 3,19 GHz
RAM
16 GB
Betriebssystem
Windows Server 2008 (64-Bit)
Speicherung
15 Festplatten mit 300 GB @ 15.000 RPM
Anzahl der Netzwerkadapter
2
Geschwindigkeit des Netzwerkadapters
1 Gigabit
Authentifizierung
NTLM
Softwareversion
Microsoft SQL Server 2008
Glossar
In diesem Dokument werden einige Fachbegriffe verwendet. Es folgen die Definitionen
zu einigen Schlüsselbegriffen:
 Anforderungen pro Sekunde (RPS) Die Anzahl der von einer Farm oder einem
Server in einer Sekunde empfangenen Anforderungen. Die Server- und
Farmauslastung wird häufig mit diesem Wert gemessen.
Beachten Sie, dass zwischen Anforderungen und dem Laden von Seiten ein
Unterschied besteht; jede Seite enthält verschiedene Komponenten, durch die beim
Laden der Seite eine oder mehrere Anforderungen erstellt werden. Deshalb werden
beim Laden einer einzelnen Seite verschiedene Anforderungen erstellt. In der Regel
werden beim Messen von RPS Überprüfungen der Authentifizierung und Ereignisse,
die wenig Ressourcen benötigen, nicht gezählt.
294

Grüner Bereich Dies ist der Zustand, in dem der Server die folgenden Kriterien
einhalten kann:

Die serverseitige Wartezeit beträgt bei mindestens 75 Prozent der
Anforderungen weniger als 1 Sekunde.

Alle Server weisen eine CPU-Auslastung von weniger als 50 Prozent auf.

Die Fehlerrate ist niedriger als 0,01 Prozent.
Web Content Management-Bereitstellungen
Es existieren zwei Modelle für das Erstellen von Inhalten in SharePointVeröffentlichungssites, die sich auf die Wahl der Serverfarmtopologie auswirken können.
Beim Modell der direkten Dokumenterstellung wird eine einzelne Websitesammlung
von Autoren und Besuchern gemeinsam genutzt. Autoren können Inhalte erstellen und
jederzeit aktualisieren, was zu einer variablen Verteilung von Lese- und
Schreibvorgängen im Verlauf eines bestimmten Tages führt. In einer solchen Serverfarm
werden in der Regel viele Lesevorgänge und eine begrenzte Anzahl von
Schreibvorgängen verzeichnet.
Im folgenden Diagramm wird die Funktionsweise der direkten Dokumenterstellung aus
Sicht der Topologie dargestellt.
Beim Modell der Inhaltsbereitstellung wird das Erstellen und Veröffentlichen von
Inhalten von mehreren Websitesammlungen getrennt und exklusiv unterstützt. Inhalt wird
in der Erstellungsumgebung erstellt und dann in regelmäßigen Abständen in der
Veröffentlichungsumgebung bereitgestellt, um von Besuchern gelesen zu werden. In der
Veröffentlichungsumgebung werden in erster Linie Leseanforderungen ausgeführt, mit
Ausnahme der Bereitstellung von Inhalt aus der Erstellungsumgebung. Im Gegensatz
zum Modell der direkten Dokumenterstellung kann die Serverlast, die von der
Inhaltsbereitstellung ausgeht, auf regelmäßige Intervalle angepasst werden.
Im folgenden Diagramm wird die Funktionsweise der Inhaltsbereitstellung aus Sicht der
Topologie dargestellt.
Diese Modelle der Inhaltserstellung schließen sich gegenseitig aus.
Obwohl für Internetveröffentlichungssites und Intranetveröffentlichungssites sowohl das
Modell der direkten Dokumenterstellung als auch der Inhaltsbereitstellung verwendet
werden kann, werden Unternehmenswikis am besten mit der direkten Inhaltserstellung
ausgeführt. Bei einem Unternehmenswiki werden in der Regel mehr Schreibvorgänge als
Lesevorgänge verzeichnet, da ein höherer Anteil von Benutzern Seiten bearbeiten kann.
295
Unternehmenswikiseiten unterscheiden sich von Veröffentlichungsseiten und zeichnen
sich durch andere Leistungseigenschaften aus.
Optimierung
Dieser Abschnitt enthält Informationen über die Optimierung Ihrer Web Content
Management-Umgebung. Zur Optimierung der Umgebung gehört auch die Verwaltung
des Durchsatzes, von Engpässen und der Zwischenspeicherung.
Inhalt dieses Abschnitts:
 Durchsatz als Schlüsselmetrik

Engpässe und Abhilfe

Hilfe durch Caching
Durchsatz als Schlüsselmetrik
Durchsatz und Antwortzeit sind die wichtigsten Metriken, die bei der Kapazitätsplanung
einer Web Content Management-Bereitstellung von SharePoint Server 2010 optimiert
werden müssen. Der Durchsatz gibt die Anzahl der Vorgänge an, die in einer Serverfarm
pro Sekunde durchgeführt werden können, gemessen in Anforderungen pro Sekunde
(RPS).
Engpässe und Abhilfe
Eine Systemressource, durch die bei einem Mangel verhindert wird, dass zusätzliche
Anforderungen in der Serverfarm bereitgestellt werden, ist ein Engpass. Im folgenden
Diagramm werden die Elemente einer Serverfarm dargestellt, die zu Engpässen werden
können und überwacht werden sollten.
296
CPU-Auslastung der Webserver
Die Webserver-CPU sollte den Engpass in einer gut abgestimmten Topologie darstellen,
da sie die am einfachsten zu skalierende Komponente darstellt. Anforderungen werden
297
vom Lastenausgleichsmodul zwischen den Webservern weitergeleitet, der auch
sicherstellt, dass kein einzelner Server deutlich mehr beansprucht wird als andere.
Obwohl zusätzliche Benutzer die Website besuchen können, nachdem die WebserverCPU vollständig ausgelastet ist, steigt die Serverantwortzeit für diese Benutzer. Dieses
Verhalten erweist sich bei der Verwaltung von Belastungsspitzen beim
Anforderungsvolumen als hilfreich. Eine anhaltende Auslastung hingegen, die über die
Kapazität der Serverfarm hinausgeht, führt schließlich zu Rückständen, die so groß sind,
dass der Schwellenwert für wartende Anforderungen überschritten wird. An diesem Punkt
werden die Anforderungen von den Webservern gedrosselt und der HTTP-Fehler 503
ausgegeben. In der folgenden Abbildung ist das Absinken der Serverantwortzeit nach
Überschreiten des Schwellenwerts für wartende Anforderungen dargestellt, weil
ausschließlich HTTP-Fehler ausgegeben werden.
Die folgenden Änderungen werden in diesem Diagramm veranschaulicht:
1. Antwortzeit steigt, wenn die CPU-Auslastung der Webserver gegen 100 Prozent
steigt.
2. Nach Überschreiten des Schwellenwerts für wartende Anforderungen werden bei
weiteren Anforderungen Fehler ausgegeben.
298
Sonstige Engpässe
Wenn die Webserver-CPU nicht den Engpass darstellt, sollten als nächstes die
Farmtopologie, die Farmkonfiguration oder der Inhalt der bereitgestellten Seiten als
mögliche Engpässe überprüft werden. Potenzielle Engpässe können u. a. die folgenden
Elemente sein:
1. Netzwerk In Situationen mit hohem Durchsatz kann entweder das Netzwerk
zwischen dem Webserver und dem Datenbankserver oder zwischen dem Webserver
und Endbenutzern gesättigt sein. Sie können diese Situation vermeiden, indem Dual
Gigabit-Netzwerkadapter für die Webserver verwendet werden.
2. Datenbankserver-CPU Wenn die CPU des Datenbankservers den Engpass
darstellt, kann der maximale Durchsatz der Farm durch Hinzufügen von Webservern
zur Serverfarm nicht gesteigert werden. Ein Engpass der Datenbank-CPU, jedoch
nicht der Webserver-CPUs, kann mit zwei Situationen zusammenhängen:
a) Unzureichende Cacheeinstellungen oder äußerst langsame Seiten, vor allem
jene, deren Ausgabe nicht zwischengespeichert wird. Dieser Zustand
zeichnet sich durch eine hohe CPU-Auslastung des Datenbankservers,
kombiniert mit niedrigem oder mittlerem Durchsatz und niedriger oder
mittlerer Webserverauslastung aus.
b) Möglicherweise hat der Datenbankserver die Kapazitätsgrenze für den für
die Farm erforderlichen Durchsatz erreicht. Dieser Zustand zeichnet sich
durch eine hohe CPU-Auslastung von Webserver und Datenbankserver bei
hohem Durchsatz aus.
Hilfe durch Caching
In SharePoint Server 2010 werden drei Arten von Caching verwendet. Gemeinsames Ziel
dieser Caches ist es, die Effizienz durch Senken der Aufrufe an die Datenbank nach
häufig angeforderten Daten zu verbessern. Nachfolgende Anforderungen einer Seite
können vom Cache des Webservers bedient werden, was eine signifikant niedrigere
Ressourcenauslastung auf den Web- und Datenbankservern zur Folge hat.
Die drei Arten des Caching sind folgende:
 Ausgabecache Dieser Cache speichert angeforderte Seiteninhalte im
Arbeitsspeicher des Webservers. Weitere Informationen zum Ausgabecache finden
Sie unter Ausgabezwischenspeicherung und Cacheprofile
(http://go.microsoft.com/fwlink/?linkid=121543&clcid=0x407).

Objektcache Dieser Cache speichert SharePoint-Objekte, wie Web- und
Listenelement-Metadaten, im Arbeitsspeicher des Webservers. Weitere
Informationen zum Objektcache finden Sie unter Objectzwischenspeicherung
(http://go.microsoft.com/fwlink/?linkid=123948&clcid=0x407).

Datenträgerbasierter Cache für BLOBs (Binary Large Objects) Dieser Cache
speichert Bild-, Sound-, Grafikdateien sowie andere umfangreiche Binärdateien auf
Datenträgern. Weitere Informationen zum BLOB-Cache finden Sie unter
Datenträgerbasiertes Zwischenspeichern für BLOBs
(http://go.microsoft.com/fwlink/?linkid=123947&clcid=0x407).
Jeder dieser Caches ist für die Beibehaltung eines hohen Durchsatzes wichtig. Die
Aktivierung des Ausgabecaches hat jedoch die stärksten Auswirkungen und wird in
diesem Artikel ausführlich besprochen.
299
Testergebnisse und Empfehlungen
In diesem Abschnitt werden bestimmte Testbereiche erläutert und Empfehlungen
gegeben, die aus diesen Tests resultieren.
Inhalt dieses Abschnitts:
 Auswirkungen aus der Aktivierung des Ausgabecaches

Anonyme und authentifizierte Benutzer

Skalierungseigenschaften von Lese- und Schreibvorgängen

Einschränkungen im Zusammenhang mit dem Ausgabecache

Auswirkungen des Volumens von Lesevorgängen auf die CPU und die Antwortzeit

Auswirkungen von Schreibvorgängen auf den Durchsatz

Auswirkungen der Inhaltsbereitstellung

Auswirkungen von Datenbankmomentaufnahmen während des Exports bei der
Inhaltsbereitstellung

Eigenschaften von Inhalten
Auswirkungen aus der Aktivierung des Ausgabecaches
Der Ausgabecache zeichnet sich als ein wertvolles Feature bei der Optimierung einer
SharePoint Server 2010-Lösung für hohe Mengen an Lesevorgängen aus.
Im Rahmen dieser Tests wurde zur Messung der maximalen RPS die Anzahl der aktiven
Benutzer, die Anforderungen an die Farm sendeten, so lange gesteigert, bis der
Datenbankserver oder die Webserver 100 Prozent erreichten und einen Engpass
darstellten. Der Test wurde auf den Farmtopologien 1x1 (ein Webserver und ein
Datenbankserver), 2x1, 4x1 und 8x1 ausgeführt, um die Auswirkungen durch die
horizontale Skalierung der Webserver bei verschiedenen Ausgabecache-Trefferraten
vorzuführen.
Ausgabecache-Trefferrate
Bei der Ausgabecache-Trefferrate werden die Ausgabecachetreffer im Verhältnis zu
Cachefehlern gemessen.
 Ein Cachetreffer tritt auf, wenn der Cache eine Anforderung nach Objektdaten erhält,
die bereits im Cache gespeichert sind.

Ein Cachefehler tritt auf, wenn eine Anforderung nach Objektdaten eintrifft, die nicht
im Cache gespeichert sind. Bei einem Cachefehler versucht der Cache, die
angeforderten Objektdaten so zu speichern, dass nachfolgende Anforderungen
dieser Daten einen Cachetreffer zur Folge haben.
Eine Seitenanforderung kann aus verschiedenen Gründen zu einem Cachefehler führen.
 Seiten, die so konfiguriert wurden, dass kein Ausgabecache verwendet wird.

Personalisierte Seiten, beispielsweise Seiten mit Daten, die für den aktuellen
Benutzer spezifisch sind.

Erstmaliges Durchsuchen per Ausgabecache-Variationsschlüssel.
 Erstmaliges Durchsuchen nach Ablauf des zwischengespeicherten Inhalts.
Im folgenden Diagramm werden die Auswirkungen des Zwischenspeicherns von
Ausgaben auf den Spitzendurchsatz in Farmen mit einer Größe zwischen einem und vier
Webservern und einem Datenbankserver dargestellt.
300
Hinweis:
Der Datenpunkt für die maximale RPS in einer 4x1-Serverfarm mit einer AusgabecacheTrefferrate von 100 Prozent wurde extrapoliert und nicht tatsächlich ermittelt. Das
Anforderungsvolumen der Serverfarm erreichte die Bandbreitengrenze (die
Datenübertragungsrate erreichte also 1 Gigabit pro Sekunde). In allen Fällen lag die
CPU-Auslastung der Webserver bei 100 Prozent.
Die folgende Tabelle enthält eine Liste der Auswirkungen der Ausgabecache-Trefferraten
auf Farmtopologien mit 1 bis 4 Webservern und einem Datenbankserver.
Auswirkungen der Ausgabecache-Trefferrate auf verschiedene
Farmtopologien
Ausgabecache- Measure
Trefferrate
1x1
2x1
301
4x1
Ausgabecache- Measure
Trefferrate
1x1
2x1
4x1
3.463
7.331
11.032
CPU-Auslastung 0%
von SQL Server
0%
0%
Maximale RPS
3.945
5.937
CPU-Auslastung 5,93%
von SQL Server
12,00%
21,80%
Maximale RPS
2.864
4.518
CPU-Auslastung 7,12%
von SQL Server
14,40%
28,00%
Maximale RPS
913
1.596
CPU-Auslastung 9,86%
von SQL Server
19,50%
42,00%
Maximale RPS
339
638
19,00%
36,30%
100%
Maximale RPS
95%
2.137
90%
1.518
50%
459
0%
172
CPU-Auslastung 9,53%
von SQL Server
Schlussfolgerungen und Empfehlungen im Hinblick auf die
Aktivierung des Ausgabecaches
Höhere Ausgabecache-Trefferraten haben signifikante Steigerungen der maximalen RPS
zur Folge. Deshalb wird die Aktivierung des Ausgabecaches empfohlen, um die
SharePoint Server 2010-Veröffentlichungslösung zu optimieren. Der Ausgabecache kann
auf der Seite mit den Ausgabecacheeinstellungen für die Websitesammlung konfiguriert
werden. Weitere Informationen finden Sie unter Konfigurieren der Seitenausgabe302
Cacheeinstellungen für eine Websitesammlung
(http://go.microsoft.com/fwlink/?linkid=205058&clcid=0x407) auf der Website
Office.Microsoft.com.
In Tests mit aktiviertem Ausgabecache wurde die erste Anforderung, bei der eine Seite
zwischengespeichert wurde, weggelassen; ein bestimmter Prozentsatz von Seiten sind
also bereits im Cache gespeichert. Wenn ein Benutzer zuerst eine Seite anfordert, die
nicht zwischengespeichert ist, wird die Seite dem Cache hinzugefügt. Erreicht der Cache
die maximale Kapazität, werden die Daten, deren Anforderung am längsten zurückliegt,
aus dem Cache entfernt.
Bei der Ausgabecache-Trefferrate von 0 Prozent wird der kurze Zeitraum in einer
Umgebung simuliert, während dem der Ausgabecache nach dem Leeren wieder
aufgefüllt wird. Dies findet beispielsweise täglich in einer realen Umgebung statt, wenn
der Anwendungspool wiederverwendet wird. Die adäquate vertikale oder horizontale
Skalierung Ihrer Hardware ist wichtig in Situationen mit einer Cache-Trefferrate von
0 Prozent für den kurzen Zeitraum zwischen der Wiederverwendung des
Anwendungspools und dem nächsten Anfordern und Zwischenspeichern von Seiten. Die
Cachetrefferrate von 0 Prozent simuliert auch eine Umgebung, in der der
Ausgabespeicher nicht aktiviert wurde.
Anonyme und authentifizierte Benutzer
Im vorhergehenden Test wurde angenommen, dass alle Anforderungen für die Website
von anonymen Lesern stammen. In Ihrer Website sind einige oder sogar alle Benutzer
möglicherweise authentifiziert. Beispiele für authentifizierte Leseszenarien sind u. a. eine
Intranetveröffentlichungssite in einem Unternehmen und für Mitglieder vorbehaltene
Inhalte einer Internetwebsite.
Mithilfe von Ausgabecacheprofilen können Sie das Ausgabecacheverhalten für
authentifizierte Benutzer festlegen, das vom Verhalten für anonyme Benutzer abweicht.
Cacheprofile
In den Cacheprofilen werden Einstellungen gesammelt, die Sie auf Seiten,
Seitenelemente, Inhaltstypen und Skalierungsebenen in einer Websitebereitstellung
anwenden können. Durch ein Cacheprofil werden die folgenden Arten von
Cacheverhalten definiert:
 Die Zeitdauer, die Elemente im Cache aufbewahrt werden sollten.

Die Sicherheitsrichtlinie für Trimming.

Das Ablaufdatum von Einstellungen, wie z. B. Dauer und Änderungen.

Die Variationen zwischengespeicherter Inhalte, z. B. auf der Grundlage von
Benutzerberechtigungen, Benutzerrechten und sonstigen benutzerdefinierten
Variablen.
Alle Änderungen am Cacheprofil wirken sich unmittelbar auf die entsprechenden Inhalte
der Website aus. Sie können verschiedene Cacheprofile für anonyme Benutzer und
authentifizierte Benutzer festlegen.
Für anonyme Benutzer wurde das Ausgabecacheprofil Öffentliches Internet (vollständig
anonym) verwendet, während für authentifizierte Benutzer das Ausgabecacheprofil
Extranet (veröffentlichte Website) verwendet wurde.
Im folgenden Diagramm sind die Auswirkungen des authentifizierten Durchsatzes auf die
CPU-Auslastung des Datenbankservers dargestellt.
303
Als Authentifizierungsmodell wurde die Windows-Standardauthentifizierung verwendet.
Obwohl die Verwendung der Windows-Standardauthentifizierung nicht für Internetsites
empfohlen wird, wurde diese Authentifizierungsmethode gewählt, um vorzuführen, dass
zusätzlicher Aufwand durch die Authentifizierung entsteht. Der Umfang des Aufwands
hängt von Ihrem spezifischen Authentifizierungsmechanismus ab. Wenn Sie Ihre
Bereitstellung testen, sollten Sie die Auswirkungen des Authentifizierungsmechanismus
berücksichtigen. Weitere Informationen zu den von SharePoint Server 2010 unterstützten
Authentifizierungsmechanismen finden Sie unter Plan authentication methods
(SharePoint Server 2010).
Schlussfolgerungen und Empfehlungen für anonyme und
authentifizierte Benutzer
Bei authentifizierten Benutzern sind die Anforderungen pro Sekunde (RPS) niedriger, und
es besteht ein geringeres horizontales Skalierungspotenzial, da für die Überprüfung der
Anmeldeinformationen zusätzliche Last für den Datenbankserver entsteht. Wie in den
Testergebnissen gezeigt, ist die maximale RPS bei authentifizierten Benutzern signifikant
niedriger als bei einer Farm mit anonymem Zugriff.
Skalierungseigenschaften von Lese- und Schreibvorgängen
Bei unseren Tests wurden die Schreibvorgänge pro Stunde aufgezeichnet. Im Rahmen
dieses Artikels bezeichnet ein Schreibvorgang entweder das Erstellen und Einchecken
einer neuen Veröffentlichungsseite oder das Bearbeiten und Einchecken einer
vorhandenen Veröffentlichungsseite.
Für die folgenden Tests wurden dem System so lange Leser hinzugefügt, bis die CPUAuslastung der Webserver ca. 80-90 Prozent erreichte. Dann wurden Schreibvorgänge in
der Umgebung unter Anwendung einer künstlichen Verzögerung ausgeführt. Die
304
Gesamtanzahl der Schreibvorgänge pro Stunde für den Test betrug ca. 500. Bei allen
Tests wurde eine Ausgabecache-Trefferrate von 90 Prozent verwendet. Derselbe Test
wurde für die Farmtopologien 1x1, 2x1 und 4x1 ausgeführt; zusätzlich zum
Gesamtdurchsatz der Lesevorgänge für die einzelnen Konfigurationen wurde die CPUAuslastung der Webserver und von SQL Server ermittelt. Darüber hinaus wurde eine
anonyme schreibgeschützte Konfiguration als Baseline und eine Konfiguration mit
authentifizierten Lesern unter Verwendung der Windows-Standardauthentifizierung
getestet.
Obwohl die Webserver-CPU während der schreibgeschützten Skalierungstests bei
100 Prozent vollständig ausgelastet war, wurde die CPU-Auslastung der Webserver bei
den Skalierungstests mit Schreibvorgängen bei 80-90 Prozent gehalten. Damit sollte bei
der Ausführung von Schreibvorgängen eine zusätzliche CPU-Auslastung möglich sein.
Das folgende Diagramm zeigt die Gesamt-RPS für Lesevorgänge, die während der
einzelnen Tests ermittelt wurde. Die RPS für Lesevorgänge skaliert linear, während
zusätzliche Webserver hinzugefügt werden, selbst bei Schreibaktivität. Werden
Schreibvorgänge hinzugefügt, sinkt der Wert von RPS jedoch.
Die CPU-Auslastung des Datenbankservers nahm bei steigender Anzahl von
305
Webservern zu. Im folgenden Diagramm werden die Trends für die Zunahme der SQL
Server-CPU-Auslastung in den verschiedenen Konfigurationen dargestellt. Wie im
Abschnitt Anonyme und authentifizierte Benutzer weiter oben in diesem Artikel erwähnt,
wirkt sich die Authentifizierung auf die CPU-Auslastung des Datenbankservers aus, was
sich bei zusätzlicher Schreibaktivität noch verstärkt (was sich ebenfalls auf die CPUAuslastung des Datenbankservers auswirkt).
Der extrapolierte Trend bei der SQL Server-Verwendung zeigt, dass SQL Server bei
sechs Webservern mit authentifizierten Leseanforderungen zum Engpass wird. Bei den
anonymen Lesevorgängen hingegen ist die vertikale Skalierung zu einer größeren
Anzahl von Webservern machbar.
Es ist wichtig, darauf zu achten, dass sich zusätzliche Faktoren in einer
Standardbereitstellung auf die Auslastung des Datenbankservers auswirken; diese
Faktoren müssen bei der Kapazitätsplanung berücksichtigt werden. Wenn Sie mehr über
die Bestimmung eines grünen Bereichs für die CPU-Standardauslastung von
Datenbankservern erfahren möchten, lesen Sie die Informationen unter
Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht).
306
Schlussfolgerungen und Empfehlungen für
Skalierungseigenschaften von Lese- und Schreibvorgängen
Unsere Daten zeigen, dass die vertikale Skalierung der Anzahl von Webservern eine
effektive Strategie zur Steigerung des Durchsatzes ist, sofern der Datenbankserver nicht
den Engpass darstellt. Im Durchschnitt führte die Testmischung aus anonymen
Lesevorgängen und authentifizierten Schreibvorgängen zu einer Steigerung um
52 Prozent bei der Webserver-CPU-Auslastung verglichen mit einer Testmischung aus
anonymen Lesevorgängen und keinen Schreibvorgängen. Darüber hinaus steigt die
zusätzliche SQL Server- Auslastung bei authentifizierten Lesevorgängen stark an, da bei
jeder Anforderung zusätzliche Authentifizierungsprüfungen ausgeführt werden, die einen
Roundtrip zu SQL Server erfordern.
Im folgenden Diagramm sind die Auswirkungen des Durchsatzes auf die CPUAuslastung des Datenbankservers dargestellt.
Einschränkungen im Zusammenhang mit dem Ausgabecache
307
Wenn das einzige Anliegen bei der Kapazitätsplanung die Maximierung der RPS wäre,
könnte aus diesen Tests die Schlussfolgerung gezogen werden, dass die optimale
Cachetrefferrate bei 100 Prozent liegt. Aufgrund von Anforderungen hinsichtlich der
Datenaktualität oder von Speicherbeschränkungen ist es jedoch nicht möglich oder
wünschenswert, die Zwischenspeicherung der Ausgabe einiger oder aller Seiten zu
aktivieren.
Datenaktualität
Daten, die aus dem Ausgabecache stammen, enthalten möglicherweise keine kürzlich
vorgenommenen Aktualisierungen des Originalinhalts. In der Quelle der
Inhaltsbereitstellung oder (für authentifizierte Autoren) in einem direkten
Dokumenterstellungsszenario sind Autoren daran interessiert, dass neueste Änderungen
direkt nach dem Aktualisieren des vorhandenen Inhalts angezeigt werden.
Dies wird in der Regel durch Festlegen der Eigenschaft Dauer im Cacheprofil erreicht;
diese Eigenschaft gibt an, wie lange eine zwischengespeicherte Seite im Ausgabecache
vor dem Ablaufen aufbewahrt wird. Nach Ablauf der Seite wird sie aus dem Cache
entfernt und eine nachfolgende Anforderung führt zu einem Cachefehler, durch den der
Seiteninhalt aktualisiert wird.
Die Eigenschaft Auf Änderungen überprüfen im Cacheprofil kann ebenfalls festgelegt
werden; dabei vergleicht der Server den Zeitpunkt der Zwischenspeicherung einer Seite
mit dem Zeitpunkt der letzten Änderung in einer Websitesammlung. Die Anforderung
einer Seite mit nicht übereinstimmenden Zeitstempeln hat die Cacheinvalidierung aller
Seiten in der Websitesammlung zur Folge. Da sich die Eigenschaft Auf Änderungen
überprüfen auf alle Seiten in einer Websitesammlung auswirkt, wird empfohlen, diese
Option nur bei einer direkten Dokumenterstellungslösung zu aktivieren, die selten
aktualisiert und im Grunde genommen statisch ist. Die Kombination dieser Option mit
einer langen Dauer bietet die Möglichkeit, dass alle Seiten aus dem Cache bereitgestellt
werden, bis eine Aktualisierung an der Website vorgenommen wird.
Die Eigenschaft Auf Änderungen überprüfen ist standardmäßig nicht aktiviert. Das
bedeutet, dass der Webserver Daten aus dem Ausgabecache als Antwort auf
Anforderungen nach einer noch nicht abgelaufenen Seite bereitstellt, unabhängig davon,
ob die zugrunde liegende ASPX-Originalseite geändert wurde oder nicht.
In diesem in einer Serverfarm mit 1x1-Topologie ausgeführten Test stimmen alle
Variablen mit den Variablen der Tests im Abschnitt Skalierungseigenschaften von Leseund Schreibvorgängen überein, mit Ausnahme der Eigenschaft Auf Änderungen
überprüfen. Wenn die Eigenschaft Auf Änderungen überprüfen aktiviert ist, wird der
Cache häufiger geleert, was zu einer niedrigeren Ausgabecache-Trefferrate führt.
Im folgenden Diagramm sind die Auswirkungen der Eigenschaft Auf Änderungen
überprüfen auf den Durchsatz dargestellt.
308
Die Verwendung der Eigenschaft Auf Änderungen überprüfen im Ausgabecacheprofil
wird, abgesehen von Sonderfällen, nicht empfohlen. Eine Website, in der das Modell der
direkten Dokumenterstellung verwendet wird und nur selten inhaltliche Änderungen
vorgenommen werden, kann für authentifizierte Benutzer zusammen mit einer langen
Cachedauer möglicherweise von dieser Einstellung profitieren; bei anderen Arten von
Websites ist vermutlich jedoch eine Verschlechterung der RPS feststellbar.
Abhängig von Ihren Anforderungen ist es sinnvoll, dass Inhalte, bei denen die Aktualität
eine wichtige Rolle spielt, sofort oder zumindest schneller als dies die
Standardeinstellungen unterstützen, angezeigt werden. In diesem Fall sollten Sie die
Dauer reduzieren oder das Zwischenspeichern von Ausgaben nicht aktivieren.
Schlussfolgerungen und Empfehlungen im Hinblick auf die
Einschränkungen des Ausgabecaches
Durch das Zwischenspeichern von Ausgaben werden nicht alle Probleme im
Zusammenhang mit der Kapazitätsverwaltung gelöst. In einigen Situationen ist die
Zwischenspeicherung von Ausgaben nicht sinnvoll, was Sie beim Aktivieren des
Ausgabecaches und dem Konfigurieren der Ausgabecacheprofile bedenken sollten.
Auswirkungen des Volumens von Lesevorgängen auf die CPU und
die Antwortzeit
Dieser Test wurde auf einer 1x1-Farm mit anonymem Zugriff und aktiviertem
Ausgabecache durchgeführt.
309
Im folgenden Diagramm sind die Auswirkungen des Volumens von Lesevorgängen auf
die CPU und die Antwortzeit dargestellt.
Schlussfolgerungen und Empfehlungen im Hinblick auf die
Auswirkungen des Volumens von Lesevorgängen auf die CPU und
die Antwortzeit
Wie im Abschnitt Engpässe und Abhilfe erläutert, bleibt die Serverantwortzeit im
Allgemeinen konstant bis der Webserver ausreichend Anforderungsvolumen empfangen
hat, sodass die CPU vollständig ausgelastet ist. Bei vollständiger Auslastung der
Webserver-CPU steigt die Antwortzeit signifikant. Die Serverfarm ist jedoch weiterhin in
der Lage, zusätzliches Anforderungsvolumen zu bearbeiten.
Auswirkungen von Schreibvorgängen auf den Durchsatz
Das Verhältnis zwischen Erstellungs- und Bearbeitungsvorgängen ist über die Dauer der
Tests gleichmäßig verteilt. Die Werte für Schreibvorgänge pro Stunde wurden bis ca. 500
getestet, da das Erstellen oder Bearbeiten von mehr als 500 Seiten pro Stunde
außerhalb des Bereichs liegt, in dem sich die meisten SharePoint-Bereitstellungen
bewegen. Bei diesem Test wurden keine automatisierten Prozesse erfasst, wie die
Inhaltsbereitstellung, die im Abschnitt Auswirkungen der Inhaltsbereitstellung besprochen
ist. Diese Erstellungs- und Bearbeitungsvorgänge können zu mehreren SQL ServerVorgängen führen. Deshalb ist es wichtig, zu wissen, dass die in diesen Tests
gemessenen Schreibvorgänge sich nicht auf der SQL Server-Ebene befinden, sondern
310
dem entsprechen, was von einem Benutzer als Schreibvorgang betrachtet wird. Alle
Tests von RPS verglichen mit Schreibvorgängen pro Stunde wurden in einer 1x1-Farm
durchgeführt.
Zunächst wurden dem Test so lange Lesevorgänge hinzugefügt, bis die Webserver-CPU
einen Wert zwischen 60 und 80 Prozent erreichte, um Puffer für Belastungsspitzen zu
lassen. Diese durchschnittliche Auslastung wurde im Verlauf des Tests beibehalten.
Dann wurden Schreibvorgänge unter Anwendung einer künstlichen Verzögerung zur
Steuerung der Anzahl der Schreibvorgänge hinzugefügt. Während der Schreibvorgänge
traten jedoch Spitzen bei der Auslastung der Webserver- und SQL Server-CPU auf.
Einige dieser Spitzen überschritten bei einigen Cachetrefferraten den Schwellenwert für
Normalbetrieb, wie im folgenden Diagramm dargestellt, obwohl der Durchschnitt
innerhalb der Spanne für Normalbetrieb lag.
Wie im vorhergehenden Diagramm zu sehen, ist eine geringe Reduzierung des
Durchsatzes feststellbar, wenn der Umgebung Schreibvorgänge hinzugefügt werden. Im
Diagramm wird die Änderung des Durchsatzes zwischen einem schreibgeschützten
Szenario und Lesevorgängen im Verlauf von ca. 500 Schreibvorgängen pro Stunde
veranschaulicht. Für jede Ausgabecache-Trefferrate wurden zwei Datenpunkte
aufgezeichnet. Deshalb ist das Verhältnis zwischen Datenpunkten nicht unbedingt linear.
311
Die Reduzierung des Prozentwertes fällt bei niedrigeren Cachetrefferraten deutlicher aus,
wie im folgenden Diagramm zu sehen. Die Gesamt-RPS für Lesevorgänge bleibt,
unabhängig von den Schreibvorgängen, weitgehend abhängig von der AusgabecacheTrefferrate.
Im folgenden Diagramm wird gezeigt, dass die Datenbankserver-CPU-Auslastung bei
Hinzufügen von Schreibvorgängen zum System nicht merklich anstieg. Beachten Sie,
dass die vertikale Skalierung zwischen 0 und 10 Prozent der CPU-Auslastung liegt.
312
Während der Schreibvorgänge wurde erwartungsgemäß eine zusätzliche SQL ServerAuslastung festgestellt. Die höchste Steigerung lag jedoch bei 2,06 Prozent, was nicht
signifikant ist. Die durchschnittliche Datenbankserver-CPU-Auslastung blieb im Verlauf
aller Tests unter 10 Prozent. Dieser Test wurde in einer 1x1-Farm durchgeführt. Die
Datenbankserver-CPU-Auslastung steigt, wenn die Anzahl der Webserver horizontal
skaliert wird. Weitere Informationen hierzu finden Sie unter Skalierungseigenschaften von
Lese- und Schreibvorgängen.
Während der Tests wurde auch die Webserver-CPU-Auslastung gemessen. Im
folgenden Diagramm wird deutlich, dass die durchschnittliche Webserver-CPUAuslastung im Bereich von 60-80 Prozent während der Tests blieb, selbst als die Anzahl
der Schreibvorgänge pro Stunde 500 erreichte.
313
Die gemessene CPU-Auslastung erreicht jedoch Spitzenwerte während der
Schreibvorgänge, wie im folgenden Diagramm zu sehen. Im Allgemeinen stellen diese
CPU-Spitzen kein Problem dar. Zweck des grünen Bereichs ist es, CPU-Reserven
freizuhalten, um Spitzen bei der CPU-Auslastung abfangen zu können. Wenn zusätzliche
Webserver hinzugefügt werden, werden darüber hinaus die Spitzen zwischen diesen
Servern verteilt, sodass die Auswirkungen auf die CPU eines einzelnen Webservers
geringer ausfallen. Sie sollten jedoch wissen, dass solche Spitzen in tatsächlichen
Bereitstellungen zu erwarten sind; die Aktivität von Schreibvorgängen ist nicht
gleichmäßig verteilt, da sie im Allgemeinen in Bursts auftritt.
314
Eine Cachetrefferrate von 90 Prozent ist bei einer Standardbereitstellung sehr niedrig.
Die meisten SharePoint Server 2010-Bereitstellungen mit zahlreichen Lesevorgängen
weisen eine Ausgabecache-Trefferrate von 95 Prozent oder höher auf.
Schlussfolgerungen und Empfehlungen im Hinblick auf die
Auswirkungen von Schreibvorgängen auf den Durchsatz
Die präsentierten Daten zeigen, dass Schreibvorgänge keine umfassenden negativen
Auswirkungen auf den Gesamtdurchsatz des Systems für Leser haben. Sie sollten sich
bewusst sein, dass die Aktivität von Schreibvorgängen zu Spitzen bei der CPUAuslastung führen kann und Ihre Standardkonfiguration unter Berücksichtigung dieser
Spitzen planen. Die richtige Strategie zum Ausgleichen dieser Spitzen besteht darin, auf
mehrere Webserver zu skalieren. Dies bringt zwei Vorteile mit sich:
 Verteilung der Last durch Schreibvorgänge auf mehrere Webserver, wodurch die
Spitzen im Allgemeinen abgeschwächt werden.

Gesteigerte RPS für Lesevorgänge, vor allem bei hohen Ausgabecache-Trefferraten.
Auswirkungen der Inhaltsbereitstellung
315
Eine Alternative zum Modell der direkten Dokumenterstellung, bei der eine einzelne
Umgebung für das Bearbeiten und Lesen verwendet wird, besteht darin, die Umgebung
in zwei getrennte Umgebungen zu unterteilen - eine Umgebung für die
Dokumenterstellung und eine Umgebung für die Produktion. Mithilfe der
Inhaltsbereitstellung wird dann der Inhalt aus der Dokumenterstellungsumgebung in die
Produktionsumgebung kopiert.
In dieser Konfiguration variiert die Produktionsumgebung von geringer Schreibaktivität
bis hin zu keiner Schreibaktivität, außer beim Importieren von Inhalt durch die
Inhaltsbereitstellung. Bei diesen Tests wurden so lange Lesevorgänge hinzugefügt, bis
die Webserver-CPU-Auslastung den Bereich von 70-80 Prozent erreichte. Durch den
Inhaltsbereitstellungsauftrag wurden dann 10 Websites mit jeweils 500 Seiten als Paket
aus der Dokumenterstellungs-Websitesammlung exportiert und das Paket dann in die
Veröffentlichungssitesammlung importiert. Die Größe des bereitgestellten Pakets ist
größer als Pakete in tatsächlichen Umgebungen, um die Dauer des
Inhaltsbereitstellungsauftrags so lange zu verlängern, bis Testergebnisse vorliegen.
Zusätzliche Informationen zu den Eigenschaften des bereitgestellten Inhalts finden Sie im
Abschnitt Dataset.
Nach Abschluss des Exports wird der Inhalt in eine gesonderte Websitesammlung
importiert und die Auslastung von Anwendungsserver und SQL Server während des
Imports zusätzlich zum Durchsatz gemessen. Der Importtest wurde für mehrere
unterschiedliche Ausgabecache-Trefferraten durchgeführt.
Als Wichtigstes konnte festgestellt werden, dass der Import nur eine geringfügige
Auswirkung auf die Gesamt-RPS für Lesevorgänge hat, wie im folgenden Diagramm
dargestellt. Darüber hinaus wurde deutlich, dass der Import unabhängig von der
Cachetrefferrate keine signifikante Auswirkung auf die Webserver-CPU-Auslastung hat,
wie in den folgenden Tabellen zu sehen. Eine deutlichere Auswirkung ergab sich
hingegen für die SQL Server-CPU, wie im folgenden Diagramm dargestellt. Dies war zu
erwarten, da der Datenbankserver einer höheren Auslastung unterliegt, wenn Inhalt
importiert wird. Die Auslastung der SQL Server-CPU blieb jedoch bei allen getesteten
Cachetrefferraten selbst während des Imports unter 12 Prozent.
316
In den folgenden Tabellen werden die Auswirkungen des Imports bei der
Inhaltsbereitstellung auf die CPU-Auslastung von Webserver und Datenbankserver
dargestellt.
Auswirkungen des Imports bei der Inhaltsbereitstellung auf die
Webserver-CPU-Auslastung
Cachetreffer
100%
99%
98%
95%
90%
50%
Baseline
72,32%
73,26% 71,28% 73,53% 71,79% 68,05% 63,97%
Mit Import
70,93%
74,45% 69,56% 74,12% 70,95% 67,93% 63,94%
Auswirkungen des Imports bei der Inhaltsbereitstellung auf die
Datenbankserver-CPU-Auslastung
317
0%
Cachetreffer
100%
99%
98%
95%
90%
50%
0%
Baseline
1,19%
1,64% 2,01% 3,00% 3,73% 5,40% 6,82%
Mit Import
6,03%
6,82% 6,97% 7,96% 8,52% 10,29% 10,56%
Schlussfolgerungen und Empfehlungen im Hinblick auf die
Auswirkungen der Inhaltsbereitstellung
Die Ergebnisse der Tests zeigen, dass die Durchführung von
Inhaltsbereitstellungsvorgängen während regulärer Websitevorgänge keine signifikanten
Leistungsminderungen mit sich bringt. Diese Ergebnisse verdeutlichen, dass es nicht
unbedingt erforderlich ist, Inhalt zu Zeiten mit geringem Datenverkehr bereitzustellen, um
die Auswirkungen des Vorgangs auf die Gesamtleistung zu minimieren. Die
Bereitstellungszeiten können also in erster Linie abhängig von Geschäftsanforderungen
und nicht von Leistungsanforderungen gewählt werden.
Auswirkungen von Datenbankmomentaufnahmen während des
Exports bei der Inhaltsbereitstellung
In SharePoint Server 2010 kann die Inhaltsbereitstellung so konfiguriert werden, dass vor
dem Exportieren des Inhalts aus der Quellinhaltsdatenbank eine Momentaufnahme der
Datenbank erstellt wird. Dadurch wird der Exportvorgang vor
Dokumenterstellungsaktivitäten geschützt, die während des Exports stattfinden.
Momentaufnahmen können sich jedoch auf die Schreibleistung des Datenbankservers
auswirken, da die Momentaufnahme als Multiplikator für die Schreibvorgänge fungiert.
Wenn beispielsweise zwei Momentaufnahmen einer Quelldatenbank vorliegen und Sie
dann in die Quelldatenbank schreiben, werden die bestehenden Daten vom
Datenbankserver in jede Momentaufnahme kopiert und die neuen Daten dann in die
Quelldatenbank geschrieben. Das bedeutet, dass ein einzelner Schreibvorgang in der
Quelldatenbank drei eigentliche Schreibvorgänge mit sich bringt: einen in die
Quelldatenbank und jeweils einen für jede Datenbankmomentaufnahme.
Um die Auswirkungen einer Momentaufnahme auf die Erstellungsumgebung zu ermitteln,
wurde die RPS für Schreibvorgänge, die Antwortzeit und die CPU-Auslastung der
Webserver, Datenbankserver und Anwendungsserver während eines Exportvorgangs
gemessen, während dem auch Schreibaktivitäten stattfanden. Die folgenden Tabellen
enthalten die Ergebnisse.
Auswirkungen von Datenbankmomentaufnahmen während der
Inhaltsbereitstellung
Metrik
4 WPH - Keine Momentaufnahmen
4 WPH - Mit
Momentaufnahmen
RPS für Schreibvorgänge
0,2
0,16
Antwortzeit
0,13
0,15
Webserver-CPU (%)
0,42%
0,27%
Anwendungsserver-CPU (%)
8,67%
8,98%
318
Metrik
4 WPH - Keine Momentaufnahmen
4 WPH - Mit
Momentaufnahmen
Datenbankserver-CPU (%)
3,34%
2,41%
Auswirkungen von Datenbankmomentaufnahmen während der
Inhaltsbereitstellung
Metrik
8 WPH - Keine Momentaufnahmen
8 WPH - Mit
Momentaufnahmen
RPS für Schreibvorgänge
0,44
0,44
Antwortzeit
0,13
0,13
Webserver-CPU (%)
0,61%
0,73%
Anwendungsserver-CPU (%)
14,6%
12%
Datenbankserver-CPU (%)
7,04%
7,86%
Schlussfolgerungen und Empfehlungen im Hinblick auf
Datenbankmomentaufnahmen während des Exports bei der
Inhaltsbereitstellung
Die Ergebnisse der Tests zeigten keine signifikante Auswirkung auf die gemessenen
Datenpunkte mit Datenbankmomentaufnahmen. Die gesamte verzeichnete Abweichung
lag innerhalb der Fehlermarge. Damit wird bestätigt, dass Datenbankmomentaufnahmen
ohne große Bedenken hinsichtlich der Leistung verwendet werden können.
Eigenschaften von Inhalten
Die Tests wurden unter Verwendung eines einzelnen Datasets ausgeführt, das zur
Beantwortung einer bestimmten Reihe von Fragen erstellt wurde. Ihr Dataset weicht
davon ab und verändert sich im Laufe der Zeit. In diesem Abschnitt wird untersucht, wie
Eigenschaften von Inhalten, wie die Anzahl der Seiten in der Seitenbibliothek und die in
den Seiten enthaltenen Features, sich auf Entscheidungen zur Kapazitätsverwaltung
auswirken können.
Seitenanzahl
Die maximale RPS wurde für Seitenbibliotheken unterschiedlicher Größe getestet. Dieser
Test wurde in einer 4x1-Topologie bei deaktiviertem Ausgabecache und mit anonymem
Zugriff ausgeführt. Die Größe aller Seiten lag unkomprimiert bei 42 KB, komprimiert bei
12 KB. Die Testergebnisse sind in der folgenden Tabelle enthalten.
Auswirkungen der Anzahl der Bibliotheksseiten auf RPS
Seitenanzahl
3
1.000
20.000
Maximale RPS
860
801
790
319
Die Erhöhung der Seitenanzahl auf 20.000 hatte keine signifikanten Auswirkungen auf
die maximale RPS.
Mehrwertige Nachschlagefelder
Ein mehrwertiges Nachschlagefeld ist eine Spalte in einer Liste, die auf mindestens ein
Element in einer anderen Liste verweist, wie z. B. Spalten mit verwalteten
Unternehmensmetadaten. Diese Felder werden im Allgemeinen als Stichwörter der
Suche für eine Seite verwendet und werden nicht unbedingt gerendert. In manchen
Fällen, wie beispielsweise bei Unternehmenswikis, ist es sinnvoll, dass diese Feldwerte
im Seiteninhalt gerendert werden. So werden beispielsweise Seiten beim Erstellen
möglicherweise nach Kategorien unterteilt (z. B. Aus aller Welt, Wissen und Sport auf
einer Nachrichtenseite), und die Gestaltungsvorlage enthält einen Platzhalter, über den
dem Benutzer angezeigt wird, in welche Kategorien die Seite eingeteilt wird.
Bei mehrwertigen Nachschlagefeldern werden beim Anfordern einer Seite mehr Daten
abgerufen. Deshalb kann sich die Verwendung zahlreicher mehrwertiger
Nachschlagefelder auf einer Seite auf die Leistung auswirken.
Im folgenden Diagramm sind die Auswirkungen mehrwertiger Nachschlagefelder auf den
Durchsatz dargestellt.
320
Im folgenden Diagramm sind die Auswirkungen mehrwertiger Nachschlagefelder auf die
Verwendung von Farmressourcen dargestellt.
321
Bei zunehmender Anzahl der mehrwertigen Nachschlagefeldern kommt es zu einer
Beeinträchtigung der maximalen RPS, da sich der Anstieg auf das Netzwerk zwischen
Webserver und Datenbankserver auswirkt.
Auswirkungen der Verwendungsberichterstellung
Die Verwendungsberichterstellung ist ein Dienst, der Administratoren bei der
Überwachung von Statistiken über die Verwendung ihrer Websites hilft. Weitere
Informationen zur Verwendungsberichterstellung finden Sie unter Configure usage and
health data collection (SharePoint Server 2010).
Die Auswirkungen von Zeitgeberaufträgen für die Verwendungsberichterstellung auf die
maximale RPS wurde in einer 1x1-Farm getestet. In der folgenden Tabelle sind die
Ergebnisse beschrieben.
Auswirkungen der Verwendungsprotokollierung auf die Leistung (in
RPS)
322
Verwendungsdatenbank ein Verwendungsdatenbank Differenz
aus
Ausgabecache ein
3.459
3.463
4
Ausgabecache aus
629
638
9
Die Ergebnisse zeigen, dass die Aktivierung der Verwendungsprotokollierung in einem
schreibgeschützten Szenario keine signifikanten Auswirkungen auf RPS hat.
Informationen zu den Autoren
Joshua Stickler ist Program Manager für SharePoint Server 2010 bei Microsoft.
Joshua Stickler ist Program Manager für SharePoint Server 2010 bei Microsoft.
Zhi Liu ist Software Development Engineer in Test für SharePoint Server 2010 bei
Microsoft.
Cheuk Dong ist Software Development Engineer in Test für SharePoint Server 2010 bei
Microsoft.
Philippe Flamm ist Software Development Engineer in Test für SharePoint Server 2010
bei Microsoft.
323
Estimate performance and capacity
planning for workflow in SharePoint
Server 2010 (in englischer Sprache)
This performance and capacity planning article provides guidance on the effect that the
use of workflow has on topologies that run Microsoft SharePoint Server 2010.
For general information about capacity planning for SharePoint Server 2010, see
Leistungs- und Kapazitätsverwaltung (SharePoint Server 2010).
Contents

Test farm characteristics

Test results

Recommendations

Troubleshooting
Test farm characteristics
The following sections describe the characteristics of the test farm:
 Dataset

Workload

Hardware, settings, and topology
Dataset
To get benchmarks, most tests ran on a default Team Site on a single site collection in
the farm. The manual start tests started workflows by using a list that has 8,000 items.
Workload
Testing for this scenario helps develop estimates of how different farm configurations
respond to changes to the following variables:
 Effect of the number of front-end servers on throughput for manually starting
declarative workflows across multiple computers

Effect of the number of front-end servers on throughput for automatically starting
declarative workflows on item creation across multiple computers

Effect of the number of front-end servers on throughput for completing tasks across
multiple computers
The specific capacity and performance figures presented in this article will differ from the
figures in real-world environments. The figures presented are intended to provide a
starting point for the design of an appropriately scaled environment. After you complete
the initial system design, test the configuration to determine whether it will support the
factors in your environment.
324
This section defines the test scenarios and discusses the test process that was used for
each scenario. Detailed information such as test results and specific parameters are
given in each test result section later in this article.
Test name
Test description
Throughput for starting workflows manually 1. Associate the included MOSS Approval
workflow with a list that creates one
task.
2. Populate the list with list items.
3. Call the StartWorkflow Web service
method on Workflow.asmx against the
items in the list for five minutes.
4. Calculate throughput by looking at the
number of workflows in progress.
Throughput for starting workflows
automatically when an item is created
1. Associate the included MOSS Approval
workflow with a list that creates one
task, set to automatically start when an
item is created.
2. Create items in the list for five minutes.
3. Calculate throughput by looking at the
number of workflows in progress.
Throughput for completing workflow tasks
1. Associate the included MOSS Approval
workflow with a list that creates one
task, set to automatically start when an
item is created.
2. Create items in the list.
3. Call the AlterToDo Web service method
on Workflows.asmx against the items in
the task list that was created by the
workflows that started.
4. Calculate throughput by looking at the
number of workflows completed.
Hardware, settings, and topology
Topologies that were used for these tests use a single computer for the content database
and from one to four front-end computers that have the default installation for SharePoint
Server 2010. Although the workflows that were used in these tests are not available in
Microsoft SharePoint Foundation 2010, the results can be used to estimate similar
scenarios on those deployments. The dataset that was used for these tests contains a
325
single site collection with a single site that is based on the Team Site template on a single
content database.
To provide a high level of test-result detail, several farm configurations were used for
testing. Farm configurations ranged from one to four Web servers and a single computer
that is running Microsoft SQL Server 2008. Testing was performed with one client
computer. The database server and all Web servers were 64-bit, and the client computer
was 32-bit.
The following table lists the specific hardware that was used for testing.
Web server
Database server
Processor
[email protected]
[email protected]
RAM
4 GB
16 GB
Operating system
Windows Server 2008 R2 x64
Windows Server
2008 R2 x64
Storage
680 GB
4.2 terabyte
Number of network adapters
2
2
Network adapter speed
1 gigabit
1 gigabit
Authentication
NTLM
NTLM
Software version
4747
SQL Server 2008
R1
Number of SQL Server instances
1
1
Load balancer type
No load balancer
No load balancer
ULS logging level
Medium
Medium
Workflow Capacity Planning Topology
326
327
Test results
The following tables show the test results for workflow in SharePoint Server 2010. For
each group of tests, only certain specific variables are changed to show the progressive
effect on farm performance.
All the tests reported in this article were conducted without think time, a natural delay
between consecutive operations. In a real-world environment, each operation is followed
by a delay as the user performs the next step in the task. By contrast, in the test, each
operation was immediately followed by the next operation, which resulted in a continual
load on the farm. This load can cause database contention and other factors that can
adversely affect performance.
Effect of scaling the Web server on throughput
The following throughput tests were run by using the Approval workflow that is included
with SharePoint Server 2010. The workflow association assigns one task, and all
instances are run on a single list. Each instance of this workflow creates the following in
the content database:
 An entry in the Workflows table to store workflow status

Five secondary list items (one task and four history items)
 Four event receivers to handle events on the workflow's parent item and task
Workflow Postpone Threshold was set to be very large so that workflow operations would
never get queued. Each test was run five times, and each test ran for five minutes.
Manual start throughput
The test in the following table shows how the addition of front-end servers affects the
throughput of starting workflows synchronously through the Web service. This test was
run with a user load of 25 concurrent users continuously calling the StartWorkflow
method on Workflow.asmx and no other load on the farm. The user load was the optimal
load before dropped Web requests occurred. The list is prepopulated with up to 8,000
items.
Topology
Approval workflow maximum RPS
1x1
14.35
2x1
24.08
3x1
29.7
4x1
30.77
The following graph shows how throughput changes. The addition of front-end servers
does not necessarily affect farm throughput in a linear manner but instead peaks off at
around three to four front-end servers. In summary, the maximum throughput for
manually starting workflows is around 30 workflows per second, and adding more than
four front-end servers will likely have an insignificant effect.
Manual start throughput
328
Automatically starting workflows when items are created throughput
The test in the following table shows how the addition of front-end servers affects the
throughput of starting workflows automatically when items are created. This test was run
with a user load of 150 concurrent users continuously calling the list Web service to
create new list items in a single list and no other operations on the server. The list started
as an empty list.
Topology
Approval workflow maximum RPS
1x1
13.0
2x1
25.11
3x1
32.11
4x1
32.18
The following graph shows how throughput changes. The throughput is very close to the
manual start operations. Similar to the manual start test, throughput peaks at
approximately three or four front-end servers at approximately 32 workflows per second
maximum. Adding more than three or four front-end servers will have an insignificant
effect.
Autostart workflow throughput
329
Task completion throughput
The test in the following table shows how the addition of front-end servers affects the
throughput of completing workflow tasks. The task list that was used by autostart
workflows in the previous test was the list that was used to complete tasks. This test was
run with a user load of 25 concurrent users continuously calling the AlterToDo method on
Workflow.asmx and no other operations on the server. The list started as an empty list.
Topology
Approval workflow maximum RPS
1x1
13.5
2x1
23.86
3x1
27.06
4x1
27.14
330
The following graph shows how throughput changes. Similar to the manual start test,
throughput peaks at approximately three or four front-end servers at approximately 32
workflows per second maximum. Adding more than three front-end servers will have an
insignificant effect.
Task completion throughput
Effect of list size and number of workflow instances on throughput
The test in the following table shows how throughput changes as list size and number of
workflows increases. Data population was done by running the autostart workflow test
continuously until 1 million items were created in the list, and stopping at different
checkpoints throughout the test to perform throughput measurements as we did with the
core throughput tests. Tests were performed on a 4x1 topology.
To maintain reliability during data population, we had to keep workflow queuing turned on
to avoid reaching the maximum number of connections on the database server. If no
connections are available and a workflow operation cannot connect to the content
331
database, the operation will be unable to run. See Recommendations for more
information about workflow queuing.
Number of items or workflows
Baseline solution maximum (RPS)
0
32.18
10
32
1,000
28.67
10,000
27.16
100,000
16.98
1,000,000
9.27
Autostart throughput as number of items and workflows increases
332
For a single list and single task and history list, throughput decreases steadily between
1,000 and 100,000 items. However, the rate of degradation reduces after that point. We
attribute degradation of throughput to many factors.
One factor is the number of rows added to many tables in the content database per
instance. As mentioned earlier, workflows create several list items in addition to event
receivers that each workflow instance registers. As table sizes grow large in different
scopes, adding rows becomes slower, and the aggregate slowdown for these additions
becomes a more significant degradation than what is experienced with only list item
creation.
Task list size contributes additional overhead. In comparing throughput for workflows run
on new lists versus new task lists, task lists had a bigger effect on performance. This is
because task lists register for more event receivers than the parent list items. The
following chart describes the differences.
333
Throughput with different list
configurations (workflows started
per second)
Million item task list
Empty task list
Million item list
9.27
12
Empty item list
9.3
13
If you know that you will have to run lots of workflows against large lists and need more
throughput than what your tests show you can get, consider whether your task lists can
be separated between workflow associations.
Recommendations
This section provides general performance and capacity recommendations. Use these
recommendations to determine the capacity and performance characteristics of the
starting topology that you created to decide whether you have to scale out or scale up the
starting topology.
For specific information about minimum and recommended system requirements, see
Hardware and software requirements (SharePoint Server 2010).
Scaled-out topologies
You can increase workflow throughput by scaling out to up to four Web servers. Then,
additional increase will be insignificant. Workflow throughput can be restricted by
performance-related workflow settings. These settings are described in more detail in
Workflow queuing and performance-related settings.
Estimating throughput targets
Many factors can affect throughput. These factors include the number of users, and the
type, complexity, and frequency of user operations. More complex workflows that perform
many operations against the content database or register for more events will run slower
and consume more resources than other workflows.
The workflow used in this test creates several entries in the content database that are
built in to the task activities. If you expect to have workflows with small numbers of tasks,
you can expect similar throughput characteristics. If most workflows contain very
lightweight operations, throughput may be increased. If your workflows will consist of lots
of tasks or intense back-end operations or processing power, you can expect throughput
to decrease.
In addition to understanding what the workflows will do, consider where the workflows will
run and whether they will run against large lists, on which throughput will decrease over
time.
SharePoint Server 2010 can be deployed and configured in many ways. As a result,
there is no simple way to estimate how many users can be supported by a given number
of servers. Therefore, make sure that you conduct testing in your own environment
before you deploy SharePoint Server 2010 in a production environment.
Workflow queuing and performance-related settings
Workflow uses a queuing system to control workflow-related stress on farm resources
and the content database. By using this system, when the number of workflows executing
against a database reaches an administrator-configured threshold, successive workflow
334
operations are added to the queue to be run by the Workflow Timer service. By default,
this service receives a batch of workflow work items through timer jobs every minute.
Several farm administrator settings directly and indirectly related to the queuing
mechanism affect the performance and scaling for workflow. The following sections
describe what these settings do and how to adjust them to meet performance
requirements.
Understanding the basic queue settings
Farm administrators can adjust the following settings to configure basic characteristics of
the queuing system:
 Workflow Postpone Threshold (Set-SPFarmConfig –WorkflowPostponeThreshold
<integer>)
The maximum number of workflows that can execute against a single content
database before additional requests and operations are queued. Queued workflows
show a status of Starting. This is a farm-wide setting that has a default value of 15.
This represents the number of workflow operations that are being processed at a
time, not the maximum number of workflows that can be in progress. As workflow
operations are completed, successive operations will be able to run.
 Workflow Event Delivery Batch Size (Set-SPWorkflow –BatchSize <integer>)
The Workflow Timer service is an exception to the postpone threshold limit and will
retrieve batches of items from the queue and execute them one at a time. These
batches can be larger than the postpone threshold. The number of work items that
the service receives per run is set by using the BatchSize property. The BatchSize
property can be set one time per service instance. The default value is 100. When
running on application servers that are not configured to be front-end servers, the
Workflow Timer service requires workflow configuration settings in Web.config to be
set in the configuration database. This must be done through a script that calls
UpdateWorkflowConfigurationSettings() on the SPWebApplication object, which will
copy the Web.config settings from a front-end server.
 Workflow Timer Job Frequency (Set-SPTimerJob job-workflow –schedule <string>)
The frequency with which the Workflow Timer service runs can be adjusted through
timer job settings. By default, the service is set to run every five minutes. This means
that there can be a five-minute delay before the work items at the top of the queue
are processed.
Hinweis:
Scheduled work items such as task due date expirations are also picked up by the same
timer mechanism. Therefore, they will be delayed by the same time interval.
The Workflow Timer service can be turned off on each server by using Shared Services
Administration in Central Administration. By default, it will run on every front-end server in
the farm. Each job will iterate through all the Web applications and content databases in
the farm.
The combination of the postpone threshold, batch size, and timer frequency can be used
to limit workflow operations against the database. Maximum throughput will be affected
by how quickly operations get queued and processed from the queue.
For example, with the default settings, a single timer service, and a single content
database, if there are 1,000 items in the queue, it will take ten timer job runs to execute
them all, which will take 50 minutes to execute. However, if you set the batch size to
335
1,000 and set the timer job to run every minute, the operations would all begin execution
after a minute. If you set the postpone threshold higher, more operations will run
synchronously, reducing the number of requests that get queued and reducing the total
time that is required to process those workflows.
Hinweis:
We recommend setting the postpone threshold no larger than 200, because concurrent
workflow instances run in their own threads and will each open new SQL Server
connections, potentially hitting the maximum connection limits on the database server
over time.
If you do not want workflows running on front-end servers and know that operations do
not have to occur immediately, you can isolate the Workflow Timer service to run on
select application servers, set the postpone threshold to a very low number to force
workflows to usually run in the timer service, and set the batch size large so that it
receives items more quickly and frequently. If you want to make sure workflows run more
synchronously across the system, set the postpone threshold larger so that workflows are
not postponed often and have a more immediate effect.
Modify these settings to optimize for how you want workflows to operate. We recommend
experimenting with different settings and testing them to optimize them for your
environments and requirements.
Adjusting settings for queuing
If the farm will sustain heavy workflow load for long periods of time or there will be many
delay events queued from workflows in the system, the number of queued workflow
operations will grow. In addition to the basic queue settings, you may have to tune the
following settings to keep the queue in good health:
 Work Item Event Delivery Batchsize
The table that workflow uses for queued events is a general work item table that is
shared with other non-workflow features in SharePoint Server 2010. Thus, there is
another timer job that dequeues non-workflow work items. Similar to the workflow
event delivery batch size, the work item event delivery batch size specifies the
number of non-workflow work items that are dequeued at a time.
 Workflow Failover Timer Job Frequency
In rare circumstances, if workflow events cannot be delivered to a workflow instance,
the event delivery will be scheduled on the queue as a failover work item to be retried
later (starting with 5 minutes later, and then 10 minutes if it fails again, and then 20
minutes, and so on). A workflow failover timer job dequeues failover work items, and
this setting adjusts the frequency at which the failover timer will run. By default, this
runs every 15 minutes.
 Workflow Failover Batchsize
Similar to the workflow and work item batch size settings, this setting controls the
number of failover events that each failover timer job will dequeue.
Because there are many timer jobs that operate on the same table, lots of queued
items can cause database contention and reduce throughput and reliability. To
reduce contention, we recommend the following:
336

Balance Postpone Threshold and Workflow Batchsize so that batch size is small
enough or timer job frequency high enough that a timer job can be completed
before the next timer job starts in order to avoid building up too many parallel
timer job runs that cannot finish.

To avoid table locks, do not set either of the two batch size settings larger than
5,000.
Tipp:
Offset the frequency of the workflow, work item, and failover timer jobs so that they are
not always executing at the same times. To get a large list that has workflows, four
minutes for the workflow timer job and six minutes for the failover worked well in our data
population scripts.
Improving scaling for task and history lists
Workflows generate many tasks and history items per instance. By default, these lists are
indexed to help with scaling, but as these lists grow, performance will always decrease.
To reduce the rate of the decrease, keep separate history and task lists for different
workflow associations, and periodically change these lists in the workflow association
settings as lists become large.
Workflow also has a daily timer job (job-workflow-autoclean) that will automatically delete
workflow instances and tasks for instances that have been finished for more than 60
days. Leave this timer job on to keep the task lists and events on the task list as clean as
possible. If data must be preserved, write the data to other lists or archive locations.
Workflow history items are not deleted by this timer job. If you have to clean these up,
this should be done with a script or manually through the list user interface.
Other considerations
Removing columns on lists causes a database operation proportional to the number of
items in the list. Removing workflow associations will remove the workflow status column
from the list. This causes a large operation on large lists. If you know that a list has
millions of items, set the workflow to No New Instance instead of removing workflows.
Troubleshooting
Bottleneck
Cause
Database contention Database locks
(locks)
prevent multiple
users from making
conflicting
modifications to a
set of data. When a
set of data is locked
by a user or
process, no other
user or process can
Resolution
To help reduce the incidence of database
locks, you can do the following:
 Distribute workflows to more document
libraries.

Scale up the database server.

Tune the database server hard disk for
read/write.
Methods exist to circumvent the database
337
Bottleneck
Cause
Resolution
change that same
set of data until the
first user or process
is complete,
changing the data
and relinquishing
the lock.
locking system in SQL Server 2005, such as
the NOLOCK parameter. However, we do not
recommend or support use of this method
because of the possibility of data corruption.
Database server
disk I/O
When the number of Distributing data files across multiple physical
I/O requests to a
drives allows for parallel I/O. The blog
hard disk exceeds SharePoint Disk Allocation and Disk I/O
the disk's I/O
(http://go.microsoft.com/fwlink/?LinkId=129557)
capacity, the
contains useful information about resolving
requests will be
disk I/O issues.
queued. As a result,
the time to complete
each request
increases.
Web server CPU
utilization
When a Web server This issue can be resolved in one of two ways.
is overloaded with You can add Web servers to the farm to
user requests,
distribute user load, or you can scale up the
average CPU
Web server or servers by adding faster
utilization will
processors.
approach 100
percent. This
prevents the Web
server from
responding to
requests quickly and
can cause timeouts
and error messages
on client computers.
Web servers
The following table shows performance counters and processes to monitor for Web
servers in a farm.
Performance counter
Apply to object
Notes
Processor time
Total
Shows the
percentage of
elapsed time that
this thread used
the processor to
execute
instructions.
338
Performance counter
Apply to object
Notes
Memory utilization
Application pool
Shows the
average
utilization of
system memory
for the
application pool.
You must
determine the
correct
application pool
to monitor.
The basic
guideline is to
determine peak
memory
utilization for a
given Web
application, and
assign that
number plus 10
to the associated
application pool.
Database servers
The following table shows performance counters and processes to monitor for database
servers in your farm.
Performance counter
Apply to object
Notes
Average disk queue length
Hard disk that contains
SharedServices.mdf
Average values
larger than 1.5
per spindle
indicate that the
write times for
that hard disk are
insufficient.
Processor time
SQL Server process
Average values
larger than 80
percent indicate
that processor
capacity on the
database server
is insufficient.
Processor time
Total
Shows the
percentage of
339
Performance counter
Apply to object
Notes
elapsed time that
this thread used
the processor to
execute
instructions.
Memory utilization
Total
Shows the
average
utilization of
system memory.
Siehe auch
Weitere Ressourcen
Workflow Scalability and Performance in Windows SharePoint Services 3.0
(http://go.microsoft.com/fwlink/?LinkId=207353)
340
Speicher- und SQL ServerKapazitätsplanung und -Konfiguration
(SharePoint Server 2010)
Dieser Artikel beschreibt, wie Sie die Speicher- und Microsoft SQL ServerDatenbankschicht in einer Microsoft SharePoint Server 2010-Umgebung planen und
konfigurieren.
Die in diesem Dokument enthaltenen Informationen zur Kapazitätsplanung bieten Ihnen
Hilfestellung bei Ihrem Planungsprozess. Sie stützen sich auf Tests, die bei Microsoft mit
realen Ressourcen durchgeführt wurden. Ihre Ergebnisse können jedoch in Abhängigkeit
von den verwendeten Anlagen und den Features und Funktionen variieren, die Sie für
Ihre Websites implementieren möchten.
Da SharePoint Server häufig in Umgebungen ausgeführt wird, in denen Datenbanken
von eigenständigen SQL Server-Datenbankadministratoren verwaltet werden, ist dieses
Dokument für die gemeinschaftliche Nutzung durch SharePoint ServerFarmimplementierer und SQL Server-Datenbankadministratoren gedacht. Wesentliche
Kenntnisse im Hinblick auf SharePoint Server und SQL Server werden vorausgesetzt.
In diesem Artikel wird vorausgesetzt, dass Sie mit den unter Capacity management and
sizing for SharePoint Server 2010 (in englischer Sprache) beschriebenen Konzepten
vertraut sind.
Entwurfs- und Konfigurationsprozess für die
Speicher- und Datenbankschicht der
SharePoint 2010-Produkte
Es wird empfohlen, den Entwurfsprozess für die Speicher- und Datenbankschicht in die
folgenden Schritte zu unterteilen. In jedem Abschnitt finden Sie ausführliche
Informationen zu jeweiligen Schritt, einschließlich Speicheranforderungen und bewährten
Methoden:
 Erfassen der Speicher- und SQL Server-Kapazität und der E/A-Anforderungen

Auswählen der SQL Server-Version und -Edition

Entwerfen der Speicherarchitektur auf der Basis von Kapazität und E/AAnforderungen

Prognostizieren der Arbeitsspeicheranforderungen

Grundlegendes zu den Anforderungen an die Netzwerktopologie

Konfigurieren von SQL Server

Überprüfen von Speicherleistung und -zuverlässigkeit
341
Erfassen der Speicher- und SQL ServerKapazität und der E/A-Anforderungen
Der Speicherentwurf wird durch verschiedene Faktoren der jeweiligen SharePoint Server
2010-Architektur beeinflusst. Wesentliche Größen sind hierbei der Umfang der
verwendeten Inhalte, Features und Dienstanwendungen, die Anzahl der Farmen und die
Anforderungen an die Verfügbarkeit.
Bevor Sie mit der Planung des Speichers beginnen, sollten Sie sich vergegenwärtigen,
welche Datenbanken von SharePoint Server 2010 verwendet werden können.
Inhalt dieses Abschnitts:
 Datenbanken, die von SharePoint 2010-Produkten verwendet werden

Grundlegendes zu SQL Server und IOPS

Prognostizieren der zentralen Speicher- und IOPS-Anforderungen

Bestimmen der Speicher- und IOPS-Anforderungen für Dienstanwendungen

Bestimmen der Anforderungen an die Verfügbarkeit
Datenbanken, die von SharePoint 2010-Produkten verwendet werden
Welche Datenbanken mit SharePoint Server 2010 installiert werden, hängt von den
Features ab, die in der Umgebung verwendet werden. Alle SharePoint 2010-ProdukteUmgebungen stützen sich auf die Systemdatenbanken von SQL Server. Dieser Abschnitt
enthält einen Überblick über die mit SharePoint Server 2010 installierten Datenbanken.
Ausführliche Informationen finden Sie unter Database types and descriptions (SharePoint
Server 2010) und Datenbankmodell
(http://go.microsoft.com/fwlink/?linkid=187968&clcid=0x407).
Produktversion und -Edition
Datenbanken
SharePoint Foundation 2010
Konfiguration
Inhalt der Zentraladministration
Inhalt (eine oder mehrere)
Verwendung und Integritätsdatensammlung
Business Data Connectivity
Anwendungsregistrierungsdienst (bei einem
Upgrade vom Microsoft Office SharePoint
Server 2007-Geschäftsdatenkatalog)
Abonnementeinstellungendienst (falls über
Windows PowerShell aktiviert)
Zusätzliche Datenbanken für SharePoint
Server 2010 Standard Edition
Suchdienstanwendung:
 Suchverwaltung

Durchforstung (eine oder mehrere)
 Eigenschaften (eine oder mehrere)
Benutzerprofil-Dienstanwendung
 Profil
342
Produktversion und -Edition
Datenbanken

Synchronisierung
 Thematische Kategorien
Web Analytics-Dienstanwendung
 Staging
 Bericht
Einmaliges Anmelden
Status
Verwaltete Metadaten
Word Automation Services
Zusätzliche Datenbanken für SharePoint
Server 2010 Enterprise Edition
PerformancePoint
Zusätzliche Datenbanken für Project Server Entwurf
2010
Veröffentlicht
Archiv
Bericht
Zusätzliche Datenbank für FAST Search
Server
Suchverwaltung
Bei einer umfassenderen Anbindung an SQL Server kann Ihre Umgebung auch
zusätzliche Datenbanken einschließen, wie in den folgenden Szenarien:
 Microsoft SQL Server 2008 R2 PowerPivot für Microsoft SharePoint 2010 kann in
einer SharePoint Server 2010-Umgebung verwendet werden, die SQL Server 2008
R2 Enterprise Edition und SQL Server Analysis Services einschließt. In diesem Fall
müssen Sie auch die Unterstützung für die PowerPivot-Anwendungsdatenbank sowie
die zusätzliche Last im System einplanen. Weitere Informationen finden Sie unter
Planen einer PowerPivot-Bereitstellung in einer SharePoint-Farm
(http://go.microsoft.com/fwlink/?linkid=186698&clcid=0x407).

Das Plug-In Microsoft SQL Server 2008 Reporting Services (SSRS) kann mit jeder
SharePoint 2010-Produkte-Umgebung verwendet werden. Wenn Sie das Plug-In
verwenden, sollten Sie auch die Unterstützung der beiden SQL Server 2008
Reporting Services-Datenbanken und die zusätzliche Last, die für SQL Server 2008
Reporting Services erforderlich ist, einplanen.
Grundlegendes zu SQL Server und IOPS
Bei jedem Server, der als Host für SQL Server fungiert, ist es sehr wichtig, dass der
Server die schnellstmögliche Antwortzeit für das E/A-Subsystem erzielt.
Durch eine größere Anzahl und schnellere Datenträger oder Arrays erzielen Sie
genügend E/A-Operationen pro Sekunde (I/O Operations Per Second, IOPS), während
Wartezeit und Warteschlangenzeit für alle Datenträger niedrig bleiben.
Ein langsames Antwortverhalten des E/A-Subsystems kann nicht durch das Hinzufügen
anderer Ressourcenarten wie CPU oder Arbeitsspeicher kompensiert werden. Es kann
jedoch Auswirkungen auf die gesamte Farm haben und Probleme verursachen. Sorgen
343
Sie daher vor der Bereitstellung für minimale Wartezeiten, und überwachen Sie die
vorhandenen Systeme.
Bevor Sie eine neue Farm bereitstellen, empfiehlt es sich, für das E/A-Subsystem
Vergleichstests mithilfe des Datenträgersubsystem-Benchmarktools SQLIO
durchzuführen. Ausführliche Informationen finden Sie unter SQLIO:
Datenträgersubsystem-Benchmarktool
(http://go.microsoft.com/fwlink/?linkid=105586&clcid=0x407).
Ausführliche Informationen zum Analysieren der IOPS-Anforderungen aus SQL ServerSicht finden Sie unter Analysieren der E/A-Besonderheiten und Bestimmen der Größe
von Speichersystemen für SQL Server-Datenbankanwendungen
(http://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristicsand-sizing-storage-systems-for-sql-server-database-applications.aspx).
Prognostizieren der zentralen Speicher- und IOPS-Anforderungen
Konfigurations- und Inhaltsspeicher sowie IOPS sind die Basisgrößen, die Sie bei jeder
Bereitstellung von SharePoint Server 2010 planen müssen.
Konfigurationsspeicher und IOPS
Die Speicheranforderungen für die Konfigurationsdatenbank und die Inhaltsdatenbank
der Zentraladministration sind nicht hoch. Es empfiehlt sich, 2 GB für die
Konfigurationsdatenbank und 1 GB für die Inhaltsdatenbank der Zentraladministration
zuzuordnen Im Laufe der Zeit ist es möglich, dass die Konfigurationsdatenbank auf mehr
als 1 GB anwächst, aber ihre Größe nimmt nicht schnell zu. Pro 50.000
Websitesammlungen wird die Datenbank um ungefähr 40_MB größer.
Transaktionsprotokolle für die Konfigurationsdatenbank können sehr groß sein. Es wird
daher empfohlen, für die Datenbank vom vollständigen zum einfachen
Wiederherstellungsmodell zu wechseln.
Hinweis:
Wenn Sie die Datenbankspiegelung von SQL Server verwenden, um die Verfügbarkeit
der Konfigurationsdatenbank sicherzustellen, müssen Sie das vollständige
Wiederherstellungsmodell verwenden.
Die IOPS-Anforderungen für die Konfigurationsdatenbank und die Inhaltsdatenbank der
Zentraladministration sind minimal.
Inhaltsspeicher und IOPS
Das Prognostizieren des Speichers und der IOPS, die für die Inhaltsdatenbanken
erforderlich sind, ist kein exakter Vorgang. Die von uns durchgeführten Tests und die
Bereitstellung der folgenden Informationen sollen Ihnen helfen, Schätzwerte abzuleiten,
die Sie zum Festlegen der Anfangsgröße Ihrer Bereitstellung verwenden können. Sobald
Ihre Umgebung in Betrieb genommen wurde, sollten Sie Ihre Kapazitätsanforderungen
jedoch anhand der Daten aus der Live-Umgebung überprüfen.
Weitere Informationen zur zugrunde liegenden Kapazitätsplanungsmethodik finden Sie
unter Capacity management and sizing for SharePoint Server 2010 (in englischer
Sprache).
Prognostizieren des Speichers für Inhaltsdatenbanken
344
Das folgende Verfahren beschreibt, wie Sie den ungefähren Speicherbedarf für Ihre
Inhaltsdatenbanken ohne Berücksichtigung der zugehörigen Protokolldateien
prognostizieren:
1. Berechnen Sie die zu erwartende Anzahl an Dokumenten. Dieser Wert wird in der
Formel mit D bezeichnet.
Wie Sie die Anzahl der Dokumente berechnen, hängt von den Features ab, die Sie
verwenden. Für Websites des Typs Meine Website oder Websites für die
Zusammenarbeit empfiehlt es sich, die zu erwartende Anzahl an Dokumenten auf
Benutzerbasis zu berechnen und mit der Anzahl der Benutzer zu multiplizieren. Bei
Websites für die Datensatzverwaltung oder die Inhaltsveröffentlichung können Sie
die Anzahl der Dokumente berechnen, die durch einen Prozess verwaltet und
generiert werden.
Falls Sie eine Migration von einem bestehenden System durchführen, ist es unter
Umständen einfacher, die aktuelle Zuwachsrate und die Nutzung zu extrapolieren.
Wenn Sie ein neues System erstellen, sollten Sie die vorhandenen Dateifreigaben
oder andere Repositorys überprüfen und die zu erwartende Anzahl an Dokumenten
auf der Grundlage dieser Nutzungsrate prognostizieren.
2. Prognostizieren Sie die durchschnittliche Größe der Dokumente, die Sie speichern
werden. Dieser Wert wird in der Formel mit G bezeichnet. Es kann sich lohnen,
Durchschnittswerte für verschiedene Arten oder Gruppen von Websites zu
prognostizieren. Die durchschnittliche Dateigröße für Websites des Typs Meine
Website, Medienrepositorys und verschiedene Abteilungsportale kann erheblich
variieren.
3. Prognostizieren Sie die Anzahl der Listenelemente in der Umgebung. Dieser Wert
wird in der Formel mit L bezeichnet.
Das Prognostizieren von Listenelementen ist schwieriger als das Prognostizieren von
Dokumenten. Wir verwenden im Allgemeinen einen Schätzwert, der dem Dreifachen
der Dokumentenanzahl (D) entspricht, aber dieser Wert variiert in Abhängigkeit
davon, wie Sie Ihre Websites voraussichtlich verwenden werden.
4. Bestimmen Sie die ungefähre Anzahl der Versionen. Prognostizieren Sie die
durchschnittliche Anzahl der Versionen, die ein beliebiges Dokument in einer
Bibliothek aufweisen wird (dieser Wert ist normalerweise deutlich kleiner als die
maximal zulässige Anzahl an Versionen). Dieser Wert wird in der Formel mit V
bezeichnet.
Der Wert von V muss größer als null sein.
5. Verwenden Sie die folgende Formel, um die Größe Ihrer Inhaltsdatenbanken zu
prognostizieren:
Datenbankgröße = ((D × V) × G) + (10 KB × (L + (V × D)))
Der Wert 10 KB in der Formel ist eine Konstante, die den Umfang der für SharePoint
Server 2010 erforderlichen Metadaten grob abschätzt. Wenn ein System die Nutzung
von Metadaten in erheblichem Umfang erforderlich macht, kann es sich empfehlen,
den Wert dieser Konstante zu erhöhen.
Beispiel: Wenn Sie die Formel zum Prognostizieren des Speicherplatzes verwenden
möchten, der für die Datendateien einer Inhaltsdatenbank in einer Umgebung zur
Zusammenarbeit mit den folgenden Merkmalen erforderlich ist, würden Sie ungefähr 105
GB benötigen.
345
Eingabe
Wert
Anzahl der Dokumente (D)
200.000
Berechnet auf der Grundlage von 10.000
Benutzern mit je 20 Dokumenten
Durchschnittliche Dokumentgröße (G)
250 KB
Listenelemente (L)
600.000
Anzahl nicht aktueller Versionen (V)
2
Unter der Annahme, dass maximal 10
Versionen zugelassen sind
Datenbankgröße = (((200.000 x 2)) × 250) + ((10 KB × (600.000 + (200.000 x 2))) =
110.000.000 KB oder 105 GB
Features, die die Größe von Inhaltsdatenbanken beeinflussen
Die Verwendung der folgenden SharePoint Server 2010-Features kann sich erheblich auf
die Größe von Inhaltsdatenbanken auswirken:
 Papierkörbe Solange ein Dokument nicht vollständig aus dem Standardpapierkorb
und dem endgültigen Papierkorb gelöscht wurde, belegt es Speicherplatz in einer
Inhaltsdatenbank. Berechnen Sie, wie viele Dokumente pro Monat gelöscht werden,
um den Einfluss von Papierkörben auf die Größe von Inhaltsdatenbanken zu
bestimmen. Weitere Informationen finden Sie unter Configure Recycle Bin settings
(SharePoint Server 2010).


Überwachung Überwachungsdaten können sich sehr schnell anhäufen und große
Mengen an Speicherplatz in einer Inhaltsdatenbank beanspruchen, insbesondere
dann, wenn die Anzeige von Überwachungsdaten aktiviert ist. Anstatt das
uneingeschränkte Anwachsen von Überwachungsdaten zuzulassen, empfiehlt es
sich, nur die Überwachung von Ereignissen zu aktivieren, die für die Einhaltung von
Vorschriften oder interne Kontrollen notwendig sind. Verwenden Sie die folgenden
Richtlinien, um den Speicherplatz zu prognostizieren, der für Überwachungsdaten
reserviert werden sollte:

Prognostizieren Sie die Anzahl der neuen Überwachungseinträge für eine
Website, und multiplizieren Sie diesen Wert mit 2 KB (Einträge sind
normalerweise auf 4 KB beschränkt, wobei die durchschnittliche Größe ungefähr
1 KB beträgt).

Bestimmen Sie, basierend auf dem Speicherplatz den Sie zuordnen möchten,
wie lange (in Tagen) Überwachungsprotokolle aufbewahrt werden sollen.
Office Web Apps
Wenn Office Web Apps verwendet wird, kann
der Office Web Apps-Cache erheblichen Einfluss auf die Größe von
Inhaltsdatenbanken haben. Standardmäßig wird der Office Web Apps-Cache auf
100 GB festgelegt. Weitere Informationen zur Größe des Office Web Apps-Caches
finden Sie unter Manage the Office Web Apps cache.
Prognostizieren der IOPS-Anforderungen für Inhaltsdatenbanken
346
Die IOPS-Anforderungen für Inhaltsdatenbanken variieren beträchtlich in Abhängigkeit
von der Verwendung der Umgebung, dem Umfang des verfügbaren Speicherplatzes und
der Anzahl der verfügbaren Server. Im Allgemeinen empfiehlt es sich, die prognostizierte
Arbeitsauslastung in der Umgebung mit einer der von uns getesteten Lösungen zu
vergleichen. Weitere Informationen finden Sie unter Ergebnisse der Leistungs- und
Kapazitätstests und Empfehlungen (SharePoint Server 2010).
Wichtig:
Die Tests für den Inhalt dieses Abschnitts sind noch nicht beendet. Kehren Sie zu einem
späteren Zeitpunkt zurück, um weitere Informationen zu erhalten.
Bestimmen der Speicher- und IOPS-Anforderungen für
Dienstanwendungen
Nachdem Sie die Anforderungen im Hinblick auf Inhaltsspeicher und IOPS prognostiziert
haben, müssen Sie den Speicher und die IOPS bestimmen, die für die in der Umgebung
verwendeten Dienstanwendungen erforderlich sind.
Speicher- und IOPS-Anforderungen von SharePoint Foundation
2010-Dienstanwendungen
Zum Prognostizieren der Speicheranforderungen für die Dienstanwendungen im System
müssen Sie zuerst wissen, welche Dienstanwendungen notwendig sind und wie Sie
diese Anwendungen verwenden werden. In der folgenden Tabelle sind die
Dienstanwendungen aufgeführt, die in SharePoint Foundation 2010 verfügbar sind und
die über Datenbanken verfügen.
Dienstanwendungsdatenbank
Empfehlungen für die Größenprognose
Verwendung und Integritätsdatensammlung Die Verwendungsdatenbank kann sehr
schnell anwachsen und erhebliche
Anforderungen an die IOPS stellen.
In Umgebungen für die Zusammenarbeit, in
denen Standardeinstellungen verwendet
werden, beanspruchen 1 Million HTTPAnforderungen beispielsweise 2 GB an
Speicher.
Verwenden Sie eine der folgenden Formeln,
um den Umfang der erforderlichen IOPS zu
prognostizieren:
 115 × Seitenzugriffe/Sekunde
 5 × HTTP-Anforderungen
Wenn Sie die Größe der
Verwendungsdatenbank beschränken
müssen, empfiehlt es sich, mit der reinen
Protokollierung der Seitenanforderungen zu
beginnen. Sie können die Größe der
347
Dienstanwendungsdatenbank
Empfehlungen für die Größenprognose
Datenbank auch beschränken, indem Sie
das Standardintervall für die Aufbewahrung
der Daten auf einen Zeitraum von weniger
als zwei Wochen festlegen.
Platzieren Sie die Verwendungsdatenbank,
sofern möglich, auf einem eigenen
Datenträger oder einem eigenen
physikalischen Laufwerk.
Business Data Connectivity-Dienst
Die Größe der Business Data ConnectivityDienstdatenbank wird in erster Linie durch
die Anzahl der externen Inhaltstypen
bestimmt, die Sie unterstützen möchten.
Ordnen Sie für jeden externen Inhaltstyp
0,5 MB zu. Wenn Sie nicht wissen, wie viele
Inhaltstypen benötigt werden, empfiehlt sich
die Zuordnung von 50 MB. Die IOPSAnforderungen sind minimal.
Anwendungsregistrierungsdienst
Ordnen Sie 1 GB nur zu, wenn Sie ein
Upgrade vom Microsoft Office SharePoint
Server 2007-Geschäftsdatenkatalog
durchführen. Die IOPS-Anforderungen sind
minimal.
Abonnementeinstellungen
Ordnen Sie 1 GB zu. Die IOPSAnforderungen sind minimal.
Speicher- und IOPS-Anforderungen von SharePoint Server 2010Dienstanwendungen
Zum Prognostizieren der Speicheranforderungen für die Dienstanwendungen im System
müssen Sie zuerst wissen, welche Dienstanwendungen notwendig sind und wie Sie
diese Anwendungen verwenden werden. In der folgenden Tabelle sind die
Dienstanwendungen aufgeführt, die in SharePoint Server 2010 verfügbar sind und die
über Datenbanken verfügen.
Dienstanwendung
Empfehlungen für die Größenprognose
Suche
Für die Suche sind drei Datenbanken
erforderlich. Ihre Umgebung kann mehrere
Eigenschaften- und
Durchforstungsdatenbanken enthalten.
Die Suchverwaltungsdatenbank ist
normalerweise klein. Ordnen Sie 10 GB zu.
Verwenden Sie die folgenden
Multiplikatoren, um den erforderlichen
348
Dienstanwendung
Empfehlungen für die Größenprognose
Speicher für die Eigenschaften- und
Durchforstungsdatenbanken zu
prognostizieren:
 Durchforstung: 0,046 × (Summe der
Inhaltsdatenbanken)

Eigenschaft: 0,015 × (Summe der
Inhaltsdatenbanken)
Die IOPS-Anforderungen für die Suche sind
beträchtlich.

Für die Durchforstungsdatenbank
benötigt die Suche 3.500 bis 7.000
IOPS.

Für die Eigenschaftendatenbank
benötigt die Suche 2.000 IOPS.
Ausführliche Informationen zum
Prognostizieren der für die Suche
erforderlichen Kapazität finden Sie unter
Ergebnisse der Leistungs- und
Kapazitätstests und Empfehlungen
(SharePoint Server 2010).
Benutzerprofil
Die Benutzerprofildienst-Anwendung ist mit
drei Datenbanken verknüpft: Profil,
Synchronisierung und Thematische
Kategorien.
Verwenden Sie die folgenden
Informationen, um den erforderlichen
Speicher für die Datenbanken zu
prognostizieren:
 Profil: Wenn Sie die
Standardeinstellungen verwenden, ist in
einer Umgebung, deren Konfiguration
die Verwendung von Active Directory
vorsieht, in der Profildatenbank
ungefähr 1 MB pro Benutzerprofil
erforderlich.

Synchronisierung. Wenn Sie die
Standardeinstellungen verwenden, sind
in einer Umgebung mit wenigen
Gruppen pro Benutzer in der
Synchronisierungsdatenbank ungefähr
630 KB pro Benutzerprofil erforderlich.
90 % des Speichers werden von der
Datendatei verwendet.

Thematische Kategorien. Wenn Sie die
349
Dienstanwendung
Empfehlungen für die Größenprognose
Standardeinstellungen verwenden sind
in der Datenbank für thematische
Kategorien ungefähr 0,009 MB pro
Kategorie, Kommentar oder Bewertung
erforderlich. Zum Prognostizieren der
Anzahl an Kategorien und Notizen, die
von den Benutzern erstellt werden,
sollten Sie die folgenden Informationen
zur Website del.icio.us
berücksichtigen:

Ungefähr 10 % der Benutzer
werden als aktive Benutzer
erachtet.

Aktive Benutzer erstellen 4,5
Kategorien und 1,8 Kommentare
pro Monat.
In einer Umgebung für die Zusammenarbeit
mit 160.000 Benutzerprofilen, 5 Gruppen,
79.000 Kategorien, Kommentaren und
Bewertungen (2.500 Kommentare, 76.000
Kategorien und 800 Bewertungen) und bei
Verwendung der Standardeinstellungen
wurden für diese Datenbanken die
folgenden Größen festgestellt:
Verwaltete Metadaten
Datenbankname
Datenbankgröße
Profil
155 GB
Synchronisierung
96 GB
Thematische
Kategorien
0,66 GB
Die Dienstanwendung für verwaltete
Metadaten verfügt über eine Datenbank. Die
Größe der Datenbank wird von der Anzahl
der im System verwendeten Inhaltstypen
und Schlüsselwörter beeinflusst. Viele
Umgebungen umfassen mehrere Instanzen
der Dienstanwendung für verwaltete
Metadaten. Ausführliche Informationen zum
Prognostizieren der Größen- und IOPSAnforderungen für diese Datenbank finden
Sie unter Ergebnisse der Leistungs- und
350
Dienstanwendung
Empfehlungen für die Größenprognose
Kapazitätstests und Empfehlungen
(SharePoint Server 2010).
Web Analytics
Web Analytics verfügt über zwei
Datenbanken: die Staging- und die
Berichtsdatenbank. Die Größe der
Datenbanken wird von vielen Faktoren
beeinflusst. Hierzu zählen der
Aufbewahrungszeitraum, das tägliche
Volumen der verfolgten Daten sowie die
Anzahl der Websitesammlungen, Websites
und Unterwebsites in der analysierten
Webanwendung. Ausführliche Informationen
zum Prognostizieren der Größen- und IOPSAnforderungen finden Sie unter Ergebnisse
der Leistungs- und Kapazitätstests und
Empfehlungen (SharePoint Server 2010).
Einmaliges Anmelden
Die Größe der Datenbank der Secure Store
Service-Anwendung wird durch die Anzahl
der Anmeldeinformationen im Speicher und
die Anzahl der Einträge in der
Überwachungstabelle bestimmt. Es
empfiehlt sich, pro 1.000
Anmeldeinforationen 5 MB zuzuordnen. Die
IOPS-Anforderungen sind minimal.
Status
Die Statusdienstanwendung verfügt über
eine Datenbank. Es empfiehlt sich, 1 GB für
diese Datenbank zuzuordnen. Die IOPSAnforderungen sind minimal.
Word Automation Services
Die Word Automation Services-Anwendung
verfügt über eine Datenbank. Es empfiehlt
sich, 1 GB für diese Datenbank zuzuordnen.
Die IOPS-Anforderungen sind minimal.
PerformancePoint
Die PerformancePoint-Dienstanwendung
verfügt über eine Datenbank. Es empfiehlt
sich, 1 GB für diese Datenbank zuzuordnen.
Die IOPS-Anforderungen sind minimal.
Bestimmen der Anforderungen an die Verfügbarkeit
Verfügbarkeit bezeichnet das Ausmaß, mit dem eine SharePoint Server 2010-Umgebung
vom Benutzer als verfügbar wahrgenommen wird. Ein verfügbares System ist ein
System, das stabil ist, d. h., Vorfälle, die den Betrieb beeinflussen, treten selten auf, und
bei ihrem Auftreten werden zeitnah wirksame Maßnahmen ergriffen.
351
Durch Anforderungen hinsichtlich der Verfügbarkeit kann der Speicherbedarf erheblich
steigen. Ausführliche Informationen finden Sie unter Plan for availability (SharePoint
Server 2010).
Auswählen der SQL Server-Version und Edition
Obwohl SharePoint 2010-Produkte mit Microsoft SQL Server 2008 R2, SQL Server 2008
oder SQL Server 2005 ausgeführt werden kann, wird nachdrücklich empfohlen, die
Ausführung der Umgebung mit der Enterprise Edition von SQL Server 2008 oder SQL
Server 2008 R2 zu erwägen, um die zusätzliche Leistung, Verfügbarkeit, Sicherheit und
Verwaltungsfunktionalität nutzen zu können, die diese Edition bereitstellt. Weitere
Informationen zur Verwendung von SQL Server 2008 R2 Enterprise Edition finden Sie
unter SQL Server 2008 R2 and SharePoint Products 2010: Better Together (White paper)
(SharePoint Server 2010).
Sie sollten insbesondere die Notwendigkeit der folgenden Features berücksichtigen:
 Sicherungskomprimierung Durch die Sicherungskomprimierung kann jede
SharePoint-Sicherung beschleunigt werden. Dieses Feature ist in SQL Server 2008
Enterprise Edition und SQL Server 2008 R2 Standard Edition verfügbar. Indem Sie
die Komprimierungsoption im Sicherungsskript festlegen oder den Server mit SQL
Server so konfigurieren, dass die Komprimierung standardmäßig verwendet wird,
können Sie die Größe der Datenbanksicherungen und der versendeten Protokolle
erheblich reduzieren. Weitere Informationen finden Sie unter
Sicherungskomprimierung (SQL Server)
(http://go.microsoft.com/fwlink/?linkid=129381&clcid=0x407).
Hinweis:
Die SQL Server-Datenkomprimierung wird für SharePoint 2010-Produkte nicht
unterstützt.

Transparente Datenverschlüsselung Wenn Ihre Sicherheitsanforderungen die
Verwendung der transparenten Datenverschlüsselung notwendig machen, müssen
Sie SQL Server Enterprise Edition verwenden.

Web Analytics-Dienstanwendung Wenn Sie beabsichtigen, die Web AnalyticsDienstanwendung für umfangreiche Analysen zu verwenden, sollten Sie die
Verwendung von SQL Server Enterprise Edition erwägen, damit das System die
Vorteile der Tabellenpartitionierung nutzen kann.

Inhaltsbereitstellung Wenn Sie beabsichtigen, das Feature für die
Inhaltsbereitstellung zu verwenden, sollten Sie die Verwendung von SQL Server
Enterprise Edition in Erwägung ziehen, damit das System die Vorteile von SQL
Server-Datenbankmomentaufnahmen nutzen kann.

Remote-BLOB-Speicher Wenn Sie den Remote-BLOB-Speicher für eine
Datenbank oder einen Speicherort jenseits der Dateien nutzen möchten, die mit den
einzelnen Inhaltsdatenbanken verknüpft sind, müssen Sie SQL Server 2008 oder
SQL Server 2008 R2 Enterprise Edition verwenden.

Ressourcenkontrolle Die Ressourcenkontrolle ist eine in SQL Server 2008
eingeführte Technologie, die Ihnen die Verwaltung von SQL Server352
Arbeitsauslastungen und -Ressourcen durch Angabe der Grenzwerte für den
Ressourcenverbrauch durch eingehende Anforderungen ermöglicht. Die
Ressourcenkontrolle ermöglicht es Ihnen, Arbeitsauslastungen zu unterscheiden und
CPU und Arbeitsspeicher bei Anforderung auf der Basis der von Ihnen angegebenen
Grenzwerte zuzuordnen. Dieses Feature ist nur in SQL Server 2008 oder SQL
Server 2008 R2 Enterprise Edition verfügbar. Weitere Informationen zur Verwendung
der Ressourcenkontrolle finden Sie unter Verwalten von SQL ServerArbeitsauslastungen mit der Ressourcenkontrolle.
Die Verwendung der Ressourcenkontrolle mit SharePoint Server 2010 empfiehlt sich
aus folgenden Gründen:
 Begrenzen des Umfangs der SQL Server-Ressourcen, die die von der
Suchdurchforstungskomponente angesprochenen Webserver beanspruchen. Es
hat sich bewährt, die Durchforstungskomponente auf 10 % der CPU zu
begrenzen, wenn das System ausgelastet ist.


Überwachen der Anzahl der Ressourcen, die von den einzelnen Datenbanken im
System beansprucht werden. Die Ressourcenkontrolle kann Ihnen
beispielsweise dabei helfen, die beste Platzierung von Datenbanken auf den
verschiedenen Computern mit SQL Server zu bestimmen.
PowerPivot für SharePoint 2010
Ermöglicht Benutzern die gemeinsame
Nutzung und Zusammenarbeit an benutzergenerierten Datenmodellen und Analysen
in Excel und im Browser, während diese Analysen automatisch aktualisiert werden.
Dieses Feature gehört zu SQL Server 2008 R2 Enterprise Edition Analysis Services.
Entwerfen der Speicherarchitektur auf der
Basis von Kapazität und E/A-Anforderungen
Die Speicherarchitektur und die Datenträgertypen, die Sie für die Umgebung auswählen,
können sich auf die Systemleistung auswirken.
Inhalt dieses Abschnitts:
 Auswählen einer Speicherarchitektur

Auswählen von Datenträgertypen

Auswählen von RAID-Typen
Auswählen einer Speicherarchitektur
Die Speicherarchitekturen Direct Attached Storage (DAS), Storage Area Network (SAN)
und Network Attached Storage (NAS) werden von SharePoint Server 2010 unterstützt,
wobei NAS nur in Kombination mit Inhaltsdatenbanken unterstützt wird, die für die
Verwendung von Remote-BLOB-Speicher konfiguriert sind. Welche Option Sie
auswählen, hängt von Faktoren innerhalb der Unternehmenslösung und der bestehenden
Infrastruktur ab.
Jede Speicherarchitektur muss Ihre Anforderungen hinsichtlich der Verfügbarkeit
unterstützen und entsprechende IOPS- und Wartezeitwerte bieten. Damit das System
unterstützt wird, muss es das erste Byte mit Daten durchweg innerhalb von
20 Millisekunden (ms) zurückgeben.
Direct Attached Storage (DAS)
353
DAS ist ein digitales Speichersystem, das direkt und ohne zwischengelagertes
Speichernetzwerk an einen Server oder eine Arbeitsstation angeschlossen ist. Zu den
physikalischen Datenträgertypen für DAS gehören Serial Attached SCSI (SAS) und
Serial Attached ATA (SATA).
Im Allgemeinen empfiehlt es sich, eine DAS-Architektur auszuwählen, wenn eine
Plattform für freigegebenen Speicher keine Antwortzeiten von 20 ms und keine
ausreichende Kapazität für Durchschnitts- und Spitzen-IOPS sicherstellen kann.
Storage Area Network (SAN)
SAN ist eine Architektur, um Remotespeichergeräte (z. B. Datenträgerarrays und
Bandbibliotheken) so mit Servern zu verbinden, dass die Geräte wie lokal mit dem
Betriebssystem verbundene Geräte (z. B. Blockspeicher) angezeigt werden.
Im Allgemeinen empfiehlt sich die Auswahl eines SAN, wenn die Vorteile von
freigegebenem Speicher für Ihre Organisation eine wichtige Rolle spielen.
Zu den Vorteilen des freigegebenen Speichers zählen Folgende:
 Einfachere Neuzuordnung von Datenträgerspeicher zwischen verschiedenen Server.

Versorgung mehrerer Server.

Keine Begrenzungen hinsichtlich der Anzahl der Datenträger, auf die zugegriffen
werden kann.
Network Attached Storage (NAS)
Eine NAS-Einheit ist ein eigenständiger Computer, der mit einem Netzwerk verbunden
ist. Der einzige Zweck besteht darin, dateibasierte Datenspeicherdienste für andere
Geräte im Netzwerk bereitzustellen. Das Betriebssystem und andere Software auf der
NAS-Einheit bieten die Funktionalität für Datenspeicherung, Dateisysteme und
Dateizugriff und ermöglichen die Verwaltung dieser Funktionalität (z. B.
Datenspeicherung).
Hinweis:
NAS wird nur in Kombination mit Inhaltsdatenbanken unterstützt, die für die Verwendung
von Remote-BLOB-Speicher konfiguriert sind. Jede Netzwerkspeicherarchitektur muss
innerhalb von 1 ms auf ein Pingsignal antworten und das erste Byte mit Daten innerhalb
von 20 ms zurückgeben. Diese Einschränkung gilt nicht für den lokalen FILESTREAMAnbieter von SQL Server, da er Daten nur lokal auf dem gleichen Server speichert.
Auswählen von Datenträgertypen
Die im System verwendeten Datenträgertypen können sich auf die Zuverlässigkeit und
die Leistung auswirken. Unter ansonsten gleichbleibenden Bedingungen können größere
Laufwerke die durchschnittliche Zeit für Suchvorgänge erhöhen. SharePoint Server 2010
unterstützt die folgenden Laufwerkstypen:
 SCSI (Small Computer System Interface)

SATA (Serial Advanced Technology Attachment)

SAS (Serial-attached SCSI)

FC (Fibre Channel)

IDE (Integrated Device Electronics)
354

SSD (Solid State Drive) oder Flash Disk
Auswählen von RAID-Typen
RAID (Redundant Array of Independent Disks) wird häufig verwendet, um die
Leistungsmerkmale einzelner Datenträger (durch Verteilen der Daten auf verschiedene
Datenträger) zu verbessern und um Schutz vor dem Ausfall einzelner Datenträger zu
bieten.
Für SharePoint Server 2010 werden alle RAID-Typen unterstützt. Empfohlen wird jedoch
die Verwendung von RAID 10 oder einer herstellerspezifischen RAID-Lösung, die eine
vergleichbare Leistung bietet.
Beim Konfigurieren eines RAID-Arrays müssen Sie das Dateisystem am vom Hersteller
bereitgestellten Offset ausrichten. Falls keine diesbezüglichen Anweisungen vom
Hersteller verfügbar sind, finden Sie die entsprechenden Informationen unter Bewährte
E/A-Methoden bei der Vorabbereitstellung von SQL Server
(http://go.microsoft.com/fwlink/?linkid=105583&clcid=0x407).
Weitere Informationen zum Bereitstellen von RAID und zum SQL Server-E/A-Subsystem
finden Sie unter Bewährte Methoden für SQL Server
(http://go.microsoft.com/fwlink/?linkid=168612&clcid=0x407).
Prognostizieren der
Arbeitsspeicheranforderungen
Der für SharePoint Server 2010 erforderliche Arbeitsspeicher hängt direkt mit der Größe
der Inhaltsdatenbank zusammen, die Sie auf einem Server mit SQL Server hosten.
Werden Dienstanwendungen und Features hinzugefügt, werden die Anforderungen an
den Arbeitsspeicher aller Wahrscheinlichkeit nach ebenfalls steigen. In der folgenden
Tabelle finden Sie Richtlinien für die Größe des empfohlenen Arbeitsspeichers.
Hinweis:
Die hier zugrunde liegenden Definitionen für kleine und mittlere Bereitstellungen
entsprechen den Definitionen im Abschnitt "Referenzarchitekturen" des Artikels Capacity
management and sizing for SharePoint Server 2010 (in englischer Sprache).
Kombinierte Größe der Inhaltsdatenbanken
Empfohlener Arbeitsspeicher für Computer
mit SQL Server
Minimum für kleine
Produktionsbereitstellungen
8 GB
Minimum für mittlere
Produktionsbereitstellungen
16 GB
Empfehlung für bis zu 2 TB
32 GB
Empfehlung für den Bereich von 2 TB bis zu 64 GB
einem Maximum von 5 TB
355
Hinweis:
Diese Werte liegen aufgrund der für eine SharePoint Server 2010-Umgebung
erforderlichen Verteilung der Daten über den empfohlenen Mindestwerten für SQL
Server. Weitere Informationen zu SQL Server-Systemanforderungen finden Sie unter
Hardware- und Softwareanforderungen für die Installation von SQL Server 2008
(http://go.microsoft.com/fwlink/?linkid=129377&clcid=0x407).
Zu den weiteren Faktoren, die sich auf den erforderlichen Arbeitsspeicher auswirken
können, gehören folgende:
 Die Verwendung der SQL Server-Spiegelung.

Die häufige Verwendung von Dateien mit einer Größe von mehr als 15 MB.
Grundlegendes zu den Anforderungen an die
Netzwerktopologie
Planen Sie die Netzwerkverbindungen innerhalb von und zwischen Farmen. Es wird
empfohlen, ein Netzwerk mit geringer Wartezeit zu verwenden.
Die folgende Liste enthält einige bewährte Methoden und Empfehlungen.
 Alle Server in der Farm sollten mit LAN-Bandbreite und -Wartezeit mit dem Server
mit SQL Server verbunden sein. Die Wartezeit darf maximal 1 ms betragen.

Von einer WAN-Topologie, in der ein Server mit SQL Server entfernt von anderen
Farmkomponenten über ein Netzwerk mit einer Wartezeit von mehr als 1 ms
bereitgestellt wird, wird abgeraten. Diese Topologie wurde nicht getestet.

Planen Sie ein angemessenes WAN-Netzwerk, wenn Sie die SQL Server-Spiegelung
oder den Protokollversand verwenden möchten, um einen Remotestandort auf dem
neuesten Stand zu halten.

Für Webserver und Anwendungsserver wird die Verwendung von zwei
Netzwerkadaptern empfohlen: ein Adapter für die Verarbeitung des EndbenutzerDatenverkehrs und ein weiterer Adapter für die Verarbeitung der Kommunikation mit
den Servern mit SQL Server.
Konfigurieren von SQL Server
In den folgenden Abschnitten wird beschrieben, wie Sie die Konfiguration von SQL
Server für SharePoint Server 2010 planen sollten.
Inhalt dieses Abschnitts:
 Bestimmen der Anzahl der erforderlichen Instanzen oder Server

Konfigurieren von Speicher und Arbeitsspeicher

Festlegen von SQL Server-Optionen

Konfigurieren von Datenbanken
Bestimmen der Anzahl der erforderlichen Instanzen oder Server
356
Generell ist SharePoint Server 2010 so konzipiert, dass die Vorteile der horizontalen
Skalierung von SQL Server genutzt werden, d. h., SharePoint Server 2010 zeigt bei einer
großen Anzahl mittelgroßer Server mit SQL Server möglicherweise eine bessere
Leistung als bei wenigen großen Servern.
Platzieren Sie SQL Server immer auf einem dedizierten Server, auf dem keine weiteren
Farmrollen ausgeführt oder Datenbanken für andere Anwendungen gehostet werden, es
sei denn, Sie stellen das System auf einem eigenständigen Server bereit.
Im Folgenden finden Sie allgemeine Richtlinien für die Bereitstellung eines weiteren
Servers mit SQL Server:
 Fügen Sie einen weiteren Datenbankserver hinzu, wenn Sie mehr als vier Webserver
verwenden, die alle mit voller Auslastung betrieben werden.

Fügen Sie einen weiteren Datenbankserver hinzu, wenn die Inhaltsdatenbanken
mehr als 5 TB umfassen.
Hinweis:
Microsoft unterstützt Serverkonfigurationen, die diese Richtlinien nicht einhalten.
Zur Unterstützung der sicheren Speicherung von Anmeldeinformationen bei Verwendung
der Secure Store Service-Anwendung wird empfohlen, die Datenbank für einmaliges
Anmelden auf einer separaten Datenbankinstanz zu hosten, für die der Zugriff auf einen
Administrator begrenzt ist.
Konfigurieren von Speicher und Arbeitsspeicher
Auf dem Server mit SQL Server 2008 wird für den L2-Cache pro CPU eine Größe von
mindestens 2 MB empfohlen, um den Arbeitsspeicher zu verbessern.
Befolgen der Konfigurationsempfehlungen des Speicherherstellers
Befolgen Sie beim Konfigurieren eines physikalischen Speicherarrays die Empfehlungen
des Speicherherstellers zur Hardwarekonfiguration, um eine optimale Leistung zu
erzielen. Übernehmen Sie nicht die Standardwerte des Betriebssystems.
Falls Ihnen keine Empfehlungen des Herstellers vorliegen, sollten Sie das
Datenträgerkonfigurationsprogramm DiskPart.exe verwenden, um den Speicher für
SQL Server 2008 zu konfigurieren. Weitere Informationen finden Sie unter Bewährte E/AMethoden bei der Vorabbereitstellung
(http://go.microsoft.com/fwlink/?linkid=105583&clcid=0x407).
Bereitstellen möglichst vieler Ressourcen
Stellen Sie sicher, dass die SQL Server-E/A-Kanäle zu den Datenträgern nicht auch von
anderen Anwendungen verwendet werden, z. B. der Auslagerungsdatei und IISProtokollen (Internetinformationsdienste).
Stellen Sie so viel Busbandbreite wie möglich zur Verfügung. Mehr Busbandbreite trägt
zur Erhöhung der Zuverlässigkeit und der Leistung bei. Bedenken Sie, dass der
Datenträger nicht der einzige Verbraucher von Busbandbreite ist. Sie müssen hierbei
beispielsweise auch den Netzwerkzugriff berücksichtigen.
Festlegen von SQL Server-Optionen
Sie sollten die folgenden SQL Server-Einstellungen und Optionen konfigurieren, bevor
Sie SharePoint Server bereitstellen.
357

Aktivieren Sie nicht die automatische Erstellung von Statistiken auf einem Computer
mit SQL Server, der SharePoint Server unterstützt. Von SharePoint Server werden
bestimmte Statistiken implementiert; weitere Statistiken werden nicht benötigt. Durch
das automatische Erstellen von Statistiken kann sich der Ausführungsplan einer
Abfrage von einer Instanz von SQL Server zu einer anderen Instanz von SQL Server
erheblich ändern. Um allen Kunden eine einheitliche Unterstützung zu bieten, stellt
SharePoint Server daher bei Bedarf codierte Hinweise für Abfragen zur Verfügung,
um szenarioübergreifend eine optimale Leistung zu bieten.

Um eine optimale Leistung sicherzustellen, wird empfohlen, die Option max degree
of parallelism für Datenbankserver, die SharePoint Server 2010-Datenbanken
hosten, auf 1 festzulegen. Weitere Informationen zum Festlegen von max degree of
parallelism finden Sie unter max degree of parallelism (Option)
(http://go.microsoft.com/fwlink/?linkid=189030&clcid=0x407).

Um die Wartung zu vereinfachen, sollten Sie für jeden Datenbankserver in der Farm
SQL Server-Verbindungsaliasnamen konfigurieren. Ein Verbindungsalias ist ein
alternativer Name, der verwendet werden kann, um eine Verbindung zu einer Instanz
von SQL Server herzustellen. Weitere Informationen finden Sie unter
Vorgehensweise: Festlegen eines SQL Server-Alias (SQL Server Management
Studio) (http://go.microsoft.com/fwlink/?linkid=132064&clcid=0x407).
Konfigurieren von Datenbanken
Im Folgenden werden bewährte Methoden für die Planung der Konfiguration der
einzelnen Datenbanken in einer Umgebung beschrieben.
Verteilen und Priorisieren von Daten auf Datenträgern
Idealerweise sollten Sie die tempdb-Datenbank, Inhaltsdatenbanken, die
Verwendungsdatenbank, Suchdatenbanken und SQL Server 2008Transaktionsprotokolle auf getrennten physikalischen Festplatten platzieren.
Die folgende Liste enthält einige bewährte Methoden und Empfehlungen für die
Priorisierung von Daten:
 Verwenden Sie beim Priorisieren von Daten zwischen schnelleren Festplatten die
folgende Rangfolge:
1. Tempdb-Datendateien und Transaktionsprotokolle
2. Datenbank-Transaktionsprotokolldateien
3. Suchdatenbanken, ausgenommen die Suchverwaltungsdatenbank

4. Datenbankdatendateien
Bei einer Portalwebsite mit vorwiegend Lesezugriffen sollten Sie Daten Vorrang
vor Protokollen geben.
Anhand von Tests und Kundendaten wurde nachgewiesen, dass die SharePoint
Server 2010-Farmleistung durch eine unzureichende Datenträger-E/A für die
tempdb-Datenbank erheblich beeinträchtigt werden kann. Weisen Sie für tempdb
dedizierte Datenträger zu, um dieses Problem zu vermeiden. Wenn eine hohe
Arbeitsauslastung erwartet oder beobachtet wird (d. h., der durchschnittliche
Lesevorgang oder der durchschnittliche Schreibvorgang dauert länger als 20 ms),
müssen Sie den Engpass ggf. beheben, indem Sie die Dateien entweder auf
verschiedenen Datenträgern speichern oder die vorhandenen Datenträger durch
schnellere Datenträger ersetzen.
358

Um eine optimale Leistung zu erzielen, sollten Sie tempdb auf einem RAID 10-Array
platzieren. Die Anzahl der tempdb-Datendateien sollte der Anzahl der Kern-CPUs
entsprechen, und für die tempdb-Datendateien sollte eine einheitliche Größe
festgelegt werden. Doppelkernprozessoren werden in diesem Zusammenhang wie
zwei CPUs gezählt. Werten Sie jeden Prozessor, der Hyperthreading unterstützt, als
eine CPU. Weitere Informationen finden Sie unter Optimieren der Leistung von
'tempdb' (http://go.microsoft.com/fwlink/?linkid=148537&clcid=0x407).

Speichern Sie die Datenbankdaten- und Transaktionsprotokolldateien auf
verschiedenen Datenträgern. Wenn Dateien Datenträger gemeinsam nutzen
müssen, weil die Dateien zu klein sind, um die Verwendung eines ganzen
Datenträgers oder Stripesets zu rechtfertigen, oder weil nicht genügend
Speicherplatz verfügbar ist, speichern Sie Dateien mit verschiedenen
Verwendungsmustern auf demselben Datenträger, um gleichzeitige
Zugriffsanforderungen zu minimieren.

Wenden Sie sich an den Hersteller der Speicherhardware, um zu erfahren, wie
Protokolle und Suchdatenbanken konfiguriert werden müssen, um Schreibvorgänge
für eine spezifische Speicherlösung zu optimieren.
Verwenden mehrerer Datendateien für Inhaltsdatenbanken
Folgen Sie diesen Empfehlungen zur Optimierung der Leistung:
 Erstellen Sie nur Dateien in der primären Dateigruppe für die Datenbank.

Verteilen Sie die Dateien auf verschiedene Datenträger.

Die Anzahl der Datendateien sollte kleiner oder gleich der Anzahl der Kern-CPUs
sein. Hierbei sollten Doppelkernprozessoren als zwei CPUs gezählt werden. Jeder
Prozessor mit Unterstützung für Hyperthreading wird als eine CPU gezählt.

Erstellen Sie gleich große Datendateien.
Wichtig:
Obwohl Sie die in SharePoint Server 2010 integrierten Sicherungs- und
Wiederherstellungstools zum Sichern und Wiederherstellen mehrerer Datendateien
verwenden können, ist es im Falle von Überschreibungen an demselben Speicherort
nicht möglich, mithilfe dieser Tools mehrere Datendateien an einem anderen Speicherort
wiederherzustellen. Aus diesem Grund wird die Verwendung der Sicherungs- und
Wiederherstellungstools von SQL Server empfohlen, wenn Sie mehrere Datendateien für
eine Inhaltsdatenbank verwenden. Weitere Informationen zum Sichern und
Wiederherstellen von SharePoint Server 2010 finden Sie unter Plan for backup and
recovery (SharePoint Server 2010).
Weitere Informationen zum Erstellen und Verwalten von Dateigruppen finden Sie unter
Architektur von Dateien und Dateigruppen
(http://go.microsoft.com/fwlink/?linkid=117909&clcid=0x407).
Begrenzen der Größe der Inhaltsdatenbank zur Verbesserung der
Verwaltbarkeit
Planen Sie die Datenbankgröße so, dass die Verwaltbarkeit und Leistung der Umgebung
verbessert und ein Upgrade vereinfacht wird.
359
Um die Systemleistung sicherzustellen, wird nachdrücklich empfohlen, die Größe der
Inhaltsdatenbanken auf 200 GB zu begrenzen.
Eine Websitesammlung sollte die Größe von 100 GB nur dann überschreiten, wenn es
sich um die einzige Websitesammlung in der Datenbank handelt. Durch diesen
Grenzwert wird sichergestellt, dass Sie die SharePoint Server 2010-Tools für
differenzierte Sicherungen verwenden können, um eine Websitesammlung, falls
notwendig, in eine andere Datenbank zu verschieben.
Wichtig:
Inhaltsdatenbanken mit einer Größe von bis zu 1 TB werden nur bei großen Repositorys
und Archiven mit einer einzigen Website unterstützt, in denen die Daten weitgehend
statisch bleiben, beispielsweise Systeme zur Verwaltung von Verweisdokumenten und
Datenarchiv-Websites. In diesen Szenarien werden größere Datenbankgrößen
unterstützt, da die E/A-Muster und die typischen Datenstrukturformate für größere
Maßstäbe entworfen und getestet wurden.
Wenn für Ihre Umgebung eine Datenbank erforderlich ist, deren Größe den empfohlenen
Wert überschreitet, sollten Sie sich an die folgenden Richtlinien halten:
 Bei Datenbanken mit vielen großen Dateien, die als BLOBs (Binary Large Objects)
gespeichert werden, sollten Sie die Verwendung von Remote-BLOB-Speicher (RBS)
erwägen. RBS ist unter folgenden Bedingungen geeignet:
1. Wenn Sie Websites ausführen, die große Dateien enthalten, auf die selten
zugegriffen wird, z. B. Wissensrepositorys.
2. Wenn Sie über Daten im Umfang von mehreren TB verfügen.
3. Für Video- oder Mediendateien.
Weitere Informationen finden Sie unter Plan for remote BLOB storage (RBS)
(SharePoint Server 2010).
 Folgen Sie den bewährten Methoden zum Anzeigen von Daten aus großen
Datenbanken. Weitere Informationen finden Sie unter SharePoint Server 2010Kapazitätsverwaltung: Softwarebeschränkungen und -grenzen.
Weitere Informationen zu großen Dokumentrepositorys finden Sie unter "Abschätzen der
Leistungs- und Kapazitätsanforderungen für große Dokumentrepositorys" unter
Ergebnisse der Leistungs- und Kapazitätstests und Empfehlungen (SharePoint Server
2010).
Proaktives Verwalten des Zuwachses von Daten- und
Protokolldateien
Es wird empfohlen, den Zuwachs von Daten- und Protokolldateien proaktiv zu verwalten,
indem Sie die folgenden Empfehlungen berücksichtigen:
 Vergrößern Sie, soweit wie möglich, vorab alle Daten- und Protokolldateien auf ihre
erwartete endgültige Größe.

Es empfiehlt sich, die automatische Vergrößerung aus Sicherheitsgründen zu
aktivieren. Verlassen Sie sich nicht auf die Standardeinstellungen für die
automatische Vergrößerung. Orientieren Sie sich beim Konfigurieren dieser
Einstellungen an den folgenden Richtlinien:
360


Wenn Sie Inhaltsdatenbanken planen, die die empfohlene Größe von 200 GB
überschreiten, legen Sie den Wert für die automatische Datenbankvergrößerung
auf eine feste Anzahl von Megabytes und nicht auf einen Prozentsatz fest.
Dadurch wird die Häufigkeit verringert, mit der SQL Server die Dateigröße
erhöht. Das Erhöhen der Dateigröße ist ein blockierender Vorgang, bei dem der
neue Platz mit leeren Seiten gefüllt werden muss.

Legen Sie den Wert für die automatische Vergrößerung für die
Eigenschaftenspeicher-Datenbank der Suchdienstanwendung auf 10 % fest.

Wenn davon auszugehen ist, dass die berechnete Größe der Inhaltsdatenbank
innerhalb des nächsten Jahres nicht die empfohlene Maximalgröße von 200 GB
erreicht, sollten Sie für die Datenbank mithilfe der ALTER DATABASE
MAXSIZE-Eigenschaft die maximale Größe, die sie laut Prognose innerhalb
eines Jahres erreichen wird, zuzüglich eines 20 %igen Fehlerzuschlags
festlegen. Überprüfen Sie diese Eigenschaft regelmäßig anhand der
zurückliegenden Zuwachsraten, um sicherzustellen, dass sie immer noch einen
geeigneten Wert aufweist.
Sorgen Sie dafür, dass ein Niveau von mindestens 25 % an verfügbarem
Speicherplatz über alle Datenträger hinweg aufrechterhalten wird, um ausreichend
Spielraum für Vergrößerungen und Verwendungsmuster bei Spitzenauslastungen zu
bieten. Wenn die Größenverwaltung durch Hinzufügen weiterer Datenträger zu
einem RAID-Array oder durch Zuordnung weiteren Speichers erfolgt, müssen Sie die
Datenträgergröße genau überwachen, um Speicherplatzengpässe zu vermeiden.
Überprüfen von Speicherleistung und zuverlässigkeit
Überprüfen Sie, ob die Leistung und die Sicherungslösung der verwendeten Hardware
die Einhaltung Ihrer Servicelevel-Vereinbarungen ermöglicht. Testen Sie insbesondere
die E/A-Subsysteme des Computers mit SQL Server, um eine zufriedenstellende
Leistung sicherzustellen.
Testen Sie die verwendete Sicherungslösung, um sicherzustellen, dass eine Sicherung
innerhalb des verfügbaren Wartungszeitfensters möglich ist. Wenn die in Ihrem
Unternehmen erforderlichen Servicelevel-Vereinbarungen durch die Sicherungslösung
nicht eingehalten werden, sollten Sie die Verwendung einer Lösung für inkrementelle
Sicherungen wie System Center Data Protection Manager (DPM) 2010 in Erwägung
ziehen.
Es ist wichtig, die folgenden Ressourcenkomponenten eines Servers mit SQL Server
nachzuverfolgen: CPU, Arbeitsspeicher, Cachetrefferverhältnis und E/A-Subsystem.
Wenn eine oder mehrere dieser Komponenten langsam oder überlastet zu sein scheinen,
müssen Sie die entsprechende Strategie auf der Basis der aktuellen und prognostizierten
Arbeitsauslastung analysieren. Weitere Informationen finden Sie unter Behandeln von
Leistungsproblemen in SQL Server 2008
(http://go.microsoft.com/fwlink/?linkid=168448&clcid=0x407).
Im folgenden Abschnitt sind die Leistungsindikatoren aufgeführt, die Sie zum
Überwachen der Leistung der SQL Server-Datenbanken verwenden sollten, die in einer
SharePoint Server 2010-Umgebung ausgeführt werden. Für jeden Leistungsindikator
361
sind darüber hinaus die ungefähren Werte aufgeführt, die einen reibungslosen Betrieb
widerspiegeln.
Ausführliche Informationen zum Überwachen der Leistung und zur Verwendung von
Leistungsindikatoren finden Sie unter Erste Schritte mit der Leistungsüberwachung
(http://go.microsoft.com/fwlink/?linkid=189032&clcid=0x407).
Zu überwachende SQL Server-Leistungsindikatoren
Überwachen Sie die folgenden SQL Server-Leistungsindikatoren, um die Integrität Ihrer
Server sicherzustellen:
 Allgemeine Statistik Dieses Objekt stellt Leistungsindikatoren für die
Überwachung der allgemeinen serverweiten Aktivität zur Verfügung, z. B. die Anzahl
gleichzeitiger Verbindungen und die Anzahl der Benutzer, die pro Sekunde von
Computern mit einer Instanz von SQL Server eine Verbindung herstellen oder
trennen. Erwägen Sie die Überwachung des folgenden Leistungsindikators:


Datenbanken Dieses Objekt stellt Leistungsindikatoren für die Überwachung von
Massenkopiervorgängen, des Sicherungs- und Wiederherstellungsdurchsatzes und
von Transaktionsprotokollaktivitäten zur Verfügung. Überwachen Sie Transaktionen
und das Transaktionsprotokoll, um den Umfang der Benutzeraktivitäten in der
Datenbank zu bestimmen und festzustellen, in welchem Umfang das
Transaktionsprotokoll aufgefüllt wird. Der Umfang der Benutzeraktivitäten kann die
Leistung der Datenbank bestimmen und sich auf die Protokollgröße, Sperren und die
Replikation auswirken. Die Überwachung von Protokollaktivitäten auf niedriger Ebene
zur Messung von der Benutzeraktivität und der Ressourcennutzung kann Ihnen
helfen, Leistungsengpässe zu identifizieren. Erwägen Sie die Überwachung des
folgenden Leistungsindikators:


Benutzerverbindungen Dieser Leistungsindikator zeigt den Umfang der
Benutzerverbindungen auf dem Computer mit SQL Server an. Wenn dieser Wert
um mehr als 500 % ausgehend von Ihrer Baseline ansteigt, kann sich dies in
Leistungseinbußen niederschlagen.
Transaktionen/Sekunde Dieser Leistungsindikator zeigt den Umfang der
Transaktionen für eine bestimmte Datenbank oder den gesamten Server pro
Sekunde an. Dieser Wert hilft Ihnen vor allem hinsichtlich Ihrer Baseline und bei
der Problembehandlung.
Sperren Dieses Objekt stellt Informationen zu SQL Server-Sperren für einzelne
Ressourcentypen zur Verfügung. Erwägen Sie die Überwachung der folgenden
Leistungsindikatoren:

Durchschnittliche Wartezeit (in Millisekunden) Dieser Leistungsindikator
zeigt die durchschnittliche Länge der Wartezeit für jede Sperranforderung an, die
nicht sofort erfüllt werden konnte.

Wartezeit für Sperre (in Millisekunden) Dieser Leistungsindikator zeigt die
Wartezeit für Sperren in der vergangenen Sekunde an.

Sperrenwartevorgänge/Sekunde Dieser Leistungsindikator zeigt die Anzahl
der Sperren pro Sekunde an, die nicht sofort erfüllt werden konnten, sodass auf
Ressourcen gewartet werden musste.

Anzahl der Deadlocks/Sekunde Dieser Leistungsindikator zeigt die Anzahl der
Deadlocks pro Sekunde auf dem Computer mit SQL Server an. Dieser Wert
sollte nicht größer als 0 werden.
362




Latches Dieses Objekt stellt Leistungsindikatoren für die Überwachung interner
SQL Server-Ressourcensperren, so genannter Latches, zur Verfügung. Die
Überwachung von Latches zum Bestimmen der Benutzeraktivität und der
Ressourcennutzung kann Ihnen helfen, Leistungsengpässe zu identifizieren.
Erwägen Sie die Überwachung der folgenden Leistungsindikatoren:

Durchschnittliche Wartezeit für Latch (in Millisekunden) Dieser
Leistungsindikator zeigt die durchschnittliche Wartezeit für Latchanforderungen
an, die nicht sofort erfüllt werden konnten.

Latchwartevorgänge/Sekunde Dieser Leistungsindikator zeigt die Anzahl der
Latchanforderungen an, die nicht sofort erfüllt werden konnten.
SQL-Statistik Dieses Objekt stellt Leistungsindikatoren für die Überwachung der
Kompilierung und des Typs der Anforderungen zur Verfügung, die an eine Instanz
von SQL Server gesendet werden. Die Überwachung der Anzahl der
Abfragekompilierungen und Neukompilierungen sowie der Anzahl der Batches, die
von einer Instanz von SQL Server empfangen wurden, liefert Ihnen einen Hinweis
darauf, wie schnell Benutzerabfragen von SQL Server verarbeitet werden und wie
effektiv der Abfrageoptimierer die Abfragen verarbeitet. Erwägen Sie die
Überwachung der folgenden Leistungsindikatoren:

SQL-Kompilierungen/Sekunde Dieser Leistungsindikator zeigt an, wie oft der
Pfad für den Kompilierungscode pro Sekunde eingegeben wurde.

Erneute SQL-Kompilierungen/Sekunde Dieser Leistungsindikator zeigt die
Anzahl der erneuten Anweisungskompilierungen pro Sekunde an.
Puffer-Manager Dieses Objekt stellt Leistungsindikatoren zur Verfügung, mit denen
Sie überwachen können, wie SQL Server den Arbeitsspeicher zum Speichern von
Datenseiten, internen Datenstrukturen und des Prozedurcaches verwendet. Es stellt
darüber hinaus Leistungsindikatoren bereit, um die physische E/A, während SQL
Server Datenbankseiten liest und schreibt, zu überwachen. Erwägen Sie die
Überwachung des folgenden Leistungsindikators:

Puffercache-Trefferquote

Dieser Leistungsindikator zeigt den Prozentsatz der Seiten an, die im
Puffercache gefunden wurden, ohne dass ein Lesevorgang vom Datenträger
erforderlich war. Die Quote entspricht der Gesamtzahl von Cachetreffern dividiert
durch die Gesamtzahl der Cachesuchvorgänge für die letzten paar Tausend
Seitenzugriffe. Da das Lesen vom Cache weniger aufwendig als das Lesen vom
Datenträger ist, ist es in Ihrem Interesse, dass diese Quote hoch ist. Im
Allgemeinen können Sie die Puffercache-Trefferquote erhöhen, indem Sie den
Arbeitsspeicher, der SQL Server zur Verfügung steht, erhöhen.
Plancache Dieses Objekt stellt Leistungsindikatoren zur Verfügung, mit denen Sie
überwachen können, wie SQL Server den Arbeitsspeicher zum Speichern von
Objekten wie gespeicherten Prozeduren, Ad-hoc-Anweisungen und vorbereiteten
Transact-SQL-Anweisungen sowie Triggern verwendet. Erwägen Sie die
Überwachung des folgenden Leistungsindikators:

Cachetrefferquote

Dieser Leistungsindikator zeigt das Verhältnis zwischen Cachetreffern und
Plansuchvorgängen an.
363
Zu überwachende Leistungsindikatoren des physikalischen Servers
Überwachen Sie die folgenden Leistungsindikatoren, um die Integrität der Computer mit
SQL Server sicherzustellen:
 Prozessor: Gesamtprozessorzeit (%) Dieser Leistungsindikator zeigt den
Prozentsatz der Prozessorzeit an, die zum Ausführen von Anwendungs- oder
Betriebssystemprozessen aufgewendet wird, die sich nicht im Leerlauf befinden. Auf
dem Computer mit SQL Server sollte dieser Leistungsindikator in einem Bereich
zwischen 50 und 75 % liegen. Bei dauerhafter Überlastung sollten Sie überprüfen, ob
ungewöhnliche Prozessaktivitäten vorliegen oder ob der Server zusätzliche CPUs
benötigt.

System: Prozessor-Warteschlangenlänge Dieser Leistungsindikator zeigt die
Anzahl der Threads in der Prozessorwarteschlange an. Überwachen Sie diesen
Leistungsindikator, um sicherzustellen, dass er weniger als das Zweifache der
Anzahl an Kern-CPUs beträgt.

Arbeitsspeicher: Verfügbare MB Dieser Leistungsindikator zeigt den Umfang des
physikalischen Speichers in MB an, der für die auf dem Computer ausgeführten
Prozesse verfügbar ist. Überwachen Sie diesen Leistungsindikator, um
sicherzustellen, dass ein Niveau von mindestens 20 % des insgesamt verfügbaren
physikalischen Arbeitsspeichers aufrechterhalten wird.

Arbeitsspeicher: Seiten/s Dieser Leistungsindikator zeigt die Geschwindigkeit an,
mit der Seiten vom Datenträger gelesen oder auf den Datenträger geschrieben
werden, um Hardware-Seitenfehler zu beheben. Überwachen Sie diesen
Leistungsindikator, um sicherzustellen, dass sein Wert unter 100 bleibt.
Weitere Informationen und Beschreibungen von Methoden zum Beheben von
Arbeitsspeicherproblemen finden Sie unter Überwachen der Arbeitsspeicherverwendung
(http://go.microsoft.com/fwlink/?linkid=105585&clcid=0x407).
Zu überwachende Datenträger-Leistungsindikatoren
Überwachen Sie die folgenden Leistungsindikatoren, um die Integrität der Datenträger
sicherzustellen. Beachten Sie, dass es sich bei den folgenden Werten um Messwerte
handelt, die über einen Zeitraum gemessen werden, und nicht um plötzlich auftretende
Spitzenwerte oder Werte, die auf einer einzigen Messung basieren.
 Physikalischer Datenträger: Zeit (%): Datenlaufwerk Dieser Leistungsindikator
zeigt den Prozentsatz der verstrichenen Zeit an, die das ausgewählte Laufwerk mit
dem Bearbeiten von Lese- und Schreibanforderungen beschäftigt ist. Dieser Wert ist
ein allgemeiner Indikator für die Auslastung des Datenträgers. Wenn der
Leistungsindikator Physikalischer Datenträger: Zeit (%) einen hohen Wert (über
90 %) aufweist, sollten Sie den Leistungsindikator Physikalischer Datenträger:
Aktuelle Warteschlangenlänge überprüfen, um festzustellen, wie viele
Systemanforderungen auf den Datenträgerzugriff warten. Die Anzahl der wartenden
E/A-Anforderungen sollte nicht mehr als das 1,5- bis 2fache der Anzahl der
physikalischen Laufwerke betragen, aus denen der physikalische Datenträger
besteht.

Logischer Datenträger: Übertragungen/s Dieser Leistungsindikator zeigt die
Geschwindigkeit an, mit der Lese- und Schreibvorgänge auf dem Datenträger
ausgeführt werden. Verwenden Sie diesen Leistungsindikator, um Zuwachstrends zu
überwachen und entsprechende Prognosen zu formulieren.
364

Logischer Datenträger: Bytes gelesen/s und Logischer Datenträger: Bytes
geschrieben/s Diese Leistungsindikatoren zeigen die Geschwindigkeit an, mit der
Bytes bei Lese- oder Schreibvorgängen vom bzw. zum Datenträger übertragen
werden.

Logischer Datenträger: Mittlere Bytes/Lesevorgang Dieser Leistungsindikator
zeigt die durchschnittliche Anzahl der Bytes an, die bei Lesevorgängen vom
Datenträger übertragen werden. Dieser Wert kann die Wartezeit für den Datenträger
wiedergeben; umfangreichere Lesevorgänge können zu geringfügig längeren
Wartezeiten führen.

Logischer Datenträger: Mittlere Bytes/Schreibvorgang Dieser Leistungsindikator
zeigt die durchschnittliche Anzahl der Bytes an, die bei Schreibvorgängen zum
Datenträger übertragen werden. Dieser Wert kann die Wartezeit für den Datenträger
wiedergeben; größere Schreibvorgänge können zu geringfügig längeren Wartezeiten
führen.

Logischer Datenträger: Aktuelle Warteschlangenlänge Dieser
Leistungsindikator zeigt die Anzahl der ausstehenden Anforderungen zum Zeitpunkt
der Erfassung der Leistungsdaten an. Bei diesem Leistungsindikator sind niedrigere
Werte besser. Werte größer als 2 pro Datenträger können auf einen Engpass
hinweisen und sollten näher untersucht werden. Das bedeutet, dass ein Wert von bis
zu 8 für eine logische Einheit (LUN) aus bis zu 4 Datenträgern akzeptabel sein kann.
Engpässe können zu Rückständen führen, die sich über den aktuellen Server, der
auf den Datenträger zugreift, hinaus erstrecken und lange Wartezeiten für die
Benutzer verursachen. Mögliche Lösungen für einen Engpass können darin
bestehen, weitere Datenträger zum RAID-Array hinzuzufügen, vorhandene
Datenträger durch schnellere Datenträger zu ersetzen oder einen Teil der Daten auf
andere Datenträger zu verschieben.

Logischer Datenträger: Durchschnittl. Warteschlangenlänge des
Datenträgers Dieser Leistungsindikator zeigt die durchschnittliche Anzahl der Leseund Schreibanforderungen an, die während des Erfassungsintervalls für den
ausgewählten Datenträger in die Warteschlange gestellt wurden. Generell gilt, dass
es pro physikalischem Laufwerk maximal zwei ausstehende Lese- und
Schreibanforderungen geben sollte. Dies ist aufgrund von Speichervirtualisierung
und Unterschieden bei den RAID-Stufen der verschiedenen Konfigurationen jedoch
schwierig zu messen. Suchen Sie nach überdurchschnittlich langen DatenträgerWarteschlangen in Kombination überdurchschnittlich langen Datenträgerwartezeiten.
Diese Kombination kann darauf hinweisen, dass der Speicherarraycache überlastet
ist oder dass sich die gemeinsame Nutzung des physikalischen Laufwerks mit
anderen Anwendungen nachteilig auf die Leistung auswirkt.

Logischer Datenträger: Mittlere Sek./Lesevorgänge und Logischer Datenträger:
Mittlere Sek./Schreibvorgänge Diese Leistungsindikatoren zeigen die
durchschnittliche Dauer (in Sekunden) für Lese- oder Schreibvorgänge auf dem
Datenträger an. Überwachen Sie diese Leistungsindikatoren, um sicherzustellen,
dass sie einen Wert von 85 % der Datenträgerkapazität nicht überschreiten. Die
Datenträger-Zugriffszeiten steigen exponentiell, wenn Lese- oder Schreibvorgänge
mehr als 85 % der Datenträgerkapazität ausmachen. Informationen zum Bestimmen
der Kapazität der von Ihnen verwendeten Hardware finden Sie in der Dokumentation
des Herstellers. Alternativ können Sie auch das Datenträgersubsystem365
Benchmarktool SQLIO für die Berechnung der Kapazität verwenden. Weitere
Informationen finden Sie unter SQLIO: Datenträgersubsystem-Benchmarktool
(http://go.microsoft.com/fwlink/?linkid=105586&clcid=0x407).

Logischer Datenträger: Mittlere Sek./Lesevorgänge Dieser
Leistungsindikator zeigt die durchschnittliche Dauer (in Sekunden) eines
Lesevorgangs vom Datenträger an. Bei einem optimal konfigurierten System
liegen die Idealwerte zwischen 1 und 5 ms für Protokolle (idealerweise 1 ms für
ein zwischengespeichertes Array) und zwischen 4 und 20 ms für Daten
(idealerweise unter 10 ms). Höhere Wartezeiten können zu Spitzenzeiten
auftreten. Treten jedoch häufiger höhere Werte auf, sollten Sie die Ursachen
näher untersuchen.

Logischer Datenträger: Mittlere Sek./Schreibvorgänge Dieser
Leistungsindikator zeigt die durchschnittliche Dauer (in Sekunden) eines
Schreibvorgangs auf dem Datenträger an. Bei einem optimal konfigurierten
System liegen die Idealwerte zwischen 1 und 5 ms für Protokolle (idealerweise
1 ms für ein zwischengespeichertes Array) und zwischen 4 und 20 ms für Daten
(idealerweise unter 10 ms). Höhere Wartezeiten können zu Spitzenzeiten
auftreten. Treten jedoch häufiger höhere Werte auf, sollten Sie die Ursachen
näher untersuchen.
Wenn Sie RAID-Konfigurationen mit dem Leistungsindikator Mittlere
Sek./Lesevorgänge oder Mittlere Sek./Schreibvorgänge verwenden, sollten
Sie die in der folgenden Tabelle aufgeführten Formeln verwenden, um die Einund Ausgabegeschwindigkeit für den Datenträger zu bestimmen.
RAID-Stufe
Formel
RAID 0
E/As pro Datenträger = (Lesevorgänge +
Schreibvorgänge) / Anzahl der Datenträger
RAID 1
E/As pro Datenträger = [Lesevorgänge + (2
× Schreibvorgänge)] / 2
RAID 5
E/As pro Datenträger = [Lesevorgänge + (4
× Schreibvorgänge)] / Anzahl der
Datenträger
RAID 10
E/As pro Datenträger = [Lesevorgänge + (2
× Schreibvorgänge)] / Anzahl der
Datenträger
Beispiel für ein RAID 1-System mit zwei physikalischen Datenträgern,
für das die Leistungsindikatoren die in der folgenden Tabelle aufgeführten Werte
aufweisen:
Leistungsindikator
Werte
Mittlere Sek./Lesevorgänge
80
Logischer Datenträger: Mittlere
Sek./Schreibvorgänge
70
Durchschnittl. Warteschlangenlänge des 5
366
Leistungsindikator
Werte
Datenträgers
Der E/A-Wert pro Datenträger kann folgendermaßen berechnet
werden: (80 + (2 × 70)) / 2 = 110
Die Warteschlangenlänge des Datenträgers kann folgendermaßen berechnet
werden: 5 / 2 = 2,5
In dieser Situation liegt ein grenzwertiger E/A-Engpass vor.
Weitere Überwachungstools
Für die Überwachung der Datenträgerwartezeit und die Trendanalyse können Sie auch
die dynamische Verwaltungssicht sys.dm_io_virtual_file_stats in SQL Server 2008
verwenden. Weitere Informationen finden Sie unter sys.dm_io_virtual_file_stats
(Transact-SQL) (http://go.microsoft.com/fwlink/?linkid=105587&clcid=0x407).
367