download.microsoft.com€¦ · Web viewWord Automation Services-Anwendung Dieser Dienst...

Kapazitätsplanung für Microsoft SharePoint Server 2010Microsoft CorporationVeröffentlicht: Januar 2011Autor: Microsoft Office System and Servers Team ([email protected])

ZusammenfassungDieses 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 2010-Bereitstellung 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.

http://go.microsoft.com/fwlink/?linkid=181463&clcid=0x407







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.

InhaltKapazitätsplanung für Microsoft SharePoint Server 2010..............................................1

Abrufen von Hilfe...............................................................................................................9

Leistungs- und Kapazitätsverwaltung (SharePoint Server 2010).....................................10

Capacity management and sizing for SharePoint Server 2010 (in englischer Sprache). .12

Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht)....13

Glossar......................................................................................................................... 13

Wer sollte Artikel zur Kapazitätsverwaltung lesen?.......................................................14

Die Vier Grundkonzepte der Leistung...........................................................................17

Kapazitätsverwaltung und Kapazitätsplanung..............................................................21

Über- und Unterdimensionierung..................................................................................23

Softwaregrenzwerte und -beschränkungen..................................................................25

Wichtige Unterschiede zwischen SharePoint Server 2010 und Office SharePoint Server 2007...............................................................................................................26

Wichtige Unterscheidungsmerkmale bei Bereitstellungen von SharePoint Server 2010.................................................................................................................................. 34

Referenzarchitekturen..................................................................................................37

Siehe auch....................................................................................................................41

Kapazitätsplanung für SharePoint Server 2010...............................................................42

Schritt 1: Modellierung..................................................................................................42

Schritt 2: Entwurf..........................................................................................................52

Schritt 3: Pilot-, Test- und Optimierungsphase..............................................................57

Schritt 4: Bereitstellung.................................................................................................58

Schritt 5: Überwachung und Wartung...........................................................................59

Siehe auch....................................................................................................................59

Testen der Leistung für SharePoint Server 2010.............................................................61

Erstellen eines Testplans..............................................................................................62

Erstellen der Testumgebung.........................................................................................62

Erstellen von Tests und Tools.......................................................................................64

Siehe auch....................................................................................................................69

Überwachen und Verwalten von SharePoint Server 2010...............................................70

Konfigurieren der Überwachung...................................................................................70

Beseitigen von Engpässen...........................................................................................81

Siehe auch....................................................................................................................84

SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und -grenzen..................................................................................................................................... 85

Übersicht über Beschränkungen und Grenzen.............................................................86

Beschränkungen und Grenzen.....................................................................................89

Performance and capacity technical case studies (SharePoint Server 2010) (in englischer Sprache)..................................................................................................................... 130

Microsoft SharePoint Server 2010-Veröffentlichungsumgebung mit Unternehmensintranet: Technische Fallstudie............................................................132

Vorabinformationen....................................................................................................132

Einführung in diese Umgebung..................................................................................133

Spezifikationen...........................................................................................................134

Arbeitsauslastung.......................................................................................................138

Dataset....................................................................................................................... 138

Integritäts- und Leistungsdaten..................................................................................139

Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (in englischer Sprache).....................................................................................142

Prerequisite information..............................................................................................142

Introduction to this environment..................................................................................143

Specifications.............................................................................................................143

Health and Performance Data....................................................................................149

Enterprise intranet collaboration environment lab study (SharePoint Server 2010) (in englischer Sprache)....................................................................................................152


Glossary..................................................................................................................... 153

Overview.....................................................................................................................154

Specifications.............................................................................................................155

Results and Analysis...................................................................................................161

Departmental collaboration environment technical case study (SharePoint Server 2010) (in englischer Sprache)...............................................................................................173



Specifications.............................................................................................................174

Workload.................................................................................................................... 180

Dataset....................................................................................................................... 180


Divisional portal environment lab study (SharePoint Server 2010) (in englischer Sprache)................................................................................................................................... 184


Glossary..................................................................................................................... 185

Overview.....................................................................................................................186

Specifications.............................................................................................................187

Results and analysis...................................................................................................193

About the authors.......................................................................................................207

Social environment technical case study (SharePoint Server 2010) (in englischer Sprache)..................................................................................................................... 208



Specifications.............................................................................................................209

Workload.................................................................................................................... 214

Dataset....................................................................................................................... 215


Ergebnisse der Leistungs- und Kapazitätstests und Empfehlungen (SharePoint Server 2010).......................................................................................................................... 219

Estimate performance and capacity requirements for Access Services in SharePoint Server 2010 (in englischer Sprache)..........................................................................222

Test farm characteristics.............................................................................................222

Test results................................................................................................................. 225

Recommendations......................................................................................................236

Troubleshooting..........................................................................................................241

Estimate performance and capacity requirements for Excel Services in SharePoint Server 2010 (in englischer Sprache)......................................................................................243


Test Results................................................................................................................246


Schätzen der Leistungs- und Kapazitätsanforderungen für PerformancePoint-Dienste 262

Testfarmmerkmale......................................................................................................262

Testszenarien und Prozesse.......................................................................................263

Hardwareeinstellungen und -topologie.......................................................................265

Testergebnisse...........................................................................................................266

Topologien mit 2M und 3M..........................................................................................268

Ergebnisse von 4M+ für die Authentifizierung über das unbeaufsichtigte Dienstkonto................................................................................................................................ 272

Ergebnisse von 4M+ für die Einzelbenutzerauthentifizierung.....................................273

Empfehlungen............................................................................................................274

Analysis Services.......................................................................................................276

Häufige Engpässe und ihre Ursachen........................................................................276

Leistungsüberwachung...............................................................................................279

Siehe auch..................................................................................................................280

Capacity requirements for Web Analytics Shared Service in SharePoint Server 2010 (in englischer Sprache)....................................................................................................281

Introduction................................................................................................................. 281

Hardware specifications and topology........................................................................284

Capacity requirements................................................................................................288

Siehe auch..................................................................................................................292

Schätzen der Leistungs- und Kapazitätsanforderungen für Web Content Management in SharePoint Server 2010.............................................................................................293

Voraussetzungen........................................................................................................294

Testdetails und Ansatz................................................................................................294

Web Content Management-Bereitstellungen..............................................................297

Optimierung................................................................................................................298

Testergebnisse und Empfehlungen............................................................................302

Informationen zu den Autoren.....................................................................................325

Estimate performance and capacity planning for workflow in SharePoint Server 2010 (in englischer Sprache)....................................................................................................326


Test results................................................................................................................. 330


Troubleshooting..........................................................................................................339

Siehe auch..................................................................................................................342

Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010).......................................................................................................................... 343

Entwurfs- und Konfigurationsprozess für die Speicher- und Datenbankschicht der SharePoint 2010-Produkte......................................................................................343

Erfassen der Speicher- und SQL Server-Kapazität und der E/A-Anforderungen........344

Auswählen der SQL Server-Version und -Edition.......................................................354

Entwerfen der Speicherarchitektur auf der Basis von Kapazität und E/A-Anforderungen................................................................................................................................ 355

Prognostizieren der Arbeitsspeicheranforderungen....................................................357

Grundlegendes zu den Anforderungen an die Netzwerktopologie..............................358

Konfigurieren von SQL Server....................................................................................358

Überprüfen von Speicherleistung und -zuverlässigkeit...............................................363

Abrufen von HilfeDas 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/bb267342Sollten Sie keine Lösung im Onlineinhalt gefunden haben, können Sie eine E-Mail-Nachricht an das Team von Microsoft Office System and Servers Content senden unter:[email protected] 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

9

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 2010-Farmen.

SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und - grenzenDieser 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)

10

http://technet.microsoft.com/library/5f5110f0-2a72-4509-97a4-6896838bed1e(Office.14).aspx

http://technet.microsoft.com/library/5f5110f0-2a72-4509-97a4-6896838bed1e(Office.14).aspx

http://technet.microsoft.com/library/d95bc95a-1ffc-41f8-8039-33a8d68810d1(Office.14).aspx

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).

11

http://technet.microsoft.com/library/bcbae7bd-656b-4003-969c-8411b81fcd77(Office.14).aspx

http://technet.microsoft.com/library/bcbae7bd-656b-4003-969c-8411b81fcd77(Office.14).aspx

http://technet.microsoft.com/library/4d88c402-24f2-449b-86a6-6e7afcfec0cd(Office.14).aspx

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

12

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 2010-Bereitstellung 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

GlossarDie folgenden Spezialbegriffe werden in der Dokumentation zur Kapazitätsverwaltung von SharePoint Server 2010 verwendet.

13

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 2010Ich 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 -

grenzen14

http://technet.microsoft.com/library/1a20e357-a21f-4409-9a99-6b8263ab30c5(Office.14).aspx

Upgraden von Office SharePoint Server 2007Ich 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-UmgebungIch 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:

15

http://technet.microsoft.com/library/7d7db565-d572-4fd3-a30c-2856d98c897c(Office.14).aspx

http://technet.microsoft.com/library/de17a1ff-79f4-4638-918b-380fb0a15205(Office.14).aspx

http://technet.microsoft.com/library/396c85d9-4b86-484e-9cc5-f6c4d725c578(Office.14).aspx

Plan for remote BLOB storage (RBS) (SharePoint Server 2010)

Vom Anfang bis zum EndeIch 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 -

grenzenWenn 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:

16



http://technet.microsoft.com/library/c1f83b4f-a507-42f7-bd82-fed5404ed1ad(Office.14).aspx


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 LeistungDie 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.

WartezeitWartezeit, 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.

17

http://technet.microsoft.com/library/71c203cd-7534-47b0-9122-657d72ff0080(Office.14).aspx

http://technet.microsoft.com/library/951de096-8d0e-4c5f-a9fc-f97fed761a6b(Office.14).aspx

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.

DurchsatzDer 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

18

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.

19

DatenvolumenDas 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

20



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ätsplanungMit der Kapazitätsverwaltung wird die Kapazitätsplanung erweitert, um einen zyklischen Ansatz zu formulieren, bei dem die Kapazität einer SharePoint Server 2010-Bereitstellung 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 System-Designer und Administratoren die Anforderungen für ihre speziellen Umgebungen kennen.

SharePoint Server 2010-Kapazitätsverwaltungsmodell

21

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.

22

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 Server-Farm 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

23

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 Leistungs- und 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 BereichBei 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.

24

Softwaregrenzwerte und -beschränkungenIn 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.

25

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 GrenzwertenIn 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 2010-Kapazitätsverwaltung: Softwarebeschränkungen und -grenzen.

Wichtige Unterschiede zwischen SharePoint Server 2010 und Office SharePoint Server 2007SharePoint 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

26



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 SharePoint-Dienstanwendungen (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-Mail-Empfä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 FeaturesDie 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.

27

http://technet.microsoft.com/library/396c85d9-4b86-484e-9cc5-f6c4d725c578(Office.14).aspx

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

ver-CPUWebserver-RAM

Anwendungsserver-CPU

Anwendungsserver-RAM

SQL Server-CPU

SQL Server-IOPS

SQL Server-Speicher

SharePoint Foundation-Dienst

XXX XXX XX XXX XXX

Zentraladministrationsdienst

XX XX X X X

Protokollierungsdienst *

XX XX XX XXX XXX

SharePoint-Suchdienst

XXX XXX XXX XXX XXX XXX XXX

Word-Anzeigedienstanwendung *

X X XXX XX

PowerPoint Services *

XX XX XXX XX

Dienste für Excel-Berechnungen

XX X XX XXX

Visio Services * X X XXX XXX X X X

Access Services * X X XXX XX X X X

Benutzerprofildienst

X XX XX XX XXX XXX XX

Verwalteter Metadatendienst *

X XX XX XX X X XX

Web Analytics-Dienst *

X X XXX XXX XXX

Business Connectivity Service *

XX XX XXX XXX

28

Dienstanwendung Webserver-CPU

Webserver-RAM

Anwendungsserver-CPU

Anwendungsserver-RAM

SQL Server-CPU

SQL Server-IOPS

SQL Server-Speicher

InfoPath Forms Services

XX XX XX XX X X X

Word Automation Services

X X XXX XX X X X

PerformancePoint-Dienstanwendung *

XX XX XXX XXX X X X

Project-Dienst * X X X X XXX XXX XX

Sandkastenlösungen *

X X XXX XXX

Workflowfunktionen *

XXX 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

29

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 FAST-Suchconnector 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 PowerPoint-Dateien 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 Excel-Arbeitsblä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).

30



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 Server-Datenbank 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 Analytics-Datenbanken 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.

31

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

32

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 2010In 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 2010-Clientanwendung

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

33

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 2010-Clients 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 2010Jede 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.

34

Integrität und Leistung Beschreibt die Leistung der Farm bezüglich der Zielvorgaben für Wartezeit und Durchsatz.

SpezifikationenHardwareBei 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.TopologieDie 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.KonfigurationDer 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.

ArbeitsauslastungDie 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.BenutzerbasisDie 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

35

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.NutzungsmerkmaleDie 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).

DatasetDas 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 LeistungDie 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.

36

ReferenzarchitekturenSharePoint 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.

EinzelserverbereitstellungDie 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 FarmbereitstellungEine 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).

37

Mittlere FarmbereitstellungBei 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 Excel-Berechnungen 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.

38

Große FarmbereitstellungBei 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.

39

Ein Dataset mit mindestens 10 Terabyte.

40

Siehe auchKonzepteKapazitätsplanung für SharePoint Server 2010Testen der Leistung für SharePoint Server 2010Überwachen und Verwalten von SharePoint Server 2010SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und -grenzenErgebnisse der Leistungs- und Kapazitätstests und Empfehlungen (SharePoint Server 2010)Performance and capacity technical case studies (SharePoint Server 2010) (in englischer Sprache)

