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

Artikel
03/08/2023

GILT FÜR: yes-img-13 2013 no-img-16 2016 no-img-19 2019 no-img-se Subscription Edition no-img-sop SharePoint in Microsoft 365

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.

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 einer Testumgebung erstellt, wobei eine Workload, ein Dataset und eine Architektur eine Produktionsumgebung unter streng kontrollierten Bedingungen emulieren. Auch wenn die Tests äußerst sorgfältig ausgelegt wurden, können unter Testbedingungen 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. Stattdessen zeigen die Testergebnisse beobachtete Trends in Bezug auf Durchsatz, Latenz und Hardwarebedarf und bieten eine Analyse der beobachteten Daten, die Ihnen helfen können, Entscheidungen zur Kapazitätsplanung und Verwaltung Ihrer eigenen Farm zu 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.

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
  
  [!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 ist kleiner als 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:

Die Webserver wurden skaliert, bis vier Webserver im Einsatz waren. Auf jedem Server wird der verteilte Cachedienst ausgeführt.
Ein dedizierter Server wurde hinzugefügt, auf dem der verteilte Cachedienst ausgeführt wird.
Auf den Webservern wurde der verteilte Cachedienst deaktiviert.
Weitere Webserver wurden hinzu skaliert, bis der maximale Testumfang erreicht war.
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

[!WICHTIGER HINWEIS] 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.

Hosthardware	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

[!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. Dazu gehören: SharePoint-Zeitgeberdienst, Ablaufverfolgungsdienst, Word Automation Services, Excel Services und Microsoft SharePoint Foundation Sandboxed Code Service. 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 Labumgebung wurde die Protokollierung eingeschränkt, und die Protokollierungsdatenbank wurde in einer separaten Instanz von SQL Server 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.

Dieses Diagramm zeigt die Labortopologie für das Testen der Leistung und Kapazität des Szenarios

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

Dieses Diagramm zeigt die Arbeitslasten beim Leistungstest nach Vorgangskategorien aufgeschlüsselt an.

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

[!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 zur Kapazitätsplanung für verteilte Caches finden Sie unter Planen von Feeds und dem Verteilten Cachedienst in SharePoint Server.
Als Leistungstests für SharePoint Server 2010 durchgeführt wurden, wurde der Datenbankserver bei maximalem Durchsatz mit vier Webservern zu einem Engpass. Aufgrund der Verbesserungen bei den Zwischenspeicherungs- und Datenbanknutzungsmerkmalen in SharePoint Server 2013 ist die durchschnittliche Last auf der Datenbankserverebene deutlich geringer als in SharePoint Server 2010, und es war nicht erforderlich, die Datenbankserver während des Tests aufskalieren.

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 Hyper-V virtualization requirements for SharePoint 2013 und Use best practice configurations for the SharePoint 2013 virtual machines and Hyper-V environment.

Hinweis

[!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

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

Dieses Diagramm zeigt die RPS-Basislinie für die Grüne und die Rote Zone.

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.

Dieses Diagramm zeigt den Zusammenhang zwischen RPS und Wartezeit.

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.

Dieses Diagramm zeigt den Zusammenhang zwischen RPS und CPU- und RAM-Auslastung des Webservers.

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 eine Produktionsumgebung nicht repräsentativ, da unser Dataset viel kleiner als das einer Produktionsfarm war. Es war daher möglich, dass ein größerer Prozentsatz der Daten auf den Webservern zwischengespeichert wird, als es in einer Produktionsumgebung möglich wäre. Bei den IOPS-Ergebnissen in diesem Abschnitt handelt es sich daher um berechnete Durchschnittswerte, die auf verfügbaren Testdaten basieren und im Allgemeinen niedriger als IOPS in einer Produktionsumgebung sein werden. 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.

SQL Server IOPS-Gesamt

Die folgende Darstellung zeigt, wie sich eine Skalierung auf die IOPS-Gesamtwerte auswirkt.
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.
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:

Eine SharePoint Server 2010-Umgebung wurde erstellt.
Die SharePoint Server 2010-Umgebung wurde mithilfe der Arbeitslasten getestet, die weiter oben in diesem Abschnitt beschrieben sind.
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 übertrifft SharePoint Server 2013 SharePoint Server 2010 auf fünf Webservern, mit einer Verbesserung der RPS um mehr als 10 % und einer etwas geringeren Latenz. Auf zwei Webservern führt SharePoint Server 2013 jedoch zu einem niedrigeren RPS und einer leichten Latenzverbesserung gegenüber 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.

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