Abschätzen der Leistungs- und Kapazitätsanforderungen für Unternehmensumgebungen für eine Zusammenarbeit über das Intranet (SharePoint Server 2013)

 

**Gilt für:**SharePoint Server 2013

**Letztes Änderungsdatum des Themas:**2017-08-25

**Zusammenfassung:**Mithilfe der in diesem Artikel aufgeführten Testergebnisse und Empfehlungen können Sie die Leistungs- und Kapazitätsanforderungen für eine SharePoint Server 2013-Lösung, die eine Zusammenarbeit im Unternehmen über das Intranet ermöglicht, abschätzen.

Dieser Artikel enthält Richtlinien für die Leistungs- und Kapazitätsplanung einer auf SharePoint Server 2013 basierenden Lösung, die eine Zusammenarbeit im Unternehmen über das Intranet ermöglicht. Dazu gehört Folgendes:

• Spezifikationen der Laborumgebung, wie Hardware, Farmtopologie und Konfiguration

• Testfarm-Arbeitslasten und Dataset, mit dem die Testlasten generiert wurden

• Testergebnisse und -analysen, die Aufschluss über den Verlauf von Durchsätzen, Wartezeiten und Hardwarebelastung bei bestimmten Bezugspunkten geben.

Anhand der in diesem Artikel enthaltenen Informationen können Sie erkennen, wie sich das Szenario unter normalen und unter Spitzenlasten verhält und wie sich die Leistungsverläufe ändern, wenn Farmserver horizontal skaliert werden. Außerdem können Sie mithilfe dieses Artikels auch einen geeigneten Ausgangspunkt für Ihre geplante Architektur abschätzen und die wichtigsten Faktoren bestimmen, die Sie bei der Planung der Ressourcen Ihrer Farm berücksichtigen müssen, damit die Leistung auch unter Spitzenlast Ihren Anforderungen entspricht.

Inhalt dieses Artikels:

• Einführung in diese Umgebung

• Glossar

• Übersicht

• Spezifikationen

• Ergebnisse und Analysen

Einführung in diese Umgebung

Dieser Artikel zeigt, wie Server in einer SharePoint Server 2013-Lösung, die für die Zusammenarbeit im Unternehmen über das Intranet dient, horizontal skaliert werden. Die Kapazitätsplanung zeigt, welche Entscheidungen beim Erwerb von Hardware und bei der Durchführung von Systemkonfigurationen getroffen werden müssen, um eine optimale Lösung zu erhalten.

Jede SharePoint Server 2013-Farm ist einzigartig und muss jeweils eigene Anforderungen erfüllen, die von der Hardware, dem Benutzerverhalten, der Konfiguration installierter Funktionen und vielen anderen Faktoren abhängen. Daher müssen Sie zusätzlich zu dieser Anleitung auch noch eigene Tests Ihrer Hardware in Ihrer eigenen Umgebung durchführen. Wenn Ihr geplanter Entwurf und die zu erwartenden Lasten der im vorliegenden Artikel beschriebenen Umgebung ähneln, können Sie diesen Artikel nutzen, um Schlussfolgerungen für die Skalierung Ihrer eigenen Umgebung zu ziehen.

Die in diesem Artikel aufgeführten Testergebnisse wurden in einem Testlabor erzielt, in dem mittels Arbeitslasten, Dataset und Architektur eine Produktionsumgebung unter genau kontrollierten Bedingungen simuliert wurde. Auch wenn die Tests äußerst sorgfältig entworfen wurden, können unter Laborbedingungen nie die gleichen Bedingungen wie in einer echten Produktionsumgebung nachgestellt werden. Die hier aufgeführten Testergebnisse geben daher nicht die Leistungs- und Kapazitätskenndaten einer Produktionsfarm wieder. Sie geben jedoch Aufschluss über beobachtete Trends bei Durchsätzen, Wartezeiten und Hardwareauslastungen. Mithilfe der angegebenen Analysen der gemessenen Daten können Sie selber Entscheidungen bezüglich der Kapazitätsplanung und Verwaltung Ihrer eigenen Farm treffen.

Dieser Artikel enthält Angaben zu den folgenden Punkten:

• Spezifikationen zu Hardware, Topologie und Konfiguration

• Die Arbeitslast, inklusive einer Analyse der Auslastung der Farm, der Anzahl der Benutzer sowie Nutzungskenndaten

• Das Dataset, wie zum Beispiel Datenbankgrößen und Inhaltstypen

• Testergebnisse und Analysen für die horizontale Skalierung von Webservern

• Vergleich von SharePoint Server 2010 und SharePoint Server 2013 hinsichtlich Durchsatz, Wartezeit und Webserverleistung, sowohl auf physischen Servern als auch auf virtuellen Computern (VMs)

Für diesen Artikel müssen Sie die folgenden Artikel gelesen haben, damit Sie mit den wichtigsten Konzepten bei der Kapazitätsplanung in SharePoint Server 2013 vertraut sind.