Weitere RessourcenHardware and software requirements (SharePoint Server 2010)

41


Kapazitätsplanung für SharePoint Server 2010In diesem Artikel wird die Kapazitätsplanung für eine Microsoft SharePoint Server 2010-Farm 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 Hardware- und 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: ModellierungDie 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 DatasetsFü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.

42

In diesem Abschnitt werden bestimmte Metriken und Parameter, die Sie erfassen sollten, sowie Mechanismen zu deren Erfassung behandelt.

ArbeitsauslastungDie 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

Andere Interaktionen 43


(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 dargestellt. Anhand dieses Beispiels ist erkennbar, dass der Großteil der Auslastung

44

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).

45

Bestimmen der Produktionsarbeitsauslastung

47

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 Office-Webanwendungen im Browser, Interaktionen bei der gemeinsamen Dokumenterstellung, Synchronisierungen von SharePoint Workspace-Websites, Outlook Connector für soziale Netzwerke, RSS-Synchronisierung (in Outlook oder

48

anderen Viewern), PowerPoint-Übertragungen, freigegebene OneNote-Notizbücher, freigegebene Excel Services-Arbeitsmappen, freigegebene Access Services-Anwendungen 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 2010Zur Ermittlung wichtiger Metriken zu einer vorhandenen SharePoint Server 2010-Bereitstellung, 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 IIS-Formate.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-413c-a3f7-2e0be6d5532e&displaylang=de-de). Log Parser 2.2 kann auf der Webseite http://www.microsoft.com/downloads/details.aspx?familyid=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=de-de heruntergeladen werden.

49

http://www.microsoft.com/downloads/details.aspx?familyid=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=de-de

http://www.microsoft.com/downloads/details.aspx?familyid=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=de-de

http://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e&displaylang=de-de

http://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e&displaylang=de-de

DatasetDas 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

50

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-DatenbankWeitere Informationen zum Bestimmen der Datenbankgrößen finden Sie unter Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010).

Festlegen von Zielvorgaben für die Leistung und Zuverlässigkeit der FarmEines 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.

51

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: EntwurfNachdem 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 Vor- und 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.

52

Rolle Typ (Standard oder virtuell)

Anzahl der Server

Prozessoren

RAM

IOPS-Anforderungen

Datenträgergröße BS+Protokoll

Datenlaufwerk

Webserver Virtuell 4 4 Kerne 8 n/v 400 GB n/v

Inhaltsdatenbankserver Standard

1 Cluster

4 Quad-Core mit 2,33 GHz

48 2000 400 GB 20 300-GB-Datenträgermit 15.000 Umdrehungen pro Minute

Anwendungsserver Virtuell 4 4 Kerne 16 n/v 400 GB n/v

Suchdurchforstung-Zielwebserver

Virtuell 1 4 Kerne 8 n/v 400 GB n/v

Suchabfrageserver Standard

2 2 Quad-Core mit 2,33 GHz

32 n/v 400 GB 500 GB

Suchcrawlerserver Standard

2 2 Quad-Core mit 2,33 GHz

16 400 400 GB n/v

Server mit Suchdurchforstungsdatenbank

Standard

1 Cluster


48 4000 (optimiert für das Lesen)

100 GB 16 150-GB-Datenträger mit 15.000 Umdrehungen pro Minute

Sucheigenschaften-Informationsspeicherdatenbank + Administrationsdatenbankserver

Standard

1 Cluster


48 2000 (optimiert für das Schreiben)

100 GB 16 150-GB-Datenträger mit 15.000 Umdrehungen pro Minute

Bestimmen der AusgangsarchitekturIn diesem Abschnitt wird beschrieben, wie Sie eine Ausgangsarchitektur auswählen.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

53

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 2010Die 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/de-de/library/cc261716(Office.14).aspx) herunter.

Auswählen der HardwareDie 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. 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

54

http://technet.microsoft.com/de-de/library/cc261716(Office.14).aspx



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 HardwareauswahlAuswählen von ProzessorenSharePoint 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 SharePoint-Suchdienst 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 Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010).

Auswählen des ArbeitsspeichersIhre 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 Server-Produktionsbereitstellungen 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 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

55

http://technet.microsoft.com/de-de/library/ff607968.aspx

hohem Maß auf Arbeitsspeicher angewiesen sind, wie z. B. die Dienste für Excel-Berechnungen 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 Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010).

Auswählen von NetzwerkenNeben 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 SpeicherplatzBei 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.

56

Schritt 3: Pilot-, Test- und OptimierungsphaseDie 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.

TestenDas 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 PilotumgebungVor 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 für die erwarteten Spitzenauslastungen erfüllt. Es wird empfohlen, speziell für große

57

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.

OptimierenWenn 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: BereitstellungNachdem 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 sollte unter anderem eine Liste der erforderlichen Hardwareänderungen und ein

58

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 WartungZur 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/en-us/library/ee748639(office.14).aspx)

Siehe auchKonzepteKapazitä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

59

http://technet.microsoft.com/de-de/library/ee748639.aspx


Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010)

Weitere RessourcenHealth Monitoring (SharePoint Server 2010)

60


Testen der Leistung für SharePoint Server 2010In 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 2010-Features 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

61

Erstellen eines TestplansIhr 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 TestumgebungNachdem 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.

62

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 Roundrobin-DNS 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 Server-basierten 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

63

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 ToolsNach 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

64

http://msdn.microsoft.com/de-de/library/fda2bad5.aspx

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-81c3-c9c3d84c456e&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 dieser Werte ist in Visual Studio Team System (Team Test Load Agent) äußerst einfach.

65

http://www.microsoft.com/downloads/details.aspx?familyid=718447d8-0814-427a-81c3-c9c3d84c456e&displaylang=de-de

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 FindText-Regel 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. Durch Aktivieren der Funktion können die vom Testcontroller gemeldeten RPS-Zahlen deutlich ansteigen. Diese Anforderungen werden so schnell bereitgestellt, dass Sie

66

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 Leistung und Kapazität (http://technet.microsoft.com/de-de/library/cc261716(Office.14).aspx).

67


http://technet.microsoft.com/en-us/library/cc261716(Office.14).aspx

http://technet.microsoft.com/en-us/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 2010-basierte 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 Benutzerauslastungsmuster oder einen zielbasierten Verwendungstest zu simulieren. Ein intensiviertes Auslastungsmuster bedeutet, dass Sie mit einer niedrigeren Anzahl

68

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 auchKonzepteKapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht)Kapazitätsplanung für SharePoint Server 2010Überwachen und Verwalten von SharePoint Server 2010Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010)


69


Überwachen und Verwalten von SharePoint Server 2010Dieser 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 ÜberwachungEs 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

70




Normalbetrieb sollte die Einstellung aktiviert sein.

Zeitplan für den Zeitgeberauftrag

Import der Microsoft SharePoint Foundation-Verwendungsdaten

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.

Diagnoseanbieter

Alle Diagnoseanbieter aktivieren

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 "job-diagnostics-performance-counter-wfe-provider" und "job-diagnostics-performance-counter-sql-provider" festlegen

1 Minute 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.

Verschiedenes

Stapelablaufverfolgung für Inhaltsanforderungen aktivieren

Aktiviert Der Standardwert ist Deaktiviert. Durch Aktivieren dieser Einstellung ist die Diagnose von Inhaltsanforderungsfehlern mithilfe der Prozessstapelablaufverfolgung möglich. Bei Normalbetrieb

71


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

InhaltsimportverwendungInhaltsexportverwendungSeitenanforderungenFeatureverwendungSuchvorgangsverwendungWebsiteinventarverwendungZeitgeberaufträgeBewertungsverwendung

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.

LeistungsindikatorenWenn 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

72

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 vermehrte Cachefehler.

Arbeitsspeicher und Auslagerungsdatei Überwachen Sie die Menge des

73

Leistungsindikator Beschreibung

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.

SystemindikatorenDie 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 Lese- und 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 Datenträger-Schreibvorgänge

Die durchschnittliche Anzahl der Schreibanforderungen in der Warteschlange.

Lesevorgänge/s Die Anzahl der Lesevorgänge auf dem 74


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 unzureichendem physikalischen Speicher treten diese häufiger auf.

NIC

- Gesamtanzahl Bytes/s Dies ist die Geschwindigkeit, mit der Daten 75


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 HTML-Seiten 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. 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

76


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 Collection-Zyklus 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 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.

77

SQL Server-LeistungsindikatorenDie folgende Tabelle enthält Informationen zu SQL Server-Objekten und -Leistungsindikatoren.


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 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 der Benutzeraktivität und der Ressourcennutzung kann Ihnen helfen, Leistungsengpässe zu identifizieren.

Transaktionen/s Dieser Leistungsindikator zeigt den Umfang der Transaktionen für eine bestimmte Datenbank oder die gesamte SQL Server-Instanz 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

78


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 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.

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.

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

79


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 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ässenSystemengpä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

80

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ässePhysikalische 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.

Objekte und Indikatoren Problem Lösungsoptionen

Prozessor

Prozessor - Prozessorzeit (%)

Über 75-85% Upgrade des ProzessorsAnzahl Prozessoren erhöhenZusätzliche(n) Server hinzufügen

Datenträger


Schrittweise Zunahme, System nicht stabil und Rückstau der Warteschlange

Anzahl oder Geschwindigkeit von Datenträger erhöhenArraykonfiguration zu Stripe ändern

81


Einige Daten auf alternativen Server verschieben

Leerlaufzeit (%) Höher als 90% Anzahl Datenträger erhöhenDaten auf alternativen Datenträger oder Server verschieben

Freier Speicherplatz (%( Weniger als 30% Anzahl Datenträger erhöhenDaten 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öhenDaten auf alternativen Datenträger oder Server verschieben

Seiten/s Mehr als 10 Arbeitsspeicher hinzufügen

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

Arbeitsspeicher hinzufügen

82


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 überwachenGeschwindigkeit der Netzwerkkarte erneut überprüfenAnzahl, Größe und Verwendung von Speicherpuffern überprüfen

Prozess

Arbeitssatz Über 80% des Gesamtspeicherplatzes

Arbeitsspeicher hinzufügen

Prozessorzeit (%) Über 75-85% Anzahl Prozessoren erhöhenArbeitslast auf zusätzliche Server umverteilen

ASP.NET

Anwendungspool-Wiederverwendungen

Mehrere täglich, was zeitweise auftretende Langsamkeit zur Folge hat

Achten Sie darauf, keine Einstellungen zu implementieren, durch die der Anwendungspool im Verlauf des Tages unnötig wiederverwendet wird.

Anforderungen in Warteschlange

Hunderte oder Tausende von Anforderungen in Warteschlange.

Zusätzliche Webserver implementierenDer 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 Warteereignissen sinkt die Leistung beim Rendern von Seiten für Benutzer.

Zusätzliche Webserver implementieren

Zurückgewiesene Anforderungen

Mehr als 0 Zusätzliche Webserver implementieren

83

Siehe auchKonzepteKapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht)Testen der Leistung für SharePoint Server 2010Kapazitätsplanung für SharePoint Server 2010Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010)


84


SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und -grenzenIn 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

85

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 GrenzenDieser 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 GrenzwerteIn 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

86

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

87

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 VeranschaulichungSie 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.

88

Beschränkungen und GrenzenIn 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 HierarchieDieser Abschnitt enthält Grenzen, die nach der logischen Hierarchie einer SharePoint Server 2010-Farm geordnet sind.

WebanwendungsgrenzenDie 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

89


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

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.

Größe des Lösungscaches

300 MB pro Webanwendung

SchwellenwertDer Lösungscache ermöglicht es dem InfoPath-Formulardienst, 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 Set-SPInfoPathFormsService konfigurieren. Weitere

90


Informationen finden Sie unter Set-SPInfoPathFormsService.

Webserver- und AnwendungsservergrenzenIn der folgenden Tabelle sind die empfohlenen Richtlinien für Webserver in der Farm aufgelistet.


Anwendungspools 10 pro Webserver UnterstütztDie 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 InhaltsdatenbankenDie folgende Tabelle enthält die empfohlenen Richtlinien für Inhaltsdatenbanken.


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

91

http://technet.microsoft.com/library/ac13cd00-c372-4159-943d-98c016c7e96a(Office.14).aspx

http://technet.microsoft.com/library/ac13cd00-c372-4159-943d-98c016c7e96a(Office.14).aspx


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/A-Muster 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 empfohlen5.000 maximal

Unterstützt Es wird empfohlen, die Anzahl der Websitesammlungen in einer Inhaltsdatenbank auf 2.000 zu

92

http://technet.microsoft.com/library/9994b57f-fef8-44e7-9bf9-ca620ce20734(Office.14).aspx



http://technet.microsoft.com/library/9994b57f-fef8-44e7-9bf9-ca620ce20734(Office.14).aspx#plan_ent_typlarge




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 Upgrades und

93


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 PowerShell-Cmdlet Set-SPContentDatabase mit dem -WarningSiteCount-Parameter. Weitere Informationen finden Sie unter Set-SPContentDatabase.

Remote-BLOB-Speichersubsystem (RBS) in Network Attached Storage (NAS)

Die Zeit bis zum ersten Byte einer Antwort vom NAS darf 20 Millisekunden nicht überschreiten

BeschränkungWenn SharePoint Server 2010 für die Verwendung von RBS konfiguriert ist und die BLOBs in NAS 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 WebsitesammlungenDie folgende Tabelle enthält die empfohlenen Richtlinien für Websitesammlungen.


Website 250.000 pro Websitesammlung

UnterstütztDie empfohlene Maximalzahl von Websites und Unterwebsites liegt bei 250.000 Websites.

94

http://technet.microsoft.com/library/e1de8a07-868e-4a0d-bb5b-1f62392523f8(Office.14).aspx

