Schätzen von Leistungs- und Kapazitätsanforderungen für Umgebungen zur Zusammenarbeit in Abteilungen (SharePoint Server 2013)

 

**Gilt für:**SharePoint Server 2013 Enterprise, SharePoint Server 2013 Standard

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

Zusammenfassung: Verwenden von Testergebnissen und Empfehlungen, um Leistungs- und Kapazitätsanforderungen für eine Umgebung zur bereichsübergreifenden Zusammenarbeit für SharePoint Server 2013 abzuschätzen.

Dieser Artikel enthält Hinweise zur Informationen zur Leistungs- und kapazitätsplanung für eine Zusammenarbeit von Abteilungen-Lösung, die auf SharePoint Server 2013 basiert. In diesem Artikel wird die folgenden Informationen enthalten:

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

Inhalt dieses Artikels:

• Einführung in diese Umgebung

• Glossar

• Übersicht

• Spezifikationen

• Ergebnisse und Analysen

Einführung

In diesem Artikel wird beschrieben, wie Skalieren von Servern in einer SharePoint Server 2013 Zusammenarbeit von Abteilungen-Lösung. Eine Lösung für die Zusammenarbeit von Abteilungen ist eine SharePoint Server 2013-Bereitstellung, die weniger als eine Enterprise-Lösung für die Zusammenarbeit collaborative Aktivitäten beteiligt Computer hat. In diesem Artikel wird davon ausgegangen, dass eine Abteilung innerhalb eines Unternehmens einer Organisation ist, die 1.000 und 10.000 Mitarbeiter verfügt.

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 liefern. 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 Konzepten bei der kapazitätsverwaltung in Softwarebeschränkungen und -grenzen für SharePoint 2013SharePoint Server 2013 verstehen.

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

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

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 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): Die Anzahl der in einer Farm befindlichen Web-, Anwendungs- und Datenbankserver. So bedeutet 10x1x1 z. B., 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.

Host-Hardware	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, wie: SharePoint-Timerdienst, Ablaufverfolgungsdienst, Word Automation Services, Excel Services und Microsoft SharePoint Foundation-Sandkasten-Codedienst. 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 erhebliche konfigurationsänderungen, die wir in unserer testumgebung mit dem Datenbankserver vorgenommen. Dieser konfigurationsänderungen zu Tests eine optimale Leistung und Beziehungen zwischen Testparametern und Ergebnissen deaktivieren. Beachten Sie, dass die MAXDOP-Einstellung für die SharePoint Server 2013 erforderlich ist. Die anderen ändert sich die Einstellung nur gelten für unsere testumgebung und wirkt sich möglicherweise nicht der produktionsumgebung.

Einstellung	Wert	Anmerkungen
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 auf die Instanzen, die SharePoint Server 2013 Inhaltsdatenbanken enthalten SQL Server festgelegt. Der Standardwert ist 0, wodurch SQL Server den maximalen Grad an Parallelität bestimmen. SharePoint Server 2013 erfordert MAXDOP für SQL Server Instanzen auf 1 festgelegt werden soll, die SharePoint Server 2013 Datenbanken enthalten. 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 wird erläutert, die Labortests, die wir für SharePoint Server 2013 ausgefü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 ü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.

• Aufgrund der Verbesserungen in Zwischenspeichern und Datenbank Verwendungsmerkmale in SharePoint Server 2013 ist die durchschnittliche Belastung der Server-Datenbankschicht niedrig. Wir festgestellt, dass bei unseren Tests nicht den Datenbankservern skalieren war.

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

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.

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-Werte (nach Lese- und Schreibvorgängen pro Sekunde 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.

   

See also

Planen der Leistung in SharePoint Server 2013 Planung
Ergebnisse und Empfehlungen zu Leistungs- und Kapazitätstests (SharePoint Server 2013)
Abschätzen der Leistungs- und Kapazitätsanforderungen für Unternehmensumgebungen für eine Zusammenarbeit über das Intranet (SharePoint Server 2013)