• Kapazitätsverwaltung und Dimensionierung für SharePoint Server 2013

• Softwarebeschränkungen und -grenzen für SharePoint Server 2016

Diese Artikel enthalten die folgenden Informationen

• Die empfohlene Vorgehensweise bei der Kapazitätsverwaltung

• So nutzen Sie die in diesem Artikel enthaltenen Informationen am besten

• Definitionen von Begriffen, die in diesem Artikel verwendet werden

Glossar

Nachfolgend sind einige Fachbegriffe aufgeführt, die im Verlauf dieses Artikels vorkommen werden.

• RPS: Steht für "Requests Per Second" und gibt an, wie viele Anforderungen pro Sekunde bei einer Farm oder einem Server eingehen. Dies ist ein gängiges Maß für die Auslastung von Servern und Farmen.

  Beachten Sie, dass Anforderungen etwas anderes als Seitenladevorgänge sind. Eine Seite enthält verschiedene Komponenten, von denen jede eine oder mehrere Anforderungen stellt, wenn die Seite vom Browser geladen wird. Daher fallen beim Laden einer Seite mehrere Anforderungen an. Authentifizierungsprüfungen und Ereignisse, die kaum Ressourcen in Anspruch nehmen, werden bei RPS-Messungen für gewöhnlich nicht mitgezählt.

• Grüne Zone: Die "Grüne Zone" ist ein definierter Satz von Lastkenndaten unter normalen Betriebsbedingungen bis hin zu voraussichtlichen täglichen Spitzenlasten. Eine Farm, die in diesem Bereich arbeitet, sollte in der Lage sein, akzeptable Reaktions- und Wartezeiten einzuhalten.

  In diesem Status kann der Server die folgenden Kriterien erfüllen:

  • Die serverseitige Wartezeit beträgt bei mindestens 75 % der Anforderungen weniger als 1 Sekunde.

  • Alle Farmserver arbeiten mit einer durchschnittlichen CPU-Auslastung von weniger als 60 %.

    Hinweis

    Da in dieser Laborumgebung keine aktive Suchdurchforstung ausgeführt wurde, hielt der Datenbankserver eine CPU-Auslastung von maximal 50 % ein, um 10 % für Suchdurchforstungslasten vorzuhalten. Dabei wird davon ausgegangen, dass in Produktionsumgebungen die SQL Server-Ressourcenkontrolle eingesetzt wird, um Suchdurchforstungslasten auf 10 % der CPU-Ressourcen einzuschränken.

  • Die Fehlerrate liegt unterhalb von 0,01 %.

• Rote Zone (Max): Die "Rote Zone" ist ein definierter Satz von Lastkenndaten unter Betriebsbedingungen mit Spitzenlasten. In dieser Zone treten in der Farm stark schwankende Ressourcenauslastungen auf, die nur für begrenzte Zeiträume bewältigt werden können, bevor Fehler und andere Probleme hinsichtlich Leistung und Zuverlässigkeit auftreten.

  In diesem Status kann der Server einen beschränkten Zeitraum lang die folgenden Kriterien erfüllen:

  • Die Funktion für die HTTP-Anforderungssteuerung ist aktiviert, es werden jedoch keine Fehler vom Typ 503 (Server ist ausgelastet) zurückgegeben.

  • Die Fehlerrate liegt unterhalb von 0,1 %.

  • Die serverseitige Wartezeit beträgt bei mindestens 75 % der Anforderungen weniger als 3 Sekunden.

  • Alle Farmserver (außer Datenbankserver) arbeiten mit einer durchschnittlichen CPU-Auslastung von weniger als 90 %.

  • Die durchschnittliche CPU-Auslastung der Datenbankserver liegt unterhalb von 50 %, sodass eine ausreichende Reserve für Suchdurchforstungslasten vorhanden ist.

• AxBxC (Diagrammbeschriftung): Das ist die Anzahl der in einer Farm befindlichen Web-, Anwendungs- und Datenbankserver. So bedeutet 10x1x1 zum Beispiel, dass in dieser Umgebung 10 Webserver, 1 Anwendungsserver und 1 Datenbankserver vorhanden sind.

• **MDF und LDF:**Physische SQL Server-Dateien. Weitere Informationen dazu finden Sie unter Architektur von Dateien und Dateigruppen.

Übersicht

Dieser Abschnitt gibt einen Überblick über unseren Skalierungsansatz und die Testmethoden.

Skalierungsansatz

Dieser Abschnitt beschreibt den Ansatz, nach dem wir diese Laborumgebung skaliert haben. Diese Vorgehensweise wird es Ihnen ermöglichen, die beste Konfiguration für Ihre Arbeitslast zu ermitteln:

1. Die Webserver wurden skaliert, bis vier Webserver im Einsatz waren. Auf jedem Server wird der verteilte Cachedienst ausgeführt.

2. Ein dedizierter Server wurde hinzugefügt, auf dem der verteilte Cachedienst ausgeführt wird.