http://technet.microsoft.com/library/e1de8a07-868e-4a0d-bb5b-1f62392523f8(Office.14).aspx


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ütztEine 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 PowerShell-Cmdlet 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 Move-SPSite.

95

http://technet.microsoft.com/library/e3bf1b34-78b9-4643-b0dd-24444e3cffc5(Office.14).aspx

http://technet.microsoft.com/library/e3bf1b34-78b9-4643-b0dd-24444e3cffc5(Office.14).aspx

Listen- und BibliotheksgrenzenDie 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).


Listenzeilengröße 8.000 Bytes pro Zeile

Beschränkung

Jedes Listen- bzw. Bibliothekselement kann nur insgesamt 8.000 Bytes in der 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 Beschränkung

Die maximale Dateigröße liegt 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.

Dokumente 30.000.000 pro Bibliothek

Unterstützt 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 Unterstützt 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 Liste

Unterstützt Sie können sehr große Listen erstellen, indem Sie Standardansichten, Websitehierarchien und die Metadatennavigation verwenden. Dieser Wert kann je nach Anzahl der Spalten in der Liste und der Nutzung der Liste variieren.

96


Zeilengrößengrenze

6 interne Tabellenzeilen in der Datenbank, die für ein Listen- oder ein Bibliothekselement verwendet werden

Unterstützt 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.MaxListItemRowStorage.

Massenvorgänge 100 Elemente pro Massenvorgang

Beschränkung

Die Benutzeroberfläche lässt eine Auswahl von maximal 100 Elementen für Massenvorgänge zu.

Schwellenwert für den Listenansicht-Nachschlagevorgang

8 JOIN-Operationen pro Abfrage

Schwellenwert

Gibt die maximale Anzahl von JOIN-Operationen pro Abfrage an, wie beispielsweise solchen, die auf Nachschlagespalten, Person/Gruppe-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 die Listenansicht

5.000 Schwellenwert

Gibt die maximale Anzahl von Listen- 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 Listenansicht für Auditoren und Administratoren

20.000 Schwellenwert

Gibt die maximale Anzahl von Listen- oder Bibliothekselementen an, die mit einem Datenbankvorgang (beispielsweise einer Abfrage) gleichzeitig verarbeitet werden können, wenn der Vorgang von einem Auditor

97

http://msdn.microsoft.com/de-de/library/microsoft.sharepoint.administration.spwebapplication.maxlistitemrowstorage.aspx

http://msdn.microsoft.com/de-de/library/microsoft.sharepoint.administration.spwebapplication.maxlistitemrowstorage.aspx


oder Administrator mit entsprechenden Berechtigungen ausgeführt wird. Diese Einstellung funktioniert mit Außerkraftsetzung des Objektmodells zulassen.

Unterwebsite 2.000 pro Websiteansicht

Schwellenwert

Die Leistung der Schnittstelle für das 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 Dokumenterstellung in Microsoft Word und Microsoft PowerPoint für DOCX-, PPTX- und PPSX-Dateien

10 Bearbeiter gleichzeitig pro Dokument

Schwellenwert

Die empfohlene maximale Anzahl gleichzeitiger Bearbeiter liegt bei 10. Der Höchstwert liegt bei 99.Wenn 99 Bearbeiter gleichzeitig ein Dokument zur gemeinsamen Bearbeitung geöffnet haben, wird ab dem 100. Benutzer jedem Benutzer der Fehler "Dokument wird verwendet" 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 Schwellenwert

Die maximale Anzahl eindeutiger 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 Zugriffssteuerungsliste (Access Control List, ACL), doch im Gegensatz zu NTFS-Zugriffssteuerungslisten kann ein Bereich spezifische

98


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.

SpaltengrenzenSharePoint 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 Größe

pro Spalte

Hinweise

Eine Textzeile 276 Schwellenwert28 BytesEin 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 Spalten mit einer Textzeile zu (6 x 64 = 384). Da der Grenzwert pro SharePoint-Listenelement jedoch bei 8.000

99

Grenze Maximalwert Grenztyp Größe pro Spalte

Hinweise

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 Schwellenwert28 BytesEin 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 Schwellenwert28 BytesEin 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 Schwellenwert12 BytesEin 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 Schwellenwert12 BytesEin 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 Währungsspalten zu (6 x 12 = 72).

100


Hinweise

Datum und Uhrzeit

48 Schwellenwert12 BytesEin 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).

Nachschlagen 96 Schwellenwert4 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 Schwellenwert5 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 Schwellenwert4 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 Schwellenwert56 BytesEin 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 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

101


Hinweise

integrierte SharePoint-Spalten reserviert sind, liegt die tatsächliche Grenze bei 138 Link- oder Bildspalten.

Berechnet 48 Schwellenwert28 BytesEin 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 Schwellenwert20 BytesEin 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 Schwellenwert4 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 Schwellenwert40 Bytes für die erste, 32 für jede folgende

Dem ersten verwalteten Metadatenfeld, das einer Liste hinzugefügt wird, werden vier Spalten zugewiesen: Ein Nachschlagefeld für

das eigentliche Tag Ein ausgeblendetes

Textfeld für den Zeichenfolgenwert

Ein Nachschlagefeld für den Catch-All

Ein Nachschlagefeld für den Catch-All-Überlauf

Für jedes folgende verwaltete Metadatenfeld, das einer Liste hinzugefügt wird, werden zwei

102


Hinweise

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äftsdatenkatalog-Modell 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.

SeitengrenzenDie folgende Tabelle enthält die empfohlenen Richtlinien für Seiten.


Webparts 25 pro Wiki- oder Webpartseite

SchwellenwertBei dieser Zahl handelt es sich um eine Schätzung auf der Grundlage einfacher Webparts. Wie viele Webparts auf

103


einer Seite verwendet werden können, bevor die Leistung beeinträchtigt wird, hängt von der Komplexität der Webparts ab.

Sicherheitsgrenzen Grenze Maximalwert Grenztyp Hinweise

Anzahl der SharePoint-Gruppen, zu denen ein Benutzer gehören kann

5.000 UnterstütztDies ist keine harte Grenze, entspricht aber den Active Directory-Richtlinien. Die Zahl wird von mehreren Faktoren beeinflusst: Größe des Benutzertokens 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.

Benutzer in einer Websitesammlung

2 Millionen pro Websitesammlung

UnterstütztSie können Ihrer Website Millionen von Personen hinzufügen, indem Sie die Sicherheit mithilfe von Microsoft Windows-Sicherheitsgruppen anstatt über einzelne Benutzer verwalten.

104


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 Directory-Prinzipale/Benutzer in einer SharePoint-Gruppe

5.000 pro SharePoint-Gruppe

