Schätzen von Leistungs- und Kapazitätsanforderungen für Umgebungen zur Zusammenarbeit in Abteilungen (SharePoint Server 2013)
GILT FÜR:
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
Dieser Artikel enthält Anleitungen zur Leistungs- und Kapazitätsplanung für eine auf SharePoint Server 2013 basierte Lösung zur bereichsübergreifenden Zusammenarbeit. Die folgenden Themen werden in diesem Artikel behandelt:
Anforderungen für die Testumgebung, z. B. Hardware, Farmtopologie und Konfiguration
Die Testfarm-Arbeitslasten und das 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 Entwicklung eines Plans berücksichtigen müssen, damit die Leistung auch unter Spitzenlast Ihren Anforderungen entspricht.
Einführung
In diesem Artikel wird beschrieben, wie Sie Server in einer Lösung zur bereichsübergreifenden Zusammenarbeit auf Basis von SharePoint Server 2013 skalieren. Eine Lösung zur bereichsübergreifenden Zusammenarbeit ist eine SharePoint Server 2013-Bereitstellung, bei der für die zusammenarbeitsbezogenen Aktivitäten weniger Computer verwendet werden als bei einer Enterprise-Zusammenarbeitslösung. In diesem Artikel wird als Bereich eine Organisation innerhalb eines Unternehmens mit 1.000 bis 10.000 Mitarbeitern bezeichnet.
Unterschiedliche Szenarios weisen unterschiedliche Anforderungen auf. Ergänzen Sie diese Hinweise daher durch zusätzliche Tests mit Ihrer Hardware in Ihrer eigenen Umgebung. Wenn Ihr geplantes Design und die Arbeitslast der in diesem Artikel beschriebenen Umgebung entspricht, können Sie Schlussfolgerungen über die zu erwartende Leistung ziehen, wenn Sie Ihre Umgebung vertikal und horizontal skalieren.
Wichtig
Testergebnisse in diesem Artikel wurden in einer Testumgebung erzielt, in der 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 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. Sie geben jedoch Aufschluss über beobachtete Trends bei Durchsätzen, Wartezeiten und Hardwareauslastungen. Verwenden Sie die Analyse der gemessenen Daten, um Entscheidungen zur Kapazitätsplanung und Verwaltung Ihrer eigenen Farm zu treffen.
Dieser Artikel liefert Ihnen folgende Informationen:
Spezifikationen zu Hardware, Topologie und Konfiguration
Die Arbeitslast, inklusive einer Analyse der Auslastung der Farm, der Anzahl der Benutzer sowie Nutzungskenndaten
Das Dataset, wie z. B. Datenbankgrößen und Inhaltstypen
Testergebnisse und -analysen zur horizontalen Skalierung von Webservern
Bevor Sie diesen Artikel lesen, lesen Sie die folgenden Artikel, um sicherzustellen, dass Sie die wichtigsten Konzepte hinter der Kapazitätsverwaltung in Softwaregrenzen und -grenzwerte für SharePoint 2013SharePoint Server 2013 verstehen.
Glossar
Die folgende Liste enthält Definitionen für zentrale Begriffe, die in diesem Artikel vorkommen.
RPS: Requests per Second. RPS ist die Anzahl der Anforderungen, die eine Farm oder ein Server in einer Sekunde empfängt. Dies ist ein gängiges Maß für die Auslastung von Servern und Farmen.
Hinweis
Anforderungen sind etwas anderes als Seitenladevorgänge. Eine Seite enthält verschiedene Komponenten, von denen jede eine oder mehrere Anforderungen stellt, wenn die Seite vom Browser geladen wird. Beim Laden einer einzelnen Seite fallen mehrere Anforderungen an. Authentifizierungsprüfungen und Ereignisse, die kaum Ressourcen in Anspruch nehmen, werden bei RPS-Messungen normalerweise 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
In unserer Testumgebung wurde keine aktive Suchdurchforstung ausgeführt. Daher 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 (Graphnotation): Die Anzahl der Webserver, Anwendungsserver und Datenbankserver in einer Farm. 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 unsere Testumgebung 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.
Testmethoden und Anmerkungen
Da dieser Artikel auf Testergebnissen basiert, die in einer Testumgebung 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 Testumgebung.
Hardware
Im folgenden Abschnitt ist die Hardware beschrieben, die wir in dieser Testumgebung verwendet haben.
Wichtig
Wir haben Hyper-V-Hosts verwendet, um alle Webserver und Anwendungsserver in unserem Testlabor zu virtualisieren. Datenbankserver wurden nicht virtualisiert. Die Hardware der physischen Hosts und die virtuelle Hardware der VM werden in diesem Abschnitt separat beschrieben.
Hyper-V-Hosts
Für unsere Tests verwendeten wir sechs identisch konfigurierte Hyper-V-Hosts. Auf jedem Host werden ein bis zwei virtuelle Maschinen ausgeführt.
| Hosthardware | Wert |
|---|---|
|
Prozessoren |
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
Unsere Testfarm verwendet acht virtuelle Webserver. Wir verwenden außerdem einen dedizierten virtuellen Server, auf dem der verteilte Cachedienst ausgeführt wird.
Hinweis
In Produktionsumgebungen werden dedizierte Server, die den verteilten Cachedienst ausführen, normalerweise in einer Hochverfügbarkeitskonfiguration bereitgestellt. In unsere Testumgebung verwenden wir für den verteilten Cachedienst einen einzigen dedizierten Server, da Hochverfügbarkeit nicht von Bedeutung ist.
| VM-Hardware | WFE1-8 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-8: Grundlegende Verbunddienste. Dies umfasst Folgendes: SharePoint-Zeitgeberdienst, Ablaufverfolgungsdienst, Word Automation Services, Excel Services und Microsoft SharePoint Foundation Sandboxed Code Service. DC1: Verteilter Cachedienst. |
Datenbankserver
In unseren Tests verwenden wir einen physischen Datenbankserver und führten die SQL Server-Standardinstanz aus, welche die SharePoint-Datenbanken speichert. 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 einem hohen Volumen von Protokollierungsereignissen ein dedizierter Protokollierungsdatenbankserver erforderlich sein.
In unserer Testumgebung haben wir die Protokollierung eingeschränkt und die Protokollierungsdatenbank in einer separaten SQL Server-Instanz gespeichert.
| Datenbankserver - Standardinstanz | SQL Server |
|---|---|
|
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 unserer Testumgebung verwendete Topologie gezeigt.
Konfiguration
Die folgende Tabelle zeigt die erheblichen Konfigurationsänderungen, die wir am Datenbankserver in unserer Testumgebung vorgenommen haben. Diese Konfigurationsänderungen ermöglichen eine optimale Testleistung und klare Beziehungen zwischen Testparametern und Ergebnissen. Beachten Sie, dass die MAXDOP-Einstellung für SharePoint Server 2013 erforderlich ist. Die anderen Einstellungsänderungen beziehen sich nur auf unsere Testumgebung und haben möglicherweise keine Auswirkungen auf Ihre Produktionsumgebung.
| Einstellung | Wert | Hinweise |
|---|---|---|
|
Websitesammlung |
179 (insgesamt in der Umgebung) |
Die Websitesammlungen in unserer 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 von Browsern häufig angefordert werden können. |
|
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. 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 Labortests erläutert, die wir für SharePoint Server 2013 durchgeführt haben. Die Testdetails sind typisch für eine Umgebung zur bereichsübergreifenden Zusammenarbeit.
Dataset
Das Dataset, das wir für unsere Testumgebung verwendet haben, stellt eine Umgebung zur bereichsübergreifenden Zusammenarbeit dar. Dieses Dataset enthält verschiedene Websitesammlungen, Websites, Listen, Bibliotheken, Dateitypen und Dateigröß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 der im Abschnitt Übersicht beschriebenen Skalierungsmethode sortiert.
Skalierung der Webserver
In den folgenden Abschnitten werden die Testergebnisse beschrieben, die bei einer Skalierung der Anzahl der Webserver in unserer Testumgebung 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, 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.
Aufgrund der in SharePoint Server 2013 implementierten Verbesserungen bei der Zwischenspeicherung und der Datenbanknutzung ist die durchschnittliche Arbeitslast auf Datenbankserverebene gering. Wir haben festgestellt, dass es während der Tests nicht erforderlich ist, die Datenbankserver zu skalieren.
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. Für virtuelle Server sind zusätzliche Planungs- und Verwaltungsstrategien für die virtuellen Aspekte erforderlich.
Weitere Informationen zur Hyper-V-Leistungs- und Kapazitätsplanung finden Sie unter Hyper-V-Virtualisierungsanforderungen für SharePoint 2013 und Verwenden bewährter Methoden für die virtuellen SharePoint 2013-Computer und die Hyper-V-Umgebung.
Hinweis
Die Schlussfolgerungen in diesem Abschnitt 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 acht virtuelle Webserver, ein dedizierter virtueller Server für den verteilten Cachedienst (der ab vier Webserver hinzugefügt wird) und ein physischer Datenbankserver (8x1x1).
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.
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 fast 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 und die durchschnittliche Speicherauslastung bei zunehmendem RPS-Wert relativ konstant bleibt.
Die Prozessorauslastung in der Roten Zone sinkt tendenziell. Dieser Abwärtstrend zeigt, dass die durchschnittliche CPU-Auslastung des Webservers bei maximaler Last allmählich sinkt, je höher die Anzahl der Server ist.
4.) SQL Server-IOPs und CPU-Auslastung
Die folgende Darstellung zeigt, wie sich die durchschnittlichen Festplatten-IOPs (Lese-/Schreibvorgänge pro Sekunde auf die Festplatte) - sowohl insgesamt als auch nach Lese-/Schreibzugriffen aufgeteilt - und die Werte für die 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
Da zum Zeitpunkt der Tests keine Daten zur RAM-Auslastung von SQL Server zur Verfügung standen, sind diese nicht in diesem Diagramm enthalten.
Wichtig
Diese Ergebnisse für IOPS-Tests 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. Da ein höherer prozentualer Anteil der Daten auf dem Webserver zwischengespeichert wurde, sind die in diesem Abschnitt aufgeführten IOPS-Ergebnisse 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 sechs 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 Baseline-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:
Hätten wir die Testlast beim 9. Webserver erhöht, hätten höhere RPS-Werte erreicht werden können, während die Kurve bei der Serverressourcenauslastung weiterhin flach geblieben wäre.
Hätten wir die Anzahl der Webserver bei identischer Testlast weiter erhöht, 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-Werte (nach Lese- und Schreibvorgängen pro Sekunde aufgeschlüsselt) auswirkt.
CPU-Auslastung von SQL Server
Die folgende Darstellung zeigt, wie sich eine Skalierung auf die CPU-Auslastung von SQL Server auswirkt.
Siehe auch
Konzepte
Planen der Leistung in SharePoint Server 2013 Planung
Ergebnisse und Empfehlungen zu Leistungs- und Kapazitätstests (SharePoint Server 2013)