3. Auf den Webservern wurde der verteilte Cachedienst deaktiviert.

4. Weitere Webserver wurden hinzu skaliert, bis der maximale Testumfang erreicht war.

5. Zum Vergleichen der Leistungskenndaten von SharePoint Server 2013 und SharePoint Server 2010 wurden weitere Tests durchgeführt.

Testmethoden und Anmerkungen

Da dieser Artikel auf Testergebnissen basiert, die in einer Laborumgebung erzielt wurden, konnten wir einzelne Faktoren steuern, um bestimmte Leistungsaspekte für diese Arbeitslast hervorzuheben. Außerdem wurde in der Laborumgebung auf bestimmte Elemente einer Produktionsumgebung verzichtet (siehe folgende Liste), um den Testaufwand zu vereinfachen.

Hinweis

Es wird empfohlen, dass diese Elemente in Produktionsumgebungen vorhanden sind.

• Zwischen den Testdurchgängen wurde immer nur jeweils eine Variable verändert, damit Ergebnisse aus verschiedenen Testdurchläufe leicht verglichen werden können.

• Die Datenbankserver waren nicht in einen Cluster eingebunden, da Redundanz bei diesen Tests keine Rolle spielte.

• Während der Tests wurde die Suchdurchforstung nicht ausgeführt. In einer Produktionsumgebung wäre dies natürlich der Fall. Um diesen Punkt zu berücksichtigen, haben wir in unseren Definitionen die CPU-Auslastung von SQL Server für die Grüne Zone und die Rote Zone um einen entsprechenden Betrag verringert.

Spezifikationen

Dieser Abschnitt enthält Details zur Hardware, Software, Topologie und Konfiguration der Laborumgebung.

Hardware

Im folgenden Abschnitt ist die Hardware beschrieben, die in dieser Laborumgebung verwendet wurde.

Wichtig

beachten Sie, dass alle Webserver und Anwendungsserver in der Testumgebung mithilfe von Hyper-V-Hosts virtualisiert wurden. Datenbankserver wurden nicht virtualisiert. Die Hardware der physischen Hosts und die virtuelle Hardware der VM sind weiter unten separat beschrieben.

Hyper-V-Hosts

Bei den Tests wurden insgesamt sechs identisch konfigurierte Hyper-V-Hosts eingesetzt. Jeder Host wurde in einer oder zwei VMs ausgeführt.

Host-Hardware	Wert
Prozessor(en)	2 Vierkern-Prozessoren mit 2,49 GHz
RAM	32 GB
Betriebssystem	Windows Server 2008 R2 SP1
Anzahl der Netzwerkadapter	2
Geschwindigkeit der Netzwerkadapter	1 Gigabit

Virtuelle Webserver und Anwendungsserver

Die Farm verfügt über 1 bis 10 virtuelle Webserver. Auf einem weiteren dedizierten virtuellen Server wird der verteilte Cachedienst ausgeführt.

Hinweis

In einer Produktionsumgebung würden dedizierte Server für den verteilten Cachedienst meist in einer Hochverfügbarkeitskonfiguration bereitgestellt werden. Bei den Tests wurde für den verteilten Cachedienst ein einziger dedizierter Server eingesetzt, da Hochverfügbarkeit nicht von Bedeutung war.

VM-Hardware	WFE1-10 und DC1
Prozessoren	4 virtuelle Prozessoren
RAM	12 GB
Betriebssystem	Windows Server 2008 R2 SP1
Größe des SharePoint-Laufwerks	100 GB
Anzahl der Netzwerkadapter	2
Geschwindigkeit der Netzwerkadapter	10 Gigabit (Datenverkehr zwischen den Hosts war auf die Geschwindigkeit der Host-Netzwerkkarte begrenzt)
Authentifizierung	Windows-NTLM
Lastenausgleichstyp	F5 Big IP
Lokal ausgeführte Dienste	WFE 1-10: Grundlegende Verbunddienste, wie: SharePoint-Zeitgeberdienst, Ablaufverfolgungsdienst, Word Automation Services, Excel Services und Microsoft SharePoint Foundation-Sandkasten-Codedienst. DC1: Verteilter Cachedienst.

Datenbankserver

Ein physischer Datenbankserver, auf dem die SQL Server-Standardinstanz ausgeführt wird, die die SharePoint-Datenbanken enthält. Die Protokollierungsdatenbank wird in diesem Artikel nicht nachverfolgt.

Hinweis

Wenn Sie die Verwendungsberichterstellung aktivieren, wird empfohlen, die Protokollierungsdatenbank auf einer separaten LUN (Logical Unit Number, Logische Gerätenummer) zu speichern. In großen und einigen mittleren Bereitstellungen kann aufgrund der Prozessorauslastung bei hohen Protokollierungsvolumina ein dedizierter Protokollierungsdatenbankserver erforderlich sein.
In dieser Laborumgebung war die Protokollierung eingeschränkt, und die Protokollierungsdatenbank wurde in einer separaten SQL Server-Instanz gespeichert.