UnterstütztIn SharePoint Server 2010 können Sie Benutzer oder Active Directory-Gruppen einer SharePoint-Gruppe hinzufügen.Eine Zahl von bis zu 5.000 Benutzern (bzw. Active Directory-Gruppen 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.

Das Rendern der Mitgliedschaft in der Ansicht. Dieser Vorgang erfordert stets Zeit.

SharePoint-Gruppen

10.000 pro Websitesammlung

UnterstütztBei mehr als 10.000 Gruppen nimmt die zum Ausführen von 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

105


Gruppenansichten.

Sicherheitsprinzipal: Größe des Sicherheitsbereichs

5.000 pro Zugriffssteuerungsliste

UnterstütztDie Größe des Bereichs wirkt sich auf die Daten aus, die für eine Sicherheitsüberprüfungsberechnung 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 FeatureIn diesem Abschnitt werden die Grenzen nach Feature aufgelistet.

SuchgrenzenDie folgende Tabelle enthält die empfohlenen Richtlinien für die Suche.


SharePoint-Suchdienstanwendungen

20 pro Farm UnterstütztIn einer Farm können mehrere SharePoint-Suchdienstanwendungen 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.

Durchforstungsdatenbanken und -datenbankelemente

10 Durchforstungsdatenbanken pro Suchdienstanwendung25 Millionen Elemente pro Durchforstungsdatenbank

Schwellenwert

Die Durchforstungsdatenbank speichert die Durchforstungsdaten (Zeit/Status usw.) zu allen Elementen, die durchforstet wurden. Der unterstützte Grenzwert liegt bei 10 Durchforstungsdatenbanken pro SharePoint-Suchdienstanwendung. Die empfohlene Grenze liegt bei 25 Millionen Elementen pro Durchforstungsdatenbank (oder insgesamt vier

106


Durchforstungsdatenbanken pro Suchdienstanwendung).

Durchforstungskomponenten

16 pro Suchdienstanwendung

Schwellenwert

Die empfohlene Grenze pro 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 Suchdienstanwendung; 128 insgesamt

Schwellenwert

Die Indexpartition beinhaltet einen Teil des Indexes der Suchdienstanwendung. Die empfohlene Grenze ist 20. Eine Erhöhung der Anzahl von Indexpartitionen führt dazu, dass jede Partition 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

107


Indexpartitionen ist auf 128 beschränkt.

Indizierte Elemente 100 Millionen pro Suchdienstanwendung; 10 Millionen pro Indexpartition

UnterstütztDie SharePoint-Suche unterstützt Indexpartitionen, von denen jede jeweils einen 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.

Durchforstungsprotokolleinträge

100 Millionen pro Suchanwendung

UnterstütztDies ist die Anzahl einzelner Protokolleinträge im Durchforstungsprotokoll. Sie richtet sich nach der Grenze für indizierte Elemente.

Eigenschaftendatenbanken

10 pro Suchdienstanwendung; 128 insgesamt

Schwellenwert

Die Eigenschaftendatenbank speichert die Metadaten für 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 Suchanwendung; 64/(Durchforstungskomponenten insgesamt) pro Server

Schwellenwert

Die Gesamtzahl der Abfragekomponenten wird durch die Fähigkeit der 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

108


Durchforstungskomponenten verteilten Dateien begrenzt.

Bereichsregeln 100 Bereichsregeln pro Bereich; 600 insgesamt pro Suchdienstanwendung

Schwellenwert

Bei Überschreiten dieser Grenze nimmt die Aktualität der Durchforstung ab, und mögliche Ergebnisse von Abfragen mit zugewiesenen Bereichen werden verzögert.

Bereiche 200 pro Website Schwellenwert

Hierbei handelt es sich um 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 Schwellenwert

Anzeigegruppen werden für 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.

Benachrichtigungen 1.000.000 pro Suchanwendung

UnterstütztHierbei handelt es sich um den getesteten Grenzwert.

Inhaltsquellen 50 pro Suchdienstanwendung

Schwellenwert

Die empfohlene Grenze von 50 kann bis zur Grenze von 500 pro Suchdienstanwendung überschritten werden. Es sollten jedoch weniger Startadressen verwendet

109


werden. Außerdem muss die Grenze für gleichzeitige Durchforstungen berücksichtigt werden.

Startadressen 100 pro Inhaltsquelle Schwellenwert

Die empfohlene Grenze kann 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.

Gleichzeitige Durchforstungen

20 pro Suchanwendung Schwellenwert

Hierbei handelt es sich um 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

UnterstütztHierbei handelt es sich um die bei einer Durchforstung entdeckten Eigenschaften.

Regel für Crawlerauswirkungen

100 Schwellenwert

Empfohlene Grenze von 100 pro Farm. Die Empfehlung kann überschritten werden, allerdings verschlechtert sich die Anzeige von Websitezugriffsregeln in der Verwaltungsoberfläche der Suche. Bei etwa 2.000 Websitezugriffsregeln wird die Seite Websitezugriffsregeln verwalten unlesbar.

Durchforstungsregeln 100 pro Suchdienstanwendung

Schwellenwert

Dieser Wert kann überschritten werden; allerdings verschlechtert sich die Anzeige von Durchforstungsregeln in der

110


Verwaltungsoberfläche der Suche.

Verwaltete Eigenschaften

100.00 pro Suchdienstanwendung

Schwellenwert

Hierbei handelt es sich um Eigenschaften, die vom Suchsystem in Abfragen verwendet werden. Durchforstete Eigenschaften werden verwalteten Eigenschaften zugeordnet.

Zuordnungen 100 pro verwaltete Eigenschaft

Schwellenwert

Das Überschreiten dieser Grenze kann zu einer Verschlechterung der Durchforstungsgeschwindigkeit und Abfrageleistung führen.

URL-Entfernungen 100 Entfernungen pro Vorgang

UnterstütztHierbei handelt es sich um die empfohlene Maximalzahl an URLs, die in einem einzigen Vorgang aus dem System entfernt werden sollten.

Autorisierende Seiten Eine Seite auf höchster Ebene und minimale Seiten auf zweiter und dritter Ebene pro Suchdienstanwendung

Schwellenwert

Die empfohlene Grenze ist eine autorisierende Seite auf höchster Ebene und möglichst wenig Seiten auf 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 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ütztDie empfohlene Grenze kann bis zur (durch ASP.NET

111


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(MaxItemsInObjectGraph) geändert werden.

Erkannte Metadateneigenschaften

10.000 pro durchforstetes Element

Beschränkung

Hierbei handelt es sich um die Anzahl von Metadateneigenschaften, die bestimmt und potenziell zugeordnet oder für Abfragen verwendet werden können, wenn ein Element durchforstet wird.

Grenzen für den BenutzerprofildienstDie folgende Tabelle enthält die empfohlenen Richtlinien für den Benutzerprofildienst.


Benutzerprofile 2.000.000 pro Dienstanwendung

UnterstütztEine Benutzerprofil-Dienstanwendung kann bis zu zwei Millionen 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 Benutzerprofil-Dienstanwendung

112


unterstützen kann, ohne dass es bei Features für soziale Netzwerke zu Leistungsverschlechterungen kommt.

Thematische Kategorien, Notizen und Bewertungen

500.000.000 pro Datenbank für Funktionen und Daten für das soziale Netzwerk

UnterstütztBis zu 500 Millionen thematische Kategorien, Notizen und Bewertungen insgesamt werden in einer Datenbank für Funktionen 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.

InhaltsbereitstellungsgrenzenDie folgende Tabelle enthält die empfohlenen Richtlinien für die Inhaltsbereitstellung.


In verschiedenen Pfaden ausgeführte Inhaltsbereitstellungsaufträge

20 UnterstütztFür gleichzeitig ausgeführte Aufträge in Pfaden, die mit Websitesammlungen in derselben Quellinhaltsdatenbank verbunden sind, besteht ein 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

113


Aufträge in einem Pfad sind nicht möglich.

Wenn Sie SQL Server-Momentaufnahmen 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.

BloggrenzenDie folgende Tabelle enthält die empfohlenen Richtlinien für Blogs.


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.

Grenzen für Business Connectivity ServicesDie folgende Tabelle enthält die empfohlenen Richtlinien für Business Connectivity Services.


Externe Inhaltstypen (im Arbeitsspeicher)

5.000 pro Webserver (pro Mandant)

Beschränkung Gesamtzahl von Definitionen für externe Inhaltstypen, die zu einem bestimmten

114

http://technet.microsoft.com/library/b44a57af-98a1-4818-aab3-a561908d0e07(Office.14).aspx#section2

http://technet.microsoft.com/library/b44a57af-98a1-4818-aab3-a561908d0e07(Office.14).aspx#section2


Zeitpunkt im Arbeitsspeicher auf einem Webserver geladen sind.

Externe Systemverbindungen

500 pro Webserver 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, .NET-Assembly 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 Maximalwert auch für Anwendungen, die den Standardwert nicht berücksichtigen.

Pro Anforderung zurückgegebene Datenbankelemente

2.000 pro Datenbankconnector

SchwellenwertDie Anzahl der Elemente pro Anforderung, die der Datenbankconnector zurückgeben kann. Der standardmäßige Maximalwert von

115


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.

WorkflowgrenzenDie folgende Tabelle enthält die empfohlenen Richtlinien für Workflows.


Schwellenwert für Workflowverschiebung

15 Schwellenwert15 ist die maximale Anzahl von Workflows, die gleichzeitig für eine 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

116


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 Set-SPFarmConfig.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 Durchsatz beim Starten und Beenden von Workflowaufgaben ebenso wie die Last für Inhaltsdatenbank und Systemressourcen.

Batchgröße des Workflowzeitgebers

100 SchwellenwertDie Anzahl der Ereignisse, die bei jeder Ausführung des Workflow-Zeitgeberauftrags aufgenommen und

117

http://technet.microsoft.com/library/fc9fd625-0df1-467a-bd31-16b7e29fbca9(Office.14).aspx

http://technet.microsoft.com/library/fc9fd625-0df1-467a-bd31-16b7e29fbca9(Office.14).aspx


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 MetadatenDie folgende Tabelle enthält die empfohlenen Richtlinien für Terminologiespeicher verwalteter Metadaten.


Maximale Anzahl der Ebenen geschachtelter Ausdrücke in einem Terminologiespeicher

7 UnterstütztAusdrücke in einem Ausdruckssatz lassen sich hierarchisch darstellen. Ein Ausdruckssatz kann bis zu sieben Ausdrucksebenen (ein übergeordneter Ausdruck mit sechs Schachtelungsebenen darunter) umfassen.

Maximale Anzahl von Ausdruckssätzen in einem Terminologiespeicher

1.000 UnterstütztEin Terminologiespeicher kann bis zu 1.000 Ausdruckssätze beinhalten.

Maximale Anzahl von Ausdrücken in einem Ausdruckssatz

30.000 Unterstützt30.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

118


Ausdrücke.

Gesamtanzahl von Elementen in einem Terminologiespeicher

1.000.000 UnterstütztEin 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 ServicesDie folgende Tabelle enthält die empfohlenen Richtlinien für Instanzen von Visio Services in Microsoft SharePoint Server 2010.


Dateigröße von Visio-Webzeichnungen

50 MB SchwellenwertVisio 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. Höhere CPU-Auslastung.

119


Weniger Anwendungsserveranforderungen pro Sekunde.

Höhere durchschnittliche Wartezeit.

Höhere SharePoint-Farmnetzwerklast.

Visio-Timeout für die Neuberechnung von Visio-Webzeichnungen

120 Sekunden SchwellenwertVisio 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 werden können.

Mehr Anforderungen pro Sekunde.

Niedrigere durchschnittliche Wartezeit für alle Dokumente.

Minimales Cachealter für Visio Services (mit Daten verbundene Diagramme)

Minimales Cachealter: 0 bis 24 Std.

SchwellenwertDas 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.

120


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 Cachealter für Visio Services (nicht mit Daten verbundene Diagramme)

Maximales Cachealter: 0 bis 24 Std.

SchwellenwertDas 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.

Grenzen für PerformancePoint ServicesDie folgende Tabelle enthält die empfohlenen Richtlinien für PerformancePoint Services in Microsoft SharePoint Server 2010.


Zellen 1.000.000 pro Abfrage an Excel Services-Datenquelle

Beschränkung Eine PerformancePoint-Scorecard, die eine Excel Services-Datenquelle aufruft, unterliegt

121


einer Grenze von höchstens 1.000.000 Zellen pro Abfrage.

Spalten und Zeilen 15 Spalten mal 60.000 Zeilen

SchwellenwertDie maximale Anzahl von Spalten und Zeilen beim Rendern eines PerformancePoint-Dashboardobjekts, das eine Microsoft Excel-Arbeitsmappe als Datenquelle verwendet. Die Anzahl der Zeilen kann sich je nach Anzahl der Spalten ändern.

Abfrage einer SharePoint-Liste

15 Spalten mal 5.000 Zeilen

Unterstützt Die maximale Anzahl von Spalten und Zeilen beim Rendern eines PerformancePoint-Dashboardobjekts, das eine SharePoint-Liste als Datenquelle verwendet. Die Anzahl der Zeilen kann sich je nach Anzahl der Spalten ändern.

Abfrage einer SQL Server -Datenquelle

15 Spalten mal 20.000 Zeilen

Unterstützt Die maximale Anzahl von Spalten und Zeilen beim Rendern eines PerformancePoint-Dashboardobjekts, das eine SQL Server-Tabelle als Datenquelle verwendet. Die Anzahl der Zeilen

122


kann sich je nach Anzahl der Spalten ändern.

Grenzen für Word Automation ServicesDie folgende Tabelle enthält die empfohlenen Richtlinien für Word Automation Services.


Größe der Eingabedatei

512 MB Beschränkung

Die maximale Dateigröße, die von Word Automation Services verarbeitet werden kann.

Häufigkeit, mit der Konvertierungen gestartet werden (Minuten)

Eine Minute (empfohlen) 15 Minuten (Standard)59 Minuten (Beschränkung)

Schwellenwert

Diese Einstellung bestimmt, wie 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 Konvertierungsprozess gestartet werden

Für PDF/XPS-Ausgabeformate: 30 x M, für alle anderen Ausgabeformate: 72 x M, wobei M der Wert der Häufigkeit ist, mit der Konvertierungen gestartet werden (Minuten)

Schwellenwert

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 Benutzerberechtigungen kommen. Benutzerberechtigungen laufen 24 Stunden nach Start eines Konvertierungsauftrags ab.

Größe des Konvertierungsauftrags

100.000 Konvertierungselemente

Unterstützt Ein Konvertierungsauftrag beinhaltet ein oder mehrere Konvertierungselemente, von denen jedes eine Konvertierung darstellt, die für eine Eingabedatei in SharePoint ausgeführt wird. Beim Starten eines Konvertierungsauftrags (mithilfe der ConversionJob.Start-Methode) werden der

123


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 Konvertierungsprozesse insgesamt

N-1, wobei N die Anzahl der Prozessorkerne auf den einzelnen Anwendungsservern ist

Schwellenwert

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.

Größe der Word Automation Services-Datenbank

Zwei Millionen Konvertierungselemente

Unterstützt Word Automation Services unterhält eine beständige Warteschlange mit Konvertierungselementen in der Datenbank. Jede Konvertierungsanforderung generiert einen oder mehrere Datensätze. 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 PowerShell-Cmdlets Remove-SPWordConversionServiceJobHistory manuell entfernen. Weitere Informationen finden Sie unter Remove-SPWordConversionServiceJobHistory.

124

http://technet.microsoft.com/library/b4ed215c-cb20-4171-9013-2cc243e106d2(Office.14).aspx



Grenzen für SharePoint WorkspaceDie folgende Tabelle enthält die empfohlenen Richtlinien für Microsoft SharePoint Workspace 2010.


SharePoint Workspace-Synchronisierung

30.000 Elemente pro Liste BeschränkungSharePoint 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 Workspace-Synchronisierung

Grenze von 1.800 Dokumenten in SharePoint Workspace

BeschränkungBenutzer werden bei mehr als 500 Dokumenten in SharePoint Workspace gewarnt, aber sie können weiter Dokumente hinzufügen.

Grenzen für OneNoteDie folgende Tabelle enthält die empfohlenen Richtlinien für Microsoft OneNote-Dienste.

125


Anzahl der Abschnitte und Abschnittsgruppen in einem OneNote-Notizbuch (in SharePoint)

Siehe Grenze für "Dokumente" unter "Listen- und Bibliotheksgrenzen"

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 Bibliotheksgrenzen"

Dieser Maximalwert schließt alle Bilder, eingebetteten Dateien und XPS-Ausdrucke 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-KB-Abschnitt gilt.

Maximale Größe eines Bildes, einer eingebetteten Datei und eines OneNote-XPS-Ausdrucks in einem OneNote-Abschnitt.

Siehe Grenze für "Dateigröße" unter "Listen- und Bibliotheksgrenzen"

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 XPS-Ausdruckdatei, und zwar auch dann, wenn der Ausdruck mehrere Seiten umfasst.

Die maximale Größe aller Bilder, eingebetteten Dateien und XPS-Ausdrucke auf einer OneNote-Seite.

Die Standardgrenze ist doppelt so hoch wie die Grenze für die Dateigröße.

Schwellenwert

Dies gilt für eingebettete Inhalte auf einer OneNote-Seite, nicht in einem Abschnitt oder Notizbuch. Benutzern wird in diesem Fall der folgende Fehler in OneNote angezeigt: "jerrcStorageUrl_HotTableFull (0xE0000794)". Benutzer können dies umgehen, indem sie eingebetteten Inhalt in verschiedene Seiten aufspalten und vorherigen Versionen der

126


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änge

Einer pro Prozessorkern pro Webserver

Beschränkung

OneNote führt Änderungen von mehreren Benutzern 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 unabhängig davon gültig, ob OneNote als Clientanwendung oder als Microsoft Office Web Apps ausgeführt wird.

Grenzen für Office-WebanwendungsdiensteDie folgende Tabelle enthält die empfohlenen Richtlinien für Office Web Apps. Office-Clientanwendungsgrenzen gelten auch, wenn eine Anwendung als Webanwendung ausgeführt wird.


Cachegröße 100 GB SchwellenwertVerfügbarer Speicher zum Rendern von

127


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 ServerDie 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.


Ende der Projektzeit Datum: 31.12.2049 BeschränkungProject-Pläne können nicht über das Datum 31.12.2049 hinausgehen.

Lieferumfang pro Projektplan 1.500 Lieferumfänge BeschränkungProject-Pläne können nicht mehr als 1.500 Lieferumfänge

128

http://technet.microsoft.com/library/a0ada5d4-fc5f-4334-b5cc-44b7fb069b90(Office.14).aspx

http://technet.microsoft.com/library/a0ada5d4-fc5f-4334-b5cc-44b7fb069b90(Office.14).aspx


enthalten.

Anzahl der Felder in einer Ansicht

256 BeschränkungBenutzer können einer Ansicht, die sie in Project Web App definiert haben, nicht mehr als 256 Felder hinzufügen.

Anzahl der Klauseln in einem Ansichtsfilter

50 BeschränkungEin Benutzer kann einer Ansicht keinen Filter mit mehr als 50 Klauseln hinzufügen.

129

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 FallstudieDescribes 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)

130

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.

131

http://technet.microsoft.com/library/7b39606d-57b3-47bc-90ac-7739a67e6577(Office.14).aspx

Microsoft SharePoint Server 2010-Veröffentlichungsumgebung mit Unternehmensintranet: Technische FallstudieIn 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

VorabinformationenVor 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

132

Einführung in diese UmgebungIn diesem Whitepaper wird eine SharePoint Server 2010-Umgebung bei Microsoft beschrieben. Vergleichen Sie anhand dieses Dokuments Ihre geplanten Auslastungs- und 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 SharePoint-Umgebungen 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.

133

SpezifikationenDieser Abschnitt enthält ausführliche Informationen zur Hardware, Software, Topologie und Konfiguration der Umgebung für die Fallstudie.

HardwareDieser 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).

WebserverEs 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 ZentraladministrationEingehende E-Mails von Microsoft SharePoint FoundationMicrosoft SharePoint Foundation-Webanwendung

134

Webserver WFE1-4

Microsoft SharePoint Foundation-WorkflowtimerdienstSuchabfrage- und WebsiteeinstellungsdienstSharePoint Server-Suche

Von einer Verbunddienstfarm genutzte Dienste

BenutzerprofildienstWeb Analytics-WebdienstBusiness Data Connectivity-DienstVerwalteter Metadatenwebdienst

AnwendungsserverIn der Farm sind keine Anwendungsserver vorhanden. Lokale Dienste werden auf den Webservern gehostet. Andere Dienste werden von einer Verbunddienstfarm genutzt.

DatenbankserverEs 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 TBDatenträger 1-4: SQL-DatenDatenträger 5: ProtokolleDatenträger 6: TempDB

Anzahl der Netzwerkkarten 2

Geschwindigkeit der Netzwerkkarte 1 Gigabit

Authentifizierung Windows NTLM

Softwareversion SQL Server 2008

TopologieDas folgende Diagramm veranschaulicht die Topologie für diese Farm.

135

Konfiguration

136

In der folgenden Tabelle sind geänderte Einstellungen aufgeführt, die sich auf die Leistung oder Kapazität in der Umgebung auswirken.


Websitesammlungsverwaltung:Ausgabecache der Websitesammlung

Ein 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)

Intranet (Website für die Zusammenarbeit)

Schreibern erlauben, zwischengespeicherten Inhalt anzuzeigen ist aktiviert, wodurch das Standardverhalten außer Kraft gesetzt wird, dass Seiten von Benutzern mit 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 Front-End-Webservers gespeichert werden.

Verwendungsdienst:Ablaufverfolgungsprotokoll – Anzahl der Tage, die Protokolldateien gespeichert werden (Standard: 14 Tage)

5 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 Abfrageprotokollierung:Microsoft SharePoint Foundation-Datenbank – 1 Sekunde für "QueryLoggingThreshold" konfigurieren

1 Sekunde 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

1 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=189030&clcid=0x407).

137



ArbeitsauslastungIn diesem Abschnitt wird die Arbeitsauslastung beschrieben, also die Anforderungen an die Farm, einschließlich der Anzahl von Benutzern und der Nutzungsmerkmale.


Durchschn. Anforderungen pro Sekunde 100

Durchschn. Anforderungen pro Sekunde zu Spitzenzeiten (11–15 Uhr)

226

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 %

DatasetIn 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

Anzahl der Inhaltsdatenbanken 3

138

Datasetmerkmale Wert

Anzahl der Webanwendungen 3

Anzahl der Websitesammlungen 4

Anzahl der Websites 797

Suchindexgröße (Anzahl der Elemente) 275.000

Integritäts- und LeistungsdatenDieser 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.

139

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

140

innerhalb der Reaktionszeit ausgeführt werden und demnach bei 5 % der Anforderungen langsamere Reaktionszeiten auftreten.

Datenbank-LeistungsindikatorenAchten 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 pro Datenbank)

99,999 : 0,001

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 %

141

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 informationBefore 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

142

Introduction to this environmentThis 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.

SpecificationsThis section provides detailed information about the hardware, software, topology, and configuration of the case study environment.

Hardware

143

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 ServersThere 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

144

Web Server WFE1-4

Services consumed from a federated Services farm

User Profile ServiceWeb Analytics Web ServiceBusiness Data Connectivity ServiceManaged Metadata Web Service

Application ServerThere 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







Services running locally Office Web AppsExcelPowerPointSecure StoreUsage and HealthState Service

Database ServersThere 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


RAM 32 GB

OS Windows Server 2008, 64-bit145


Storage and geometry (1.25 TB * 7) + 3 TBDisk 1-4: SQL Data Disk 5: Logs Disk 6: TempDB




Software version SQL Server 2008

TopologyThe following diagram shows the topology for this farm.

146

Configuration

147

The following table enumerates settings that were changed that affect performance or capacity in the environment.

Setting Value Notes

Usage ServiceTrace 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.

QueryLoggingThresholdSharePoint Foundation Database – change QueryLoggingThreshold to 1 second

1 second

The default is 5 seconds. Lowering this setting can save bandwidth and CPU on the database server.

Database Server – Default InstanceMax degree of parallelism

1 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).

WorkloadThis 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%

148

http://go.microsoft.com/fwlink/?LinkId=189030


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%

DatasetThis 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 DataThis 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%

ASP.NET Requests Queued 0.00149

Metric Value

The following charts show the average CPU utilization and latency for this environment:

In this document, latency is divided into four categories. The 50th percentile latency is 150

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%

151

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 environmentThis 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

152

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 -

grenzenAlso, we encourage you to read the following: Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server

2010)

GlossaryThere 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:153

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.

OverviewThis 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 approachThis 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 environmentThe 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,

154

http://msdn.microsoft.com/en-us/library/ms179316.aspx


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 NotesThis 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).

SpecificationsThis section provides detailed information about the hardware, software, topology, and configuration of the lab environment.

HardwareThe following sections describe the hardware that was used in this lab environment.

Web and Application serversThere 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





155

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 ServersThere 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 diskExternal Array with 15 x 450GB 15krpm disk6 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)


Database Server – Default Instance DB1-2



Software version SQL Server 2008 R2 (pre-release version)

TopologyThe following diagram shows the topology in this lab environment:

157

Configuration

158

To allow for the optimal performance, the following configuration changes were made in this lab environment.

Setting Value Notes

Site Collection

Blob Caching 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.

Database Server – Default Instance

Max degree of parallelism

1 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).

WorkloadThe 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.

159




DatasetThe 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).


Database size (combined) 130 GB

BLOB size 108.3 GB


Number of site collections 181


160


Number of sites 1384

Results and AnalysisThe following results are ordered based on the scaling approach described in the Overview section of this document.

Web Server Scale OutThis 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.

AnalysisIn 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 chartsIn 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 RPSThe following graph shows how scaling out (adding Web servers) affects latency and RPS.

161

2. Processor utilizationThe following graph shows how scaling out the Web servers affects processor utilization on the Web server(s) and the database server.

162

3. SQL Server I/O operations per section (IOPs) for MDF and LDF filesThe 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 / secIn 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:

163

Green Zone:

Example of how to read these graphs:

164

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 OutThis 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 chartsIn 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 RPSThe following graph shows how scaling out both Web servers and database servers affects latency and RPS.

165

2. Processor utilizationThe following graphs show how scaling out affects processor utilization.

166

3. Memory utilization at scale outThroughout 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 filesThe 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

167

Green Zone RPS

Web server Scale UpThis section describes the test results that were obtained when we scaled up the Web servers in this lab environment.

168

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 chartsIn 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 2007This section provides information about how the capacity testing for this workload varied between SharePoint Server 2010 and Microsoft Office SharePoint Server 2007.

WorkloadTo 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

169

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.

170

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 chartsThe following graph shows the throughput without scaling out Web servers.

The following graph shows the throughput when Web servers were at maximum scale out.

171

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 environmentIn this article: Prerequisite information Introduction to this environment Specifications Workload Dataset Health and Performance Data

Prerequisite informationBefore 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 environmentThis white paper describes an actual SharePoint Server 2010 environment at Microsoft. Use this document to compare with your planned workload and usage characteristics. If

173

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 environmentThis 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.

SpecificationsThis section provides detailed information about the hardware, software, topology, and configuration of the case-study environment.

HardwareThis section provides details about the server computers that were used in this environment.

174

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 ServersThere 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


SharePoint Server 2010 (pre-release version)

Services running locally Search Query WFE3 – No services

175

Web Server WFE1-2 WFE3-4

WFE4 – Search crawl target

Application ServerThere are four application servers in the farm.

Web Server APP1-3 APP4


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


Network adapter speed 1 Gigabit 1 Gigabit


Load balancer type Hardware load balancing Hardware load balancing


SharePoint Server 2010 (pre-release version)

Services running locally APP1 – Central Administration and all applications except for Office Web ApplicationsAPP2 – All applications (including Office Web Applications)APP3 – Office Web Applications

Search Crawler

Database Servers

176

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


2 quad core @ 3.2 GHz

RAM 32 GB 16 GB 32 GB

Operating system Windows Server 2008 SP1, 64 bit

Windows Server 2008 SP1, 64 bit

Windows Server 2008 SP1, 64 bit

Storage and geometry 5x146GB 15K SAS + SANDisk 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 15KDisk 4: Direct Attached Storage (16 disk RAID 10, Temp DB data) SAS 146 GB 15KDisk 5-15: SAN using fiber connection. When possible, one database per two disks. Separating logs and data between LUNs. 15K drives.

6x450GB 15K SASDirectly attached 14x146GB 15K SASDisk 1: Usage logs and OSDisk 2: Usage data

2x136GB 15K SAS (RAID 0)6x60GB SSD, SATA (RAID 5)Disk 1: OSDisk 2: Swap and BLOB CacheDisk 3: Logs and Temp directory. Solid state drives. 6-60GB Solid state drives (RAID 5)

Number of network adapters 2 2 2

Network adapter speed 1 Gigabit 1 Gigabit 1 Gigabit


Windows NTLM

Software version SQL Server 2008 SQL Server 2008

SQL Server 2008 R2


177

Configuration

178

The following table enumerates settings that were made that affect performance or capacity in the environment.

Setting Value Notes

Site collection:Object Caching (On | Off)Anonymous Cache Profile (select)Anonymous Cache Profile (select)Object Cache (Off | n MB)Cross List Query Cache Changes (Every Time | Every n seconds)

OnDisabledDisabledOn – 100GB60 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 front-end Web server memory.

Usage Service:Trace Log – days to store log files (default: 14 days)


Query Logging Threshold:Microsoft SharePoint Foundation Database – configure QueryLoggingThreshold to 1 second

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

1 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).

179







Total number of unique users per day 9186


Maximum concurrent users 322



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%


180



BLOB size 1.68 TB


Total number of databases 36




Search index size (number of items) 4.6 million

Health and Performance DataThis section provides health and performance data that is specific to the case study environment.

General Counters Metric Value


Failure Rate 0.0005%




82.5%

The following charts show the average CPU utilization and latency for this environment:

181

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

182

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


Disk Queue Length: Reads 1.38






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%

183

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 environmentThis 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

184

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 -

grenzenAlso, we encourage you to read the following: Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server

2010)

GlossaryThere 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%. 185

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.

OverviewThis section provides an overview to our assumptions and our test methodology.

AssumptionsFor 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 methodologyWe 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.

186



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.

SpecificationsThis section provides detailed information about the hardware, software, topology, and configuration of the lab environment.

HardwareThe 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

ServerDatabase Server

Processor(s) [email protected] [email protected]@ 3.19GHz

RAM 8 GB 8 GB 32 GB

Number of network adapters2 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 Medium Not applicable

SoftwareThe table that follows explains software installed and running on the servers that were used in this testing effort.

Web Server Application

ServerDatabase Server

Operating System Windows Server 2008 R2 x64 Windows Server 2008 R2 x64

Windows Server 2008 x64

Software version SharePoint Server 2010 and SharePoint SQL Server

187

Web Server Application Server

Database Server

Office Web Applications, pre-release versions

Server 2010 and Office Web Applications, pre-release versions

2008 R2 CTP3


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 Administration Excel ServicesManaged Metadata Web ServiceMicrosoft SharePoint Foundation Incoming E-Mail Microsoft SharePoint Foundation Web Application Microsoft SharePoint Foundation Workflow Timer Service PowerPoint ServicesSearch Query and Site Settings Service SharePoint

Not applicable

188

Web Server Application Server

Database Server

Server SearchVisio Graphics ServicesWord 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 configurationThe 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.

189

Dataset and disk geometry

190

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 GB

1.2 terabytes

75 GB

Number of sites 44 74 9 9 222

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

Transactional mixThe 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%

Microsoft InfoPath Display/Edit upsize list item and new forms

r 0.32%

Download file by using "Save as"

r 1.39%

Microsoft OneNote 2010 Open Microsoft Office OneNote 2007 file

r 13.04%

191

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, scroll to 6 slides

r 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 page)

r 1.70%

Browse to Upload doc to doc lib w 0.05%

Browse to List/Library's default view

r 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 using DAV

w 3.32%

Propfind list by using DAV r 4.16%

Propfind site by using DAV r 4.16%

List document by using FPSE r 0.91%192

Feature or Service Operation Read/write Percentage of mix

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 r 1.56%

Workspaces WXP - Cobalt internal protocol r 23.00%

Full file upload using WXP w 0.57%

Results and analysisThis section describes the test methodology and results to provide guidance for capacity planning of a typical divisional portal.

Results from 1x1 farm configurationSummary 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 graphsThe following table presents various performance counters captured during testing a 1x1 farm at different steps in user load.

User Load 50 75 100 125

RPS 74.958 89.001 95.79 101.37

Latency 0.42 0.66 0.81 0.81

Web server CPU 79.6 80.1 89.9 86

193

User Load 50 75 100 125

Application server CPU N/A 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.

194

Results from 1x1x1 farm configurationSummary 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 graphsThe following table presents various performance counters captured during testing a 1x1x1 farm, at different steps in user load.

195

User Load 25 50 75 100 125 150

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.

196

Results from 2x1x1 farm configurationSummary 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 graphsThe following table presents various performance counters captured during testing a 2x1x1 farm, at different steps in user load.

197

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 45 45.9

Database server CPU 21.2 36.1 43.7 48.5 52.8 56.2



The following chart shows RPS and latency results for a 2x1x1 configuration.

The following chart shows performance counter data in a 2x1x1 configuration.

198

Results from 3x1x1 farm configurationSummary 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 graphsThe following table presents various performance counters captured during testing a 3x1x1 farm, at different steps in user load.

User Load 66 103 141 17 202 226

RPS 193.8 218.5 269.8 275.5 318.25 310

199

User Load 66 103 141 17 202 226

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



The following chart shows RPS and latency results in a 3x1x1 configuration.

The following chart shows performance counter data for a 3x1x1 configuration.

200

ComparisonFrom 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.

201

The following chart shows a summary of latency at different configurations.

202

A note on disk I/ODisk 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.

203

Tests with Search incremental crawlAs 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

Incremental Crawl

No Resource Governor

10% Resource 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

204

Baseline 3x1x1 Only Incremental Crawl

No Resource Governor

10% Resource Governor

(%)

Web server CPU (%) 53.40 0.30 47.00 46.5

Application server CPU (%)22.10 28.60 48.00 41.3