Datenbankserver – Standardinstanz	SPSQL
Prozessoren	4 Vierkern-Prozessoren mit 2,4 GHz
RAM	32 GB
Betriebssystem	Windows Server 2008 R2 SP1
Speicher und Geometrie	Direct-Attached Storage (DAS) 1 x Systemvolume (RAID 0, 1 Spindel, 300 GB) 2 x Volumes für Inhaltsdaten (RAID 0, 4 Spindeln, jeweils 450 GB) 2 x Volumes für Inhaltsprotokolle (RAID 0, 2 Spindeln, jeweils 450 GB) 1 x Volume für temporäre Daten (RAID 0, 2 Spindeln, jeweils 300 GB) 1 x Volume für temporäre Protokolle (RAID 0, 2 Spindeln, jeweils 300 GB)
Anzahl der Netzwerkadapter	1
Geschwindigkeit der Netzwerkadapter	1 Gigabit
Authentifizierung	Windows-NTLM
Softwareversion	SQL Server 2008 R2

Topologie

Im folgenden Diagramm wird die in dieser Laborumgebung verwendete Topologie gezeigt.

Konfiguration

Um bei den Tests eine optimale Leistung zu erzielen und die Beziehungen zwischen Testparametern und Ergebnissen klar erkennbar zu machen, wurden an der Laborumgebung die folgenden größeren Konfigurationsänderungen vorgenommen.

Einstellung	Wert	Anmerkungen
Websitesammlung	179	Die Websitesammlungen in der Testumgebung arbeiten mit Standardeinstellungen und Windows-Forderungsauthentifizierung.
Blob-Cache	Ein	Diese Einstellung ist standardmäßig deaktiviert. Wenn Sie die Blob-Cache-Funktion aktivieren, können Sie die Servereffizienz verbessern, da dann weniger Aufrufe für statische Seitenressourcen beim Datenbankserver eingehen, die sonst häufig angefordert werden.
Maximaler Grad an Parallelität (MAXDOP)	1	Dieser Parameter wird in der SQL Server-Instanz oder in Instanzen, die SharePoint Server 2013-Inhaltsdatenbanken enthalten, festgelegt. Der Standardwert beträgt 0 und bedeutet, dass SQL Server selbst den maximalen Grad an Parallelität bestimmen kann. Bei SharePoint Server 2013 muss für SQL Server-Instanzen, die SharePoint Server 2013-Datenbanken enthalten, ein MAXDOP-Wert von 1 festgelegt werden. Weitere Informationen über die Konfiguration der MAXDOP-Einstellung für SQL Server 2008 R2 finden Sie in dem entsprechenden TechNet-Artikel über Optionen für den maximalen Grad an Parallelität. Weitere Informationen zum Konfigurieren der MAXDOP-Einstellung für SQL Server 2012 finden Sie unter Konfigurieren der Serverkonfigurationsoption "Max. Grad an Parallelität".

Arbeitslast

In diesem Abschnitt werden die Laborergebnisse für SharePoint Server 2013 beschrieben. Die Details der Tests sind typisch für eine Umgebung für Zusammenarbeitszwecke in Unternehmen.

Dataset

Das Dataset für die in diesem Artikel beschriebene Laborumgebung, die eine typische Umgebung für Zusammenarbeitszwecke in Unternehmen darstellt, enthält verschiedene Websitesammlungen, Websites, Listen, Bibliotheken, Dateitypen und -größen.

Kenndaten des Datasets	Wert
Datenbankgröße (kombiniert)	174 GB
MDF-Größe	154 GB
LDF-Größe	20 GB
BLOB-Größe	152 GB
Anzahl von Inhaltsdatenbanken	2
Anzahl von Websitesammlungen	179
Anzahl von Webanwendungen	1
Anzahl von Websites	1.471

Ergebnisse und Analysen

Die folgenden Ergebnisse sind basierend auf den im Abschnitt Übersicht dieses Artikels beschriebenen Skalierungsmethoden sortiert.

Skalierung der Webserver

In diesem Abschnitt werden die Testergebnisse beschrieben, die bei einer Skalierung der Anzahl der Webserver in der Laborumgebung erzielt wurden.

Testmethodik

• Es werden Webserver mit identischen Hardwarespezifikationen hinzugefügt, und der Test wird ohne Änderungen an der Farm oder an Testparametern erneut ausgeführt.

• Bei jedem Server in der Testfarm werden RPS, Wartezeit und Ressourcenverwendung gemessen.

Analyse

Die Tests haben Folgendes ergeben:

• Die Umgebung wurde auf 10 Webserver pro Datenbankserver skaliert. Die Zunahmen beim Durchsatz erfolgten in etwa linear.

• Bis hin zur maximal getesteten Anzahl von 10 Webservern konnten die Durchsätze durch Hinzufügen weiterer Datenbankserver nicht weiter gesteigert werden. Die Engpässe wurden im Allgemeinen durch Webserverressourcen verursacht.