Crawl Web server CPU (%) 0.50 16.50 15.00 12.1

The following chart shows results from tests with incremental Search crawl turned on.

205

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 recommendationsTo 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 deploymentIn 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 (that

206

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 authorsGaurav 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.

207

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 environmentIn this article: Prerequisite information Introduction to this environment Specifications Workload Dataset Health and Performance Data

Prerequisite informationBefore 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 environmentThis white paper describes an actual SharePoint Server 2010 environment at Microsoft. Use this document to compare with your planned workload and usage characteristics. If

208

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 environmentThis 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.

SpecificationsThis section provides detailed information about the hardware, software, topology, and configuration of the case-study environment.

Hardware

209

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 ServersThere 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


RAM 16 GB

Operating system Windows Server 2008, 64 bit







Services running locally Central AdministrationMicrosoft SharePoint Foundation Incoming E-MailMicrosoft SharePoint Foundation Web ApplicationMicrosoft SharePoint Foundation Workflow Timer ServiceSearch Query and Site Settings ServiceSharePoint Server Search

210

Web Server WFE1-3

Services consumed from a federated services farm

User Profile ServiceWeb Analytics Web ServiceBusiness Data Connectivity ServiceManaged Metadata Web Service

Application ServerThere are two application servers in the farm, each with identical hardware.

Application Server APP1-4


RAM 16 GB

OS Windows Server 2008, 64 bit







Services running locally Office Web AppsExcelPowerPointSecure StoreUsage and HealthState Service

Database ServersThere 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.



RAM 64 GB

Operating system Windows Server 2008, 64 bit211


Storage and geometry (1.25 TB * 6)Disk 1-4: SQL DataDisk 5: LogsDisk 6: TempDB


Network adapter speed 1 @ 100MB, 1 @ 1GB




212

Configuration

213

The following table enumerates settings that were changed that affect performance or capacity in the environment.

Setting Value Notes

Usage Service:Trace Log – days to store log files (default: 14 days)


QueryLoggingThresholdMicrosoft SharePoint Foundation Database – configure QueryLoggingThreshold to 1 second

1 second

The default is 5 seconds. Lowering this setting can save bandwidth and CPU on the database server.

Database Server – Default InstanceMax degree of parallelism

1 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).





Total number of unique users per day 69,814


Maximum concurrent users 1186



214



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%




BLOB size 1.05 TB





Search index size (number of items) 5.5 million

Health and Performance DataThis section provides health and performance data that is specific to the case study environment.

General Counters

215

Metric Value


Failure Rate 0.39%




17.42%

The following charts show average CPU utilization and latency for this environment.

216

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

217

Metric Value

Read/Write Ratio (IO Per Database) 99.854 : 0.146


Disk Queue Length: Reads 30.518






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%

218

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 Leistungs- und Kapazitätstests und Empfehlungen für SharePoint Server 2010 als Microsoft Word-Dokument 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).

219

http://www.microsoft.com/downloads/details.aspx?familyid=fd1eac86-ad47-4865-9378-80040d08ac55&displaylang=de-de



Thema Beschreibung

Übersicht über Caches Enthält Informationen, wie die drei SharePoint Server 2010-Caches zur Umsatzsteigerung und damit zur Erfüllung Ihrer unternehmerischen Anforderungen beitragen. Laden Sie dieses Whitepaper herunter (SharePointServerCachesPerformance.docx).

Excel Services in Microsoft SharePoint Server 2010

Enthält Anweisungen zur Planung von Excel Services in 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 großer Farmen. Laden Sie dieses Whitepaper herunter

220












Thema Beschreibung

(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).

221







http://technet.microsoft.com/library/2cabee64-40e0-4a49-a915-bd739074fd26(Office.14).aspx

http://technet.microsoft.com/library/2cabee64-40e0-4a49-a915-bd739074fd26(Office.14).aspx

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 characteristicsThis 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.

DatasetAccess 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.

222

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).

WorkloadTo 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 reportsEach 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 definitionsFor 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.

223

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 varyThe 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 topologyLab HardwareTo 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)

TopologyFrom 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

224

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 computersThe 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 resultsThe 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 scaleThe 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

225

Topology Baseline solution maximum (RPS) Baseline recommended (RPS)

2x4 116 58

226

Recommended resultsThe following graph shows the results for recommended sustainable throughput.

227

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.

228

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.

229

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.

MaximumThe 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.

230

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.

231

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.

232

Detailed resultsThe following tables show the detailed results for the recommended configurations.

Overall 1x1 1x2 1x3 1x4 2x1 2x2 2x4

Req/Sec 14.96 28.76 45.22 48.01 14.85 28.77 58.02

Tests/Sec 2.00 3.81 6.11 6.42 1.99 3.81 7.80

Average Latency 235.80 241.21 247.21 244.87 240.70 242.26 250.94

Average front-end Web server tier

1x1 1x2 1x3 1x4 2x1 2x2 2x4

%CPU 13.82 24.40 41.02 43.62 6.31 12.48 26.18

233


1x1 1x2 1x3 1x4 2x1 2x2 2x4

Max w3wp Private Bytes

9.46E+08 2.31E+081.49E+09 1.55E+09 8.43E+08 9.84E+081.19E+09

Average application server (Access Data Services) tier

1x1 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 8.62 7.94 9.17 6.84 9.03 8.02 8.71

Max total Private Bytes

4.80E+09 4.89E+094.91E+09 4.62E+09 5.32E+09 4.82E+095.07E+09


2.10E+09 1.97E+092.04E+09 1.86E+09 2.00E+09 2.00E+092.07E+09

Max RS Private Bytes

1.78E+09 2.00E+091.97E+09 1.86E+09 2.30E+09 1.89E+092.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+103.25E+10 3.25E+10 2.89E+10 3.22E+103.25E+10

Max Private Bytes

3.26E+10 3.25E+103.25E+10 3.25E+10 3.25E+10 3.25E+103.25E+10

Avg Disk Queue Length Total

0.74 1.18 1.64 1.77 0.67 1.24 2.18

The following tables show the detailed results for the maximum configurations.

234

Overall 1x1 1x2 1x3 1x4 2x1 2x2 2x4

Req/Sec 14.96 28.76 45.22 48.01 14.85 28.77 58.02

Tests/Sec 2.00 3.81 6.11 6.42 1.99 3.81 7.80

Average Latency 235.80 241.21 247.21 244.87 240.70 242.26 250.94


1x1 1x2 1x3 1x4 2x1 2x2 2x4

%CPU 13.82 24.40 41.02 43.62 6.31 12.48 26.18


9.46E+08 2.31E+081.49E+09 1.55E+09 8.43E+08 9.84E+081.19E+09

Average application server (Access Data Services) tier

1x1 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 8.62 7.94 9.17 6.84 9.03 8.02 8.71

Max total Private Bytes

4.80E+09 4.89E+094.91E+09 4.62E+09 5.32E+09 4.82E+095.07E+09


2.10E+09 1.97E+092.04E+09 1.86E+09 2.00E+09 2.00E+092.07E+09

Max RS Private Bytes

1.78E+09 2.00E+091.97E+09 1.86E+09 2.30E+09 1.89E+092.02E+09


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+103.25E+10 3.25E+10 2.89E+10 3.22E+103.25E+10

235


1x1 1x2 1x3 1x4 2x1 2x2 2x4

Max Private Bytes

3.26E+10 3.25E+103.25E+10 3.25E+10 3.25E+10 3.25E+103.25E+10

Avg Disk Queue Length Total

0.74 1.18 1.64 1.77 0.67 1.24 2.18

RecommendationsThis 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 recommendationsAccess 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 topologiesTo 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.

236

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 settingsOne 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 TableSecond, the resulting size of a query can be limited: Maximum Columns per Query Maximum Rows per Query Allow Outer JoinsIn 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 QueryObviously, 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

OptimizationsCommon bottlenecks and their causesDuring 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 monitoring237

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 serversThe 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 ServicesThe 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.



% Processor Time Process(w3wp) The Access Data Services runs within its own

238


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) Watch for too much disk writing because of logging.

% 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) 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.

Private Bytes Process(ReportingSrevicesService)Reports are handled by SQL Server Reporting

239


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 serversThe following table shows performance counters and processes to monitor for database servers in your farm.



% 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 instance of SQL

240


Server is becoming overloaded, and that possibly additional disk spindles would help distribute the load.

TroubleshootingThe following table lists some common bottlenecks and describes their causes and possible resolutions.

Bottleneck Cause Resolution

Access Data Services CPU

Access Services depends on a large amount of processing in the 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.

Increase the number of CPUs or cores, or both, in the existing Access Data Services computers. Add additional Access Data Services computers if possible.

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 more Web servers to the farm to distribute user load, or you can scale up the Web server or servers by adding higher-speed processors.

Database server disk I/O

When the number of I/O requests to a hard disk exceeds

Distributing data files across multiple physical drives allows for parallel I/O. The blog SharePoint Disk Allocation and Disk I/O 241



the disk’s I/O capacity, the requests will be queued. As a result, the time to complete each request increases.

(http://go.microsoft.com/fwlink/?LinkId=129557) contains useful information about resolving disk I/O issues.

Reporting Services CPU utilization

The Reporting 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).

242

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 characteristicsThis section describes the dataset, workloads, hardware settings, topology, and test definitions that were used during the performance and capacity testing of Excel Services.

DatasetExcel 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:

243

Workbook Characteristics Small Large Very

Large

Sheets 1-3 1-5 1-20

Columns 10-20 10-500 10-1,000

Rows 10-40 10-10,000 100-30,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.

WorkloadTo 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.

244

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 definitionsFor 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 Excel-Berechnungen 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 TopologyThis section describes the kinds of computer hardware we used in our lab and the farm configuration topologies that we used in our tests.

Lab HardwareSeveral 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

245

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 4 proc/4 core 2.6 GHz Intel Xeon16 GB 1 gig

TopologyOur 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 front-end 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 ResultsThe 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 ScaleThe 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.

246

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

247

Recommended ResultsThe following chart shows our results for recommended sustainable throughput.

248

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

249

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 front-end 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 ResultsThe following chart shows our results for maximum peak throughput.

250

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.

251

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 ResultsThis section shows details for the recommended and maximum results obtained in our tests.

Recommended ResultsThe following tables show the recommended results of our tests.

252

Overall 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3

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

Web Front-end Tier 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3

% CPU (average over all Web Front-end computers

33.73 37.64 33.84 14.61 23.95 36.90 7.54 13.12 21.75

Dienste für Excel-Berechnungen Tier

1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3

% CPU (average over all Dienste für Excel-Berechnungen computers)

30.56 34.55 31.67 26.03 45.94 68.37 20.71 38.82 63.70

Peak Private Bytes (maximum over all Dienste für Excel-Berechnungen computers)

5.94E+09

5.82E+09

5.79E+09

5.87E+09

6.09E+09

5.92E+09

5.79E+09

5.91E+09

5.85E+09

Maximum ResultsThe following tables show the maximum results of our tests.

253

Overall 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3

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 1x3 2x1 2x2 2x3 3x1 3x2 3x3

% CPU (average over all Web Front-end computers

41.08 67.78 58.59 19.44 34.11 45.97 10.19 17.79 28.69

Dienste für Excel-Berechnungen Tier

1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3

% CPU (average over all Dienste für Excel-Berechnungen computers)

24.99 18…44 10.96 23.57 20.56 17.77 18.97 17.04 18.10

Peak Private Bytes (maximum over all Dienste für Excel-Berechnungen computers)

5.91E+09

5.85E+09

5.91E+09

5.88E+09

5.99E+09

6.502E+09

5.94E+09

5.94E+09

6.04E+09

Scale Up Test resultsWe also measured the effect of adding CPUs and memory to the Dienste für Excel-Berechnungen tier. For these tests, a 1x1 topology was used.

254

Our results in the previous chart show that adding additional CPUs was helpful but did not significantly affect the overall throughput.

255

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.

RecommendationsThis 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.

256

Hardware RecommendationsExcel 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 Excel-Berechnungen 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 SettingsOne 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 Excel-Berechnungen. 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.

257

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 SizeBy 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 Excel-Berechnungen 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 causesDuring 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


Dienste für Excel-Berechnungen Memory

Excel Services holds each workbook in memory throughout

Scale Up with more memory in

258


the user's session. A large number of workbooks, or large workbooks, can cause Dienste für Excel-Berechnungen to consume all available memory causing the actually consumed "Private Bytes" to exceed "Maximum Private Bytes."

the Dienste für Excel-Berechnungen tier computers, or Scale Out with the addition of more Dienste für Excel-Berechnungen 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 Excel-Berechnungen computers, or add Dienste für Excel-Berechnungen 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 monitoringTo 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

259

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.


% Processor Time Processor (_Total) Shows the percentage of elapsed time that all threads on the server that used the processor to execute

260


instructions.

% Processor Time Processor (w3wp) The Dienste für Excel-Berechnungen 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 Excel-Berechnungen, memory consumption for the Dienste für Excel-Berechnungen w3wp will increase.

SQL ServerAs 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.

261

Schätzen der Leistungs- und Kapazitätsanforderungen für PerformancePoint-DiensteIn 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).

TestfarmmerkmaleDatasetDas 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.

262

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 ProzesseIn 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 zufälliges Ändern eines der beiden Filter mit einer Pause von 15 Sekunden zwischen Interaktionen.

1. Rendern des Dashboards.2. Auswählen eines der beiden Filter und

zufälliges Auswählen eines Filterwerts 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 eines Diagramms und fünfmaliges Erweitern und Reduzieren mit einer Pause von 15 Sekunden zwischen Interaktionen.

1. Rendern des Dashboards. 2. Auswählen eines zufälligen Elements in

einem Diagramm und dieses erweitern.3. Auswählen eines anderen zufälligen

Elements im Diagramm und dieses

263

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 zufälliges Ändern eines der beiden Filter.

80%

Rendern eines Dashboards, Auswählen eines Diagramms und fünfmaliges Erweitern sowie Reduzieren.

10%

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

264

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 -topologieLaborhardwareUm 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,

auf dem SQL Server ausgeführt wird

Computer, auf dem Analysis Services ausgeführt wird

Prozessor(en) 2px4c @ 2,66 GHz 2px4c @ 2,66 GHz2px4c @ 2,66 GHz

4px6c @ 2,4 GHz

RAM 16 GB 32 GB 16 GB 64 GB

Betriebssystem Windows Server 2008 R2 Enterprise

Windows Server 2008 R2 Enterprise



NIC 1x1 Gigabit 1x1 Gigabit 1x1 1x1

265

Webserver Anwendungsserver Computer, auf dem SQL Server ausgeführt wird

Computer, auf dem Analysis Services ausgeführt wird

Gigabit Gigabit

Authentifizierung NTLM und Kerberos NTLM und Kerberos

NTLM und Kerberos

NTLM und Kerberos

Nach dem Skalieren der Farm auf mehrere Webserver wurde ein Hardware-Lastenausgleichsmodul 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.TopologieDie 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.

TestergebnisseDie 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 (RPS)

Gesamtanzahl der von Visual Studio gemeldeten 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 beliebige Webanforderung der Renderingdienst-URL, die

266

Measure Beschreibung

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

267



Topologie (WFExAPPxSQL) Benutzer Anforderungen pro Sekunde (RPS)


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

pro Sekunde (RPS)


2M (1x0x1) 200 47 27

3M (1x1x1) 240 56 33

4M (1x2x1) 300 67 40

5M (1x3x1) 325 74 44

Topologien mit 2M und 3MZur 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 360

Durchschnittl. WFE/APP-CPU 19,20% 57,70% 94,00% 96,70%

Anforderungen pro Sekunde 18 53 83 83

Ansichten pro Sekunde 10,73 31,72 49,27 49,67

Durchschnittl. Antwortzeit (s) 0,12 0,15 0,38 2

268

Einzelbenutzerauthentifizierung Benutzeranzahl 50 100 150 200

Durchschnittl. WFE/APP-CPU 30,80% 61,30% 86,50% 93,30%


Ansichten pro Sekunde 10,3 19,32 26,04 27,75


269

Ergebnisse 3M-Farm (1x1x1)Authentifizierung über das unbeaufsichtigte Dienstkonto Benutzeranzahl 100 250 400 540


Ansichten pro Sekunde 21 52 74 75


Durchschnittl. WFE-CPU 11% 28% 43% 46%

Max. private Bytes des WFE vom SharePoint Server-W3WP-Arbeitsprozess mit Internetinformationsdiensten (Internet Information Services, IIS).

0,7 GB 1,4 GB 2,0 GB

2,4 GB

Durchschnittl. APP-CPU 25% 62% 94% 95%

Max. private Bytes des APP 5,9 GB 10,8 GB 14,1 14,6

270

Benutzeranzahl 100 250 400 540

vom PerformancePoint Services-W3WP-Arbeitsprozess

GB GB

Einzelbenutzerauthentifizierung Benutzeranzahl 50 120 180 240





Max. private Bytes des WFE vom SharePoint Server-W3WP-Arbeitsprozess

0,78 GB 1,3 GB 1,6 GB

1,9 GB


271


Max. private Bytes des APP vom PerformancePoint Services-W3WP-Arbeitsprozess

19 GB 20,1 GB 20,5 GB

20,9 GB

Ergebnisse von 4M+ für die Authentifizierung über das unbeaufsichtigte DienstkontoBeginnend 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.

272

4M (1x2x1) 5M (1x3x1) 6M (2x3x1)

7M (2x4x1)

Benutzeranzahl 840 950 1.250 1.500





2,1 GB 1,7 GB 2,1 GB2,0 GB



16 GB 12 GB 15 GB 15 GB

Ergebnisse von 4M+ für die EinzelbenutzerauthentifizierungDie 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

(1x3x1)6M (1x4x1)






2,1 GB 1,9 GB 1,9 GB1,5 GB



20 GB 20 GB 20 GB 20 GB

273

3M (1x1x1) 4M (1x2x1) 5M (1x3x1)

6M (1x4x1)

Analysis Services-CPU 17% 44% 57% 68%

EmpfehlungenHardwareempfehlungenDie 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

274

unbeaufsichtigte Dienstkonto authentifizierten 7M-Dashboard. Die PerformancePoint Services-Inhaltsdefinitionen wie Berichte, Scorecards und KPIs werden in SharePoint-Listen gespeichert und von PerformancePoint Services im Arbeitsspeicher zwischengespeichert, wodurch die Auslastung des Datenbankservers sinkt.ArbeitsspeicherbelegungIn 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 ist niedrig; andere Dienste werden auf dem Anwendungsserver ausgeführt.

Hinzufügen von zusätzlichem physikalischen Arbeitsspeicher oder Begrenzen des Arbeitsspeichers des ASP.NET-Caches.

Nutzung des Anwendungsserverprozessors ist niedrig; nur PerformancePoint Services wird auf dem Anwendungsserver ausgeführt.

Konfigurieren der ASP.NET-Cacheeinstellungen, sodass mehr Arbeitsspeicher vom Cache genutzt wird (falls akzeptabel), oder Hinzufügen von zusätzlichem Arbeitsspeicher.

Nutzung des Anwendungsserverprozessors ist hoch.

Hinzufügen eines anderen Anwendungsservers.

275

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 ServicesBeim 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 CPU-Auslastung der Web-, Anwendungs- und Analysis Services-Server niedrig blieb. Zur Problembehandlung wurde die Abfragezeit mithilfe von dynamischen Analysis Services-Verwaltungssichten 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 UrsachenWä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

276



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 Services-Speicherheaps

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 Services-Abfragezeiten mithilfe dynamischer Verwaltungssichten, um festzustellen, ob Abfragezeiten mit der Benutzerauslastung steigen und die Analysis Services-Prozessornutzung 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&clcid=0x407).

Analysis Services-Abfrage- und Verarbeitungsthreads

Standardmäßig wird die Anzahl der Abfrage- und Verarbeitungsthreads für Abfragen von Analysis Services begrenzt. Bei lang andauernden Abfragen und hohen Benutzerauslastungen werden möglicherweise alle verfügbaren Threads verwendet. Überwachen Sie die Leistungsindikatoren der Threads im Leerlauf und der Auftragswarteschlange unter der Kategorie

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 2008-Whitepaper: Handbuch zur Leistungsoptimierung in Analysis Services (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x407).

277






Möglicher Engpass


Lösung

"MSAS 2008:Threads".

Arbeitsspeicher von Anwendungsservern

In PerformancePoint Services werden die Abfrageergebnisse von Analysis Services und anderen Datenquellen während der Lebensdauer des Caches der Datenquelle zwischengespeichert. Diese Elemente können sehr viel Arbeitsspeicher beanspruchen. Überwachen Sie den Leistungsindikator "ASP.NET-Anwendungen \ Cache-API-Kürzungen" des PerformancePoint Services-Anwendungspools, um festzustellen, ob Cachekürzungen aufgrund von niedrigem Arbeitsspeicher von ASP.NET erzwungen werden.

Fügen Sie Arbeitsspeicher hinzu, oder erhöhen Sie die Standard-Cachespeicherbegrenzungen von ASP.NET. Weitere Hinweise entnehmen Sie dem Abschnitt "Arbeitsspeicherbelegung" weiter oben in diesem Dokument. Weitere Informationen finden Sie auch im Dokument Einstellungen des ASP.NET-Cacheelements (http://go.microsoft.com/fwlink/?linkid=200610&clcid=0x407) sowie in Thomas Marquardts Blogbeitrag über Hintergrundinfos zu den Arbeitsspeicherbegrenzungen des ASP.NET-Caches (http://go.microsoft.com/fwlink/?linkid=200611&clcid=0x407).

Einstellungen der WCF-Drosselung

PerformancePoint Services ist als WCF-Dienst implementiert. Durch WCF wird die maximale Anzahl gleichzeitiger Aufrufe als Dienstdrosselungsverhalten eingeschränkt. Obwohl lang andauernde Abfragen zu diesem Engpass führen könnten, tritt dieser Engpass nicht

Falls erforderlich, ändern Sie das WCF-Drosselungsverhalten (Windows Communication Foundation). Informationen finden Sie unter Drosselungsverhalten des WCF-Diensts (http://go.microsoft.com/fwlink/?linkid=200612&clcid=0x407) und in Wenlong Dongs Blogbeitrag über die WCF-Anforderungsdrosselung und Serverskalierbarkeit (http://go.microsoft.com/fwlink/?linkid=200613&clcid=0x407).

278









Möglicher Engpass


Lösung

häufig auf. Überwachen Sie Aufrufe der Leistungsindikatoren des WCF-/Dienst-Modells, die für PerformancePoint Services ausstehen und vergleichen Sie sie mit der maximalen Anzahl gleichzeitiger Aufrufe.

LeistungsüberwachungUm 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

zHinweise

ASP.NET-Anwendungen / Cache-API-Kürzungen

PerformancePoint Services-Anwendungspool

Wenn der Wert größer als Null ist, lesen Sie den Abschnitt "Arbeitsspeicherbelegung" durch.

MSAS 2008:Threads / Abfragepoolthreads im Leerlauf

n/v 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&clcid=0x407).

MSAS 2008:Threads / Abfragepool-Auftragswarteschlangenlänge

n/v 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&clcid=0x407).

279







Leistungsindikator Indikatorinstanz

Hinweise

MSAS 2008:Threads / Verarbeitungspoolthreads im Leerlauf


MSAS 2008:Threads / Verarbeitungspool-Auftragswarteschlangenlänge


WCF CountersServiceModelService 3.0.0.0(*)\Ausstehende Aufrufe

PerformancePoint-Dienstinstanz

Wenn der Wert größer als Null ist, lesen Sie die Informationen in WCF-Anforderungsdrosselung und Serverskalierbarkeit (http://go.microsoft.com/fwlink/?linkid=200613&clcid=0x407).

Siehe auchWeitere RessourcenPlan for PerformancePoint Services (SharePoint Server 2010)

280

http://technet.microsoft.com/library/4c1ac4c1-1154-4346-9b80-0b804802beaa(Office.14).aspx









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

IntroductionOverviewAs 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:

281

http://technet.microsoft.com/library/bfc60f64-f816-4e68-896f-91784d0aaa47(Office.14).aspx

Traffic Search InventorySharePoint 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 overviewThe 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).

282

Figure 1. SharePoint Server 2010 Web Analytics architectural overviewThe performance of the Logging Web Service primarily depends on the number of application servers. (Scaling out is available for the application servers.) The

283

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 topologyThis 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 serversThis article does not cover the Web server layer capacity planning, because the Web Analytic service’s capacity requirements are minimal at this level. Application serversThe 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



Network adapter speed 1 GB

Authentication NTLM

Load balancer type SharePoint Load Balancer

284

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 serversThe 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.


Network adapter speed 1 GB

Authentication NTLM


285

TopologyThe following diagram (Figure 2) shows the Web Analytics topology.

286

Figure 2. Web Analytics topology

287

Capacity requirementsTesting methodologyThis 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 descriptionThe 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.

288

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 portalsIf 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 serversThe 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.

289

http://technet.microsoft.com/library/8e0b7a53-6741-4b19-897e-4b42e5b8e005(Office.14).aspx#Section3

Figure 3. Daily site traffic vs. the application servers topologyThe 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 computersThe 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).

290

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 topologyThe 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.

291

Configuration 1S+R 1S1R 1S1R 2S1R 2S1R

Staging + Reporting Staging Reporting Staging Reporting

Total sum of percentage of processor time for 8 processor computer

19 192 5.78 100 13.4

SQL Server buffer hit ratio99 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 factorsMany 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 issuesThere 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 auchKonzepteLeistungs- und Kapazitätsverwaltung (SharePoint Server 2010)

Weitere RessourcenSharePoint 2010 Administration Toolkit (SharePoint Server 2010)

292

http://technet.microsoft.com/library/a7c82686-15d9-4685-b303-44a3fc675d3f(Office.14).aspx

Schätzen der Leistungs- und Kapazitätsanforderungen für Web Content Management in SharePoint Server 2010Dieser 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 SharePoint-Umgebung 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 2010-

Bereitstellung 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 Testdetails und Ansatz Web Content Management-Bereitstellungen Optimierung

293

Testergebnisse und Empfehlungen Informationen zu den Autoren

VoraussetzungenEhe 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 AnsatzBei 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.

DatasetDie 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

Anzahl der Webanwendungen 1

Anzahl der Websites 50

294

http://technet.microsoft.com/de-de/library/cc261716.aspx

http://technet.microsoft.com/de-de/library/cc261700.aspx

Objekt Veröffentlichungssite

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 CPU-Auslastung ü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.

HardwareDie 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

Lastenausgleichstyp Hardwarelastenausgleich

Softwareversion SharePoint Server 2010 (Vorabversion)

Lokal ausgeführte Dienste Zentraladministration

295

Webserver

Eingehende Microsoft SharePoint Foundation-E-MailMicrosoft SharePoint Foundation-WebanwendungMicrosoft SharePoint Foundation-Workflowtimerdienst

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

GlossarIn 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.

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.

296

Die Fehlerrate ist niedriger als 0,01 Prozent.

Web Content Management-BereitstellungenEs existieren zwei Modelle für das Erstellen von Inhalten in SharePoint-Verö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. Unternehmenswikiseiten unterscheiden sich von Veröffentlichungsseiten und zeichnen sich durch andere Leistungseigenschaften aus.

297