• Die durchschnittlichen Wartezeiten in der Grünen Zone waren während des gesamten Tests fast konstant. Die Anzahl der Webserver und die Durchsätze hatten keinen Einfluss auf die Wartezeiten in der Grünen Zone. Bei den Wartezeiten in der Roten Zone wurde ein Verlauf verzeichnet, der zu erwarten war. Bei einem einzigen Webserver sind die Wartezeiten sehr hoch. Bei 2 bis 10 Webservern bleibt die Kurve ausreichend innerhalb der Kriterien für die Rote Zone.

  Hinweis

  Die Wartezeit können Sie etwas beeinflussen, wenn Sie den verteilten Cachedienst aus den Webservern der Farm auf einen Server verlegen, der speziell für den verteilten Cachedienst dient. Der Grund dafür ist der, dass der Datenverkehr des verteilten Cachediensts, der zuvor in den einzelnen Webservern intern war, dann über das Netzwerk verläuft. Ob dieser Wechsel spürbare Verbesserungen mit sich bringt, müssen Sie in Ihrer eigenen Umgebung selbst testen. In unserer Testumgebung stieg die Wartezeit leicht an, wenn der verteilte Cachedienst auf einen dedizierten Server verlegt wurde. Mit jedem hinzugefügten Webserver nahmen die Wartezeiten ab, da die rein rechnerisch hinzugefügten Wartezeiten durch die gesunkenen CPU- und RAM-Auslastungen auf den Webservern kompensiert wurden.
  Weitere Informationen über die Kapazitätsplanung für den verteilten Cachedienst finden Sie unter Planen von Feeds und des Diensts für den verteilten Cache in SharePoint Server.

• Bei Durchführung der Leistungstests für SharePoint Server 2010 traten bei Einsatz von 4 Webservern und maximalem Durchsatz bei den Datenbankservern Engpässe auf. Aufgrund der in SharePoint Server 2013 implementierten Verbesserungen bei der Zwischenspeicherung und der Datenbanknutzung liegt die durchschnittliche Arbeitslast auf Datenbankserverebene deutlich niedriger als in SharePoint Server 2010. Während der Tests war es daher nicht erforderlich, die Datenbankserver zu skalieren.

  Weitere Informationen zu Testergebnissen unter SharePoint Server 2010 für dieses Szenario finden Sie in der Laborstudie zur Umgebung für Zusammenarbeitszwecke über das Intranet in Unternehmen (SharePoint Server 2010)

• Wie viel Leistungszuwächse durch das Hinzufügen virtueller Webserver erzielt werden können, hängt zum Teil davon ab, über welche Hardwareressourcen der Host verfügt und wie viel davon von anderen VMs in Anspruch genommen wird, die auf diesem Host ausgeführt werden. Bei der Kapazitätsplanung virtueller Server sind zusätzliche Planungs- und Verwaltungsstrategien für die virtuellen Aspekte erforderlich.

  Weitere Informationen zur Leistungs- und Kapazitätsplanung für Hyper-V finden Sie unter Anforderungen für die Virtualisierung mit Hyper-V für SharePoint 2013 und Anwenden bewährter Konfigurationsmethoden für virtuelle SharePoint 2013-Computer und Hyper-V-Umgebung.

Hinweis

Die in diesem Abschnitt beschriebenen Schlussfolgerungen gelten nur für die Hardware, aus denen die Umgebung aufgebaut ist. Die gleichen Durchsätze könnten möglicherweise auch mit mehr, jedoch schwächeren Hyper-V-Hostservern oder weniger, jedoch leistungsfähigeren Hyper-V-Hostservern erzielt werden. Bei einer Verbesserung der Hardwareressourcen auf dem Datenbankserver würden die Ergebnisse nicht wesentlich anders ausfallen.

Ergebnisse, Graphen und Diagramme

In den folgenden Diagrammen sind in der X-Achse die Änderungen bei der Anzahl von Webservern in der Farm angegeben. Die Skala beginnt bei einem virtuellen Webserver und einem physischen Datenbankserver (1x1). Das Maximum beträgt zehn virtuelle Webserver, ein dedizierter virtueller Server für den verteilten Cachdienst (der ab vier Webserver hinzugefügt wird) und ein physischer Datenbankserver (10x1x1).

Hinweis

Die Darstellungen in diesem Abschnitt zeigen die Durchschnittswerte für die einzelnen Datenpunkte während des Testverlaufs an. Alle Diagramme enthalten die RPS-Baseline für die Grüne Zone und die Rote Zone, um den Zusammenhang zwischen RPS und Faktoren wie Wartezeit, Auslastung von Serverressourcen und Datenträgerverwendung durch SQL Server aufzuzeigen.

1.) RPS

Die folgende Darstellung zeigt, wie sich eine Skalierung auf die RPS-Baseline auswirkt.

2.) Wartezeit

Die folgende Darstellung zeigt, wie sich eine Skalierung auf die Wartezeit auswirkt. Beachten Sie dabei, dass die Wartezeiten in der Grünen Zone größtenteils gleich bleiben, während in der Roten Zone moderate Abweichungen auftreten, die jedoch innerhalb akzeptabler Grenzen bleiben.

3.) CPU- und RAM-Auslastung auf dem Webserver

Die folgende Darstellung zeigt, welche Auswirkungen eine Skalierung auf die durchschnittliche CPU- und RAM-Auslastung auf den Webservern hat. Es ist zu erkennen, dass in der Grünen Zone die CPU-Auslastung bei zunehmendem RPS-Wert relativ konstant bleibt, während die durchschnittliche RAM-Auslastung leicht ansteigt.

In der Roten Zone verläuft die CPU-Auslastung in sinkender Richtung, was zeigt, dass die durchschnittliche CPU-Auslastung des Webservers bei maximaler Last leicht sinkt, je höher die Anzahl der Server ist.

4.) SQL Server-IOPs und CPU-Auslastung

Die folgende Darstellung zeigt, wie sich die Durchschnittswerte für Festplatten-IOPs (Lese-/Schreibvorgänge pro Sekunde auf die Festplatte) – sowohl insgesamt als auch nach Lese-/Schreibzugriffen aufgeteilt – und CPU-Auslastung ändern, wenn die Anzahl der Webserver skaliert wird. Die IOPs-Werte wurden anhand der folgenden Leistungsindikatoren gemessen:

• PhysicalDisk: Anzahl der Lesevorgänge auf dem Datenträger pro Sekunde

• PhysicalDisk: Anzahl der Schreibvorgänge auf dem Datenträger pro Sekunde

Aus den Werten der einzelnen Zähler während des Tests wurde der Durchschnitt ermittelt, und dann wurden die Durchschnitte zusammenaddiert, um den IOPs-Gesamtwert zu erhalten.

Hinweis

Daten zur RAM-Auslastung von SQL Server standen nicht zur Verfügung und sind in dieser Grafik nicht enthalten.

Wichtig

Diese IOPS-Testergebnisse sind für Produktionsumgebungen nicht repräsentativ, da unser Dataset viel kleiner als das einer Produktionsfarm ausgelegt war. Daher konnte ein prozentual viel höherer Anteil an Daten auf den Webservern zwischengespeichert werden, als dies in Produktionsumgebungen möglich wäre. Die in diesem Abschnitt aufgeführten IOPS-Ergebnisse sind daher Durchschnittswerte, die aus den verfügbaren Testdaten ermittelt wurden. In einer Produktionsumgebung sollten für gewöhnlich höhere IOPS zu erwarten sein. Gründliche Tests Ihrer eigenen Farm in einer Pilotumgebung könnten möglicherweise zu anderen Ergebnissen führen.

Wie Sie den hier aufgeführten Diagrammen entnehmen können, gingen die IOPS-Werte und die CPU-Auslastung auf dem Datenbankserver bei einer Anzahl von 9 und 10 Front-End-Webservern zurück, während die RPS-Werte weiter anstiegen. Diese Veränderung war auch bei der CPU-Auslastung auf dem Webserver (siehe vorheriges Diagramm) zu beobachten.

Das ist ein Anzeichen dafür, dass die Farm so weit skaliert war, dass durch Anwendung der Baseline-Arbeitslasten und des -Datasets eine maximale Belastung der Farmserverressourcen erreicht wurde. Zur Bewältigung der auf der Farm liegenden Arbeitslast ist eine niedrigere durchschnittliche Auslastung der Serverressourcen erforderlich.

Daraus lassen sich die folgenden Schlussfolgerungen ziehen:

• Wäre die Testlast beim 9. Webserver erhöht worden, hätten höhere RPS-Werte erreicht werden können, während die Kurve bei der Serverressourcenauslastung weiterhin flach geblieben wäre.

• Wäre die Anzahl der Webserver bei identischer Testlast weiter erhöht wurden, hätten die RPS-Werte weiter zugenommen und der Druck auf die Serverressourcen wäre weiter gesunken.

1. SQL Server IOPS-Gesamt

   Die folgende Darstellung zeigt, wie sich eine Skalierung auf die IOPS-Gesamtwerte auswirkt.

   

2. SQL Server IOPS-Werte, nach Lese- und Schreibvorgängen aufgeschlüsselt

   Die folgende Darstellung zeigt, wie sich eine Skalierung auf die IOPS-Gesamtwerte (nach Lese- und Schreibvorgängen aufgeschlüsselt) auswirkt.

   

3. CPU-Auslastung von SQL Server

   Die folgende Darstellung zeigt, wie sich eine Skalierung auf die CPU-Auslastung von SQL Server auswirkt.

   

Vergleich von SharePoint Server 2013 und SharePoint Server 2010