OptimierungDieser 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üsselmetrikDurchsatz 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 AbhilfeEine 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.

298

CPU-Auslastung der WebserverDie Webserver-CPU sollte den Engpass in einer gut abgestimmten Topologie darstellen, da sie die am einfachsten zu skalierende Komponente darstellt. Anforderungen werden

299

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 Webserver-CPU 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.

300

Sonstige EngpässeWenn 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 CachingIn 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.

301

http://msdn.microsoft.com/de-de/library/aa604896.aspx



Testergebnisse und EmpfehlungenIn 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 AusgabecachesDer 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-TrefferrateBei 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.

302

Hinweis: Der Datenpunkt für die maximale RPS in einer 4x1-Serverfarm mit einer Ausgabecache-Trefferrate 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

303

Ausgabecache-Trefferrate

Measure 1x1 2x1 4x1

100% Maximale RPS

CPU-Auslastung von SQL Server

3.463

0%

7.331

0%

11.032

0%

95% Maximale RPS


2.137

5,93%

3.945

12,00%

5.937

21,80%

90% Maximale RPS


1.518

7,12%

2.864

14,40%

4.518

28,00%

50% Maximale RPS


459

9,86%

913

19,50%

1.596

42,00%

0% Maximale RPS


172

9,53%

339

19,00%

638

36,30%

Schlussfolgerungen und Empfehlungen im Hinblick auf die Aktivierung des AusgabecachesHö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 Seitenausgabe-

304

http://office.microsoft.com/de-de/ha101785628.aspx

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 BenutzerIm 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.

CacheprofileIn 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.

305

http://office.microsoft.com/de-de/ha101785628.aspx

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 BenutzerBei 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ängenBei 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 CPU-Auslastung der Webserver ca. 80-90 Prozent erreichte. Dann wurden Schreibvorgänge in der Umgebung unter Anwendung einer künstlichen Verzögerung ausgeführt. Die

306

http://technet.microsoft.com/library/40117fda-70a0-4e3d-8cd3-0def768da16c(Office.14).aspx

http://technet.microsoft.com/library/40117fda-70a0-4e3d-8cd3-0def768da16c(Office.14).aspx

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 CPU-Auslastung 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

307

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 CPU-Auslastung 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).

308

Schlussfolgerungen und Empfehlungen für Skalierungseigenschaften von Lese- und SchreibvorgängenUnsere 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 CPU-Auslastung des Datenbankservers dargestellt.

Einschränkungen im Zusammenhang mit dem Ausgabecache309

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ätDaten, 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 Lese- und 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.

310

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 AusgabecachesDurch 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 AntwortzeitDieser Test wurde auf einer 1x1-Farm mit anonymem Zugriff und aktiviertem Ausgabecache durchgeführt.

311

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 AntwortzeitWie 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 DurchsatzDas 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 Server-Vorgä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

312

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.

313

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 Ausgabecache-Trefferrate.

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.

314

Während der Schreibvorgänge wurde erwartungsgemäß eine zusätzliche SQL Server-Auslastung 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-CPU-Auslastung im Bereich von 60-80 Prozent während der Tests blieb, selbst als die Anzahl der Schreibvorgänge pro Stunde 500 erreichte.

315

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.

316

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 DurchsatzDie 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 CPU-Auslastung 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

317

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.

318

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% 0%

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

319

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 InhaltsbereitstellungDie 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 InhaltsbereitstellungIn 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%

Datenbankserver-CPU (%) 3,34% 2,41%320


Auswirkungen von Datenbankmomentaufnahmen während der Inhaltsbereitstellung


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 InhaltsbereitstellungDie 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 InhaltenDie 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.

SeitenanzahlDie 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

321

Die Erhöhung der Seitenanzahl auf 20.000 hatte keine signifikanten Auswirkungen auf die maximale RPS.

Mehrwertige NachschlagefelderEin 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.

322

Im folgenden Diagramm sind die Auswirkungen mehrwertiger Nachschlagefelder auf die Verwendung von Farmressourcen dargestellt.

323

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 VerwendungsberichterstellungDie 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)

324

http://technet.microsoft.com/library/33ed78c8-25fc-48ea-b0c1-50b540213cff(Office.14).aspx

http://technet.microsoft.com/library/33ed78c8-25fc-48ea-b0c1-50b540213cff(Office.14).aspx

Verwendungsdatenbank ein Verwendungsdatenbank aus

Differenz

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 AutorenJoshua 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.

325

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 characteristicsThe following sections describe the characteristics of the test farm: Dataset Workload Hardware, settings, and topology

DatasetTo 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.

WorkloadTesting 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 computersThe 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.

326

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 topologyTopologies 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

327

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


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

328

Test resultsThe 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 throughputThe 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 taskWorkflow 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 throughputThe 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

330

Automatically starting workflows when items are created throughputThe 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.


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

331

Task completion throughputThe 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.


1x1 13.5

2x1 23.86

3x1 27.06

4x1 27.14

332

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 throughputThe 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

333

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

334

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.

335

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.

RecommendationsThis 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 topologiesYou 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 targetsMany 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 settingsWorkflow 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

336


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 settingsFarm 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

337

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 queuingIf 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 FrequencyIn 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 BatchsizeSimilar 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:

338

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 listsWorkflows 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 considerationsRemoving 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 Resolution

Database contention (locks)

Database 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

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

339


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 I/O requests to a hard disk exceeds the disk's I/O capacity, the requests will be queued. As a result, the time to complete each request increases.

Distributing data files across multiple physical drives allows for parallel I/O. The blog SharePoint Disk Allocation and Disk I/O (http://go.microsoft.com/fwlink/?LinkId=129557) contains useful information about resolving disk I/O issues.

Web server CPU utilization

When a Web server is overloaded with user requests, average CPU utilization 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.

Web serversThe following table shows performance counters and processes to monitor for Web servers in a farm.


Processor time Total Shows the percentage of elapsed time that this thread used the processor to execute instructions.

340



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 serversThe following table shows performance counters and processes to monitor for database servers in your farm.


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 elapsed time that

341


this thread used the processor to execute instructions.

Memory utilization Total Shows the average utilization of system memory.

Siehe auchWeitere RessourcenWorkflow Scalability and Performance in Windows SharePoint Services 3.0 (http://go.microsoft.com/fwlink/?LinkId=207353)

342



Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010)Dieser Artikel beschreibt, wie Sie die Speicher- und Microsoft SQL Server-Datenbankschicht 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 Server-Farmimplementierer 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-ProdukteEs 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/A-

Anforderungen Prognostizieren der Arbeitsspeicheranforderungen Grundlegendes zu den Anforderungen an die Netzwerktopologie Konfigurieren von SQL Server Überprüfen von Speicherleistung und -zuverlässigkeit

343

Erfassen der Speicher- und SQL Server-Kapazität und der E/A-AnforderungenDer 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 werdenWelche Datenbanken mit SharePoint Server 2010 installiert werden, hängt von den Features ab, die in der Umgebung verwendet werden. Alle SharePoint 2010-Produkte-Umgebungen 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 KonfigurationInhalt der ZentraladministrationInhalt (eine oder mehrere)Verwendung und Integritätsdatensammlung Business Data ConnectivityAnwendungsregistrierungsdienst (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 Synchronisierung

344


http://technet.microsoft.com/library/9b1e8b21-7675-4186-beb6-3adeef4360e6(Office.14).aspx

http://technet.microsoft.com/library/9b1e8b21-7675-4186-beb6-3adeef4360e6(Office.14).aspx

Produktversion und -Edition Datenbanken

Thematische KategorienWeb Analytics-Dienstanwendung Staging BerichtEinmaliges AnmeldenStatusVerwaltete MetadatenWord Automation Services

Zusätzliche Datenbanken für SharePoint Server 2010 Enterprise Edition

PerformancePoint

Zusätzliche Datenbanken für Project Server 2010

EntwurfVeröffentlichtArchivBericht

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 IOPSBei 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

345


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 Server-Sicht 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-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx).

Prognostizieren der zentralen Speicher- und IOPS-AnforderungenKonfigurations- und Inhaltsspeicher sowie IOPS sind die Basisgrößen, die Sie bei jeder Bereitstellung von SharePoint Server 2010 planen müssen.

Konfigurationsspeicher und IOPSDie 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 IOPSDas 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

346

http://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx

http://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx



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.

347

Eingabe Wert

Anzahl der Dokumente (D) 200.000Berechnet 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) 2Unter 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 beeinflussenDie 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

348

http://technet.microsoft.com/library/9a75a461-6c86-4b61-be98-bcaf9290f2da(Office.14).aspx

http://technet.microsoft.com/library/abcf2ba8-86f6-4116-8461-b3e5fc6fedfb(Office.14).aspx

http://technet.microsoft.com/library/abcf2ba8-86f6-4116-8461-b3e5fc6fedfb(Office.14).aspx

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 DienstanwendungenNachdem 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-DienstanwendungenZum 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 HTTP-Anforderungen beispielsweise 2 GB an Speicher. Verwenden Sie eine der folgenden Formeln, um den Umfang der erforderlichen IOPS zu prognostizieren: 115 × Seitenzugriffe/Sekunde 5 × HTTP-AnforderungenWenn 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 Datenbank auch beschränken, indem Sie

349

Dienstanwendungsdatenbank Empfehlungen für die Größenprognose

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 Connectivity-Dienstdatenbank 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 IOPS-Anforderungen 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 IOPS-Anforderungen sind minimal.

Speicher- und IOPS-Anforderungen von SharePoint Server 2010-DienstanwendungenZum 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 Speicher für die Eigenschaften- und Durchforstungsdatenbanken zu

350


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 Standardeinstellungen verwenden sind in der Datenbank für thematische Kategorien ungefähr 0,009 MB pro Kategorie, Kommentar oder Bewertung

351


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:

Datenbankname Datenbankgröße

Profil 155 GB

Synchronisierung 96 GB

Thematische Kategorien

0,66 GB

Verwaltete Metadaten 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 IOPS-Anforderungen für diese Datenbank finden Sie unter Ergebnisse der Leistungs- und 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

352


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 IOPS-Anforderungen 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 IOPS-Anforderungen 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ügbarkeitVerfü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. 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 -EditionObwohl 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

353

http://technet.microsoft.com/library/04812402-43d6-4605-960c-1dd5ec65bef1(Office.14).aspx

http://technet.microsoft.com/library/04812402-43d6-4605-960c-1dd5ec65bef1(Office.14).aspx

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 Analytics-Dienstanwendung 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 Server-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 Server-Arbeitsauslastungen mit der Ressourcenkontrolle.Die Verwendung der Ressourcenkontrolle mit SharePoint Server 2010 empfiehlt sich aus folgenden Gründen:

354

http://msdn.microsoft.com/de-de/library/bb933866.aspx

http://msdn.microsoft.com/de-de/library/bb933866.aspx


http://technet.microsoft.com/library/665876e1-2706-42ad-bd76-8e4d1da0ce92(Office.14).aspx

http://technet.microsoft.com/library/665876e1-2706-42ad-bd76-8e4d1da0ce92(Office.14).aspx

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-AnforderungenDie 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 SpeicherarchitekturDie 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)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.

355

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 FILESTREAM-Anbieter von SQL Server, da er Daten nur lokal auf dem gleichen Server speichert.

Auswählen von DatenträgertypenDie 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) SSD (Solid State Drive) oder Flash Disk

Auswählen von RAID-TypenRAID (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

356

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 ArbeitsspeicheranforderungenDer 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 einem Maximum von 5 TB

64 GB

357




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 NetzwerktopologiePlanen 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 Endbenutzer-Datenverkehrs und ein weiterer Adapter für die Verarbeitung der Kommunikation mit den Servern mit SQL Server.

Konfigurieren von SQL ServerIn 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

358

http://technet.microsoft.com/library/3d7496d6-1a0b-4efd-bfe4-6e15c98ea932(Office.14).aspx#Section6_5





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 ArbeitsspeicherAuf 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 SpeicherherstellersBefolgen 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/A-Methoden bei der Vorabbereitstellung (http://go.microsoft.com/fwlink/?linkid=105583&clcid=0x407).

Bereitstellen möglichst vieler RessourcenStellen 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 IIS-Protokollen (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-OptionenSie sollten die folgenden SQL Server-Einstellungen und Optionen konfigurieren, bevor Sie SharePoint Server bereitstellen.

359



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 DatenbankenIm 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ägernIdealerweise sollten Sie die tempdb-Datenbank, Inhaltsdatenbanken, die Verwendungsdatenbank, Suchdatenbanken und SQL Server 2008-Transaktionsprotokolle 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 Transaktionsprotokolle1. Datenbank-Transaktionsprotokolldateien2. Suchdatenbanken, ausgenommen die Suchverwaltungsdatenbank3. 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.

360



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 InhaltsdatenbankenFolgen 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 VerwaltbarkeitPlanen Sie die Datenbankgröße so, dass die Verwaltbarkeit und Leistung der Umgebung verbessert und ein Upgrade vereinfacht wird.

361


http://technet.microsoft.com/library/01abe8d2-33f8-48fe-af76-40522a5afe08(Office.14).aspx

http://technet.microsoft.com/library/01abe8d2-33f8-48fe-af76-40522a5afe08(Office.14).aspx



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.4. Wenn Sie über Daten im Umfang von mehreren TB verfügen.5. 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 2010-Kapazitä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:

362



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

363



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: 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 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: 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.

364


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.

365

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.

366


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 Lese- und 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äger-Warteschlangen 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ägersubsystem-

367

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 Ein- und 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


5

368


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 ÜberwachungstoolsFü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).

369



download.microsoft.com€¦ · Web viewWord Automation Services-Anwendung Dieser Dienst...

Documents

Transcript of download.microsoft.com€¦ · Web viewWord Automation Services-Anwendung Dieser Dienst...