Dieser Abschnitt enthält Angaben über die Unterschiede bei der Leistung von SharePoint Server 2013 und SharePoint Server 2010 bei dieser Arbeitslast.

Arbeitslast

Für den Vergleich von SharePoint Server 2013 mit SharePoint Server 2010 setzten wir eine andere Kombination von Tests ein als die, die im Abschnitt Spezifikationen beschrieben ist. Dies war erforderlich, da einige SharePoint Server 2013-Features (wie der verteilte Cachedienst) und -Vorgänge in SharePoint Server 2010 nicht vorhanden sind.

Testmethodik

Zum Testen der Leistung in den beiden Umgebungen gingen wir wie folgt vor:

1. Eine SharePoint Server 2010-Umgebung wurde erstellt.

2. Die SharePoint Server 2010-Umgebung wurde mithilfe der Arbeitslasten getestet, die weiter oben in diesem Abschnitt beschrieben sind.

3. Die Inhaltsdatenbanken wurden auf SharePoint Server 2013 aktualisiert, ohne dass dabei an den Clients dieser Umgebung Änderungen vorgenommen wurden.

Diese aktualisierte Umgebung wurde auf den aktualisierten Servern, die als Host für SharePoint Server 2013 dienen, noch einmal unter Verwendung der gleichen Auswahl von Tests getestet, die nur SharePoint Server 2010-Vorgänge beinhalteten.

• Beide Umgebungen wurden zum Vergleich getestet. Zum Ausführen der Webserver auf einem Hyper-V-Host wurden in der einen Umgebung physische Server und in der anderen VMs verwendet. Der Datenbankserver wurde in beiden Fällen auf einem physischen Server ausgeführt.

• Das Dataset wurde nach dem Upgrade der Inhaltsdatenbank für die SharePoint Server 2013-Tests nicht geändert.

• Die Tests für SharePoint Server 2010 enthielten keine Vorgänge, die nur in SharePoint Server 2013 verfügbar sind, und sie ähnelten der Lösung für Zusammenarbeitszwecke im Unternehmen über das Intranet, die weiter oben in diesem Artikel beschrieben und getestet wurde.

Das Ziel der Tests bestand darin, auf die SharePoint Server 2013- und die SharePoint Server 2010-Farm ähnliche Belastungen mit der gleichen Arbeitslast und dem gleichen Dataset anzuwenden und dann festzustellen, welche Unterschiede es bei Durchsatz, Wartezeit und Auslastung an Serverressourcen gibt. Die Testmethoden und -ziele waren bei physischen und virtuellen Webserver-Tests unterschiedlich:

• Mit den auf physischen Servern durchgeführten Tests sollte verglichen werden, wie sich SharePoint Server 2013- und SharePoint Server 2010-Farmen bei Skalierung unter Last verhalten. Dabei wurden die Webserver in diesen Tests von zwei auf fünf skaliert.

• Mit den auf virtuellen Servern durchgeführten Tests sollte verglichen werden, wie sich SharePoint Server 2013- und SharePoint Server 2010-Farmen mit vier Webservern unter Benutzerlasten der Grünen und der Roten Zone verhalten. Eine Skalierung der Webserver wurde bei diesen Tests nicht vorgenommen.

Analyse

• Prinzipiell lässt sich sagen, dass SharePoint Server 2013 bei Skalierung auf fünf Webserver bessere Leistungen als SharePoint Server 2010 erreicht hat, während bei zwei Webservern SharePoint Server 2010 überlegen war. Die Tests der aktualisierten SharePoint Server 2013-Serverfarm beinhalteten keine nach dem Upgrade vorgenommenen Optimierungen und nutzten auch keine leistungsverbessernden Features von SharePoint Server 2013 (wie den verteilten Cachedienst oder den Anforderungs-Manager). Daher unterscheiden sich die Testergebnisse für SharePoint Server 2013 erheblich von den Ergebnissen, die in echten Produktionsumgebungen zu erwarten wären.

• Am Verlauf der Daten in den Diagrammen in diesem Abschnitt ist erkennbar, wie das Ressourcenverwaltungsmodell von SharePoint Server 2013 die Nutzung von CPU-Ressourcen gegenüber Schreib-/Lesezugriffen auf den Datenträger (IOPS) priorisiert.

• In der Grünen Zone erbringt SharePoint Server 2013 bei fünf Webservern eine bessere Leistung als SharePoint Server 2010, d. h., die Anforderungen pro Sekunde (RPS) sind um 10 % besser und die Wartezeiten sind etwas geringer. Bei zwei Webservern jedoch erreicht SharePoint Server 2013 niedrigere RPS-Werte und etwas bessere Wartezeiten als SharePoint Server 2010.

• In der Roten Zone erreichte SharePoint Server 2013 einen rund 12 % besseren Durchsatz als SharePoint Server 2010 bei fünf Webservern. Bei zwei Webservern lag der Durchsatz bei SharePoint Server 2010 rund 30 % höher. Bei den Wartezeiten erzielte SharePoint Server 2013 einen moderaten Vorsprung gegenüber SharePoint Server 2010 bei fünf Webservern.

• Die Ergebnisse der Tests auf virtuellen Servern fielen für SharePoint Server 2013 und SharePoint Server 2010 in der Grünen Zone ähnlich aus. In der Roten Zone liegt SharePoint Server 2013 bei Durchsatz und Wartezeit klar vor SharePoint Server 2010.

Ergebnisse, Graphen und Diagramme

Die Tests, mit denen die in diesem Abschnitt präsentierten Ergebnisse erzielt wurden, wurden sowohl auf physischen als auch auf virtuellen Webservern ausgeführt. Bei allen Tests wurde ein einzelner physischer Datenbankserver mit SQL Server 2008 R2 mit SP1 eingesetzt.

1. RPS und Wartezeit

   Das folgende Diagramm zeigt die Unterschiede bei Durchsätzen und Wartezeiten zwischen SharePoint Server 2013 und SharePoint Server 2010 bei Einsatz von zwei und fünf physischen Webservern in der Grünen Zone. Bei zwei Webservern erreichte SharePoint Server 2010 höhere RPS-Werte und längere Wartezeiten. Bei fünf Webservern erzielte SharePoint Server 2013 höhere RPS-Werte und niedrigere Wartezeiten.

   

   Das folgende Diagramm zeigt die Unterschiede bei der CPU-Auslastung des Webservers bei zwei und fünf physischen Webservern in der Roten Zone. Bei fünf Webservern war SharePoint Server 2013 sowohl beim RPS-Wert als auch bei der Wartezeit besser als SharePoint Server 2010, nicht jedoch bei zwei Webservern.

   

2. RPS und Serverressourcenauslastung

   Das folgende Diagramm zeigt die Unterschiede bei der CPU-Auslastung des Web- und des Datenbankservers bei zwei und fünf physischen Webservern in der Grünen Zone. Wie man erkennen kann, erreicht SharePoint Server 2013 bei fünf Webservern durch eine effizientere Nutzung der verfügbaren Serverressourcen einen höheren Durchsatz.

   

   Das folgende Diagramm zeigt die Unterschiede bei der CPU-Auslastung des Web- und des Datenbankservers bei zwei und fünf physischen Webservern in der Roten Zone. Auch hier erzielt SharePoint Server 2013 bei fünf Webservern wieder höhere Durchsätze, nicht jedoch bei zwei Webservern.

   

3. RPS und IOPS

   Das folgende Diagramm zeigt die Unterschiede bei Lese- und Schreibvorgängen (IOPS) beim Einsatz von zwei und fünf physischen Webservern für die Grüne Zone. Wie Sie sehen, steigen die IOPS-Werte für SharePoint Server 2013SharePoint Server 2016 zwischen zwei und fünf Webservern an, während sie für SharePoint Server 2010 abnehmen. Außerdem liegt die Steigerungsrate bei den RPS-Werten bei SharePoint Server 2013 deutlich höher als bei SharePoint Server 2010. Dieser Unterschied in den Kurven belegt, dass SharePoint Server 2013 Serverressourcen in größeren Farmen anders verwaltet, um größere Durchsätze zu erzielen.

   

   Das folgende Diagramm zeigt die Unterschiede bei Lese- und Schreibvorgängen (IOPS) beim Einsatz von zwei und fünf physischen Webservern für die Rote Zone. Wenn Sie diese Ergebnisse mit der oben im Abschnitt "RPS und Serverressourcenauslastung" gezeigten Kurve für die Rote Zone vergleichen, können Sie erkennen, dass das Ressourcenverwaltungsmodell von SharePoint Server 2013 die Nutzung von CPU-Ressourcen gegenüber den Lese-/Schreibzugriffen auf die Festplatte (IOPS) von SQL Server priorisiert.

   

4. RPS, Wartezeit und IOPS bei virtuellen Webservern

   Die Vergleichstest für virtuelle Server wurde mit vier virtuellen Webservern und einem physischen Datenbankserver durchgeführt.

   Das folgende Diagramm zeigt die Unterschiede bei Durchsätzen und Wartezeiten mit vier virtuellen Webservern. Bei Lasten der Grünen Zone erzielten SharePoint Server 2013 und SharePoint Server 2010 ähnliche Ergebnisse, während in der Roten Zone SharePoint Server 2013 bei Wartezeit und Durchsatz deutlich besser als SharePoint Server 2010 war.

   

   Das folgende Diagramm zeigt die Unterschiede bei Datenbank-IOPS mit vier virtuellen Webservern. SharePoint Server 2013 liegt sowohl bei Lasten der Grünen als auch der Roten Zone bei der Datenbank-IOPS-Leistung deutlich vorn.

   

See also

Planen der Leistung in SharePoint Server 2013 Planung
Ergebnisse und Empfehlungen zu Leistungs- und Kapazitätstests (SharePoint Server 2013)