Schätzen der Leistungs- und Kapazitätsanforderungen für soziale Umgebungen (SharePoint Server 2013)
GILT FÜR:
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
Dieser Artikel enthält Informationen zu den folgenden Bereichen, um einen Leistungs- und Kapazitätsplan für ein Enterprise-Intranet „Meine Website“ und für das Social-Network-Portal zu erstellen:
Spezifikationen der Laborumgebung, wie z. B. Hardware, Farmtopologie und Konfiguration
Testfarm-Arbeitslasten und Dataset, mit dem die Testlasten generiert wurden
Testergebnisse und -analysen, die Aufschluss über die Trends hinsichtlich Durchsatz, Wartezeit und Hardwareanforderungen bei bestimmten Skalierungspunkten.
Verwenden Sie die Informationen in diesem Artikel, um die folgenden Konzepte nachvollziehen zu können:
Eigenschaften des Szenarios bei normalen und Spitzenlasten
Wie sich Leistungstrends ändern, wenn Farmservern horizontal skaliert werden
So schätzen Sie einen geeigneten Anfangspunkt für die geplante Architektur
Wichtige Faktoren zu berücksichtigende Faktoren, wenn Sie die für die Farm erforderlichen Ressourcen planen, um akzeptable Leistungsstufen bei Spitzenlasten aufrechtzuerhalten
Einführung in diese Umgebung
Unternehmen verwenden SharePoint Server 2013 häufig zum Veröffentlichen von "Meine Website" und Social-Computing-Portalen, die den Benutzerzugriff auf eine Intranetwebsite authentifiziert haben. Dieser Artikel enthält Kapazitäts- und Leistungsdaten, um die Anzahl der zu verwendenden Computer und die Computertypen zu planen, die zum Veröffentlichen von "Meine Website" und Social-Computing-Portalen in SharePoint Server 2013 erforderlich sind.
In zusätzlichen Anleitungen wird erläutert, wie Server in einer SharePoint Server 2013 Enterprise-Portallösung "Meine Website" und "Social Computing" horizontal hochskaliert werden. Durch die Kapazitätsplanung können fundierte Entscheidungen zu Hardwarekäufen und Systemkonfigurationen getroffen werden, die Ihre Lösung optimieren.
Da einzelne SharePoint Server 2013-Farmen eindeutig sind, hat jede Farm unterschiedliche Anforderungen, die von der Hardware, dem Benutzerverhalten, der Konfiguration installierter Features und vielen anderen Faktoren abhängen. Ergänzen Sie deshalb diesen Leitfaden durch zusätzliche Tests Ihrer Hardware in Ihrer eigenen Umgebung. Wenn der Aufbau und die Arbeitslasten Ihrer Umgebung der in diesem Artikel beschriebenen ähnelt, können Sie daraus anhand dieses Artikels Schlussfolgerungen zum Skalieren Ihrer Umgebung ziehen.
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 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. 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 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 z. B. Datenbankgrößen und Inhaltstypen
Testergebnisse und -analysen zur horizontalen Skalierung von Webservern
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
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.
Wichtig
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 0,5 Sekunden.
Alle Farmserver arbeiten mit einer durchschnittlichen CPU-Auslastung von weniger als 50 %.
Die Fehlerrate liegt unterhalb von 0,1 %.
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 serverseitige Wartezeit beträgt bei mindestens 75 % der Anforderungen weniger als 1 Sekunde.
Durchschnittliche Datenbankserver-CPU-Auslastung beträgt weniger als 80 %.
Die Fehlerrate liegt unterhalb von 0,1 %.
Übersicht
In diesem Abschnitt wird unser Skalierungsansatz, die Beziehung zwischen dieser Testumgebung und einer ähnlichen Fallstudien-Umgebung und Testmethodik zusammengefasst.
Skalierungsansatz
Es wird empfohlen, dass Sie die Computern in Ihrer Umgebung in der spezifischen Reihenfolge skalieren, der wir zum Skalieren unserer Testumgebung folgen. Anhand dieses Ansatzes können Sie die beste Konfiguration für die Arbeitsauslastung aussuchen.
Wir haben die Leistungstestzyklen in drei Arbeitsauslastungskategorien unterteilt. Der primäre Parameter, der die Kategoriebegrenzung bestimmt, war die Anzahl der Benutzerprofile, die bei den Benutzerprofiltests auf 10.000, 100.000 und 500.000 festgelegt wurde. Ein weiterer Parameter war die Anzahl aktiver Benutzer, die Aktionen hinsichtlich Social-Network-Features ausführen. Mit der Anzahl der Benutzer mit einem Profil und der Anzahl der aktiven Benutzer führten wir Tests zum Simulieren der Anwendungsnutzung durch, die den tatsächlichen Bereitstellungen ähneln. In der folgenden Tabelle ist der anfängliche Dataset und die Anzahl der aktiven Benutzer angegeben.
Anfänglicher Dataset
| Entität | % der Benutzer mit diesem Feature | Klein (10.000 Benutzer) | Mittel (Benutzer von 100.000) | Groß (500.000 Benutzer) |
|---|---|---|---|---|
| Anzahl der Benutzerprofile für Benutzer |
100 % |
10.000 |
100.000 |
500K |
| Anzahl der bereitgestellten "Meine Websites" |
100 % |
10.000 |
100.000 |
500K |
| Anzahl der Benutzerprofile, die Benutzerfotos enthalten |
50% |
5K |
50.000 |
250.000 |
| Anzahl der Benutzerprofile, die Beiträge enthalten |
10 % |
1K |
10.000 |
50.000 |
| Anzahl der Teams |
1,860 |
18,600 |
93K |
|
| Anzahl der aktiven Benutzer pro Tag |
10 % |
1K |
10.000 |
50.000 |
| Anzahl der aktiven Benutzer pro Stunde |
5% |
500 |
5K |
25K |
Die Tests konzentrieren sich auf die folgenden Schlüsselszenarien:
Zugriff auf Newsfeed-Seiten und andere Aktionen
Profilseite
Zugriff auf Websitefeed-Seiten und andere Aktionen
Outlook Connector für soziale Netzwerke – Synchronisierung von Aktivitätsfeeds
OneDrive-Seitenzugriff
OneDrive-Clientnutzung
Um eine realistische Szenariobereitstellung zu simulieren, wurden alle Tests in einer Datenbank ausgeführt, die bereits Daten enthielt. Das Dataset war ein Modell einer Strukturorganisation mit durchschnittlich 4-6 Benutzer pro Team und 3-4 Ebenen. Um diese Zahlen zu generieren, haben wir Datenverkehr von einer internen Website für soziale Netzwerke analysiert. In der folgenden Tabelle werden die Parameter aufgeführt, die zum Erstellen des anfänglichen Datasets verwendet wurden.
Datenmodell für die ursprüngliche Datenbank
| Beschreibung der Daten-Entität | Zahl |
|---|---|
| Durchschnittliche Anzahl der Benutzer im Team |
5 |
| Durchschnittliche Anzahl der Ebenen pro Organisation |
4 |
| Anzahl der Teams pro 1.000 Benutzer |
186 |
| Durchschnittliche Anzahl von Kollegen, denen ein Benutzer folgt |
50 |
| Anzahl der Benutzerprofileigenschaften |
93 |
Die folgende Tabelle beschreibt die Parameter im Hinblick auf Aktionen, die zu einer Datenauffüllung führen würden:
Nutzungsmerkmale
| Parameter | Anzahl oder Prozentsatz |
|---|---|
| Prozentsatz der Benutzer mit 1-3 Beiträgen |
10 % |
| Durchschnittliche Anzahl von Beiträgen pro Benutzer |
2 |
| Durchschnittliche Anzahl von Antworten pro Benutzer |
2 |
| Prozentsatz der Beiträge, die mit „Gefällt mir“ bewertet wurden |
15 % |
| Prozentsatz der Beiträge mit links |
5% |
| Prozentsatz der Beiträge mit Tags |
12% |
| Prozentsatz der Beiträge mit Erwähnungen von Benutzern |
8% |
| Prozentsatz der Beiträge mit angehängtem Bild |
5% |
Um die einzelnen Skalierungstests zu erstellen, haben wir die folgende Kombinationsmischung zu der vorherigen Datasets und der Anzahl der aktiven Benutzer angewendet:
Leseaktionen von Benutzern
| Benutzeraktion | % der Benutzer, die diese Aktion durchführen | Szenario | Feature oder URL |
|---|---|---|---|
| Navigieren zur Startseite für Meine Website |
12% |
Newsfeed |
Newsfeedseite (http://my/default.aspx) |
| Navigieren Sie zur öffentlichen Profilseite des Benutzers. |
8% |
Profil |
Profilseite (http://my/person.aspx?accountname=<Alias>) |
| Navigieren Sie zur privaten Profilseite des Benutzers. |
4% |
Profil |
Profilseite (http://my/person.aspx) |
| Automatische Synchronisierung des Aktivitätsfeeds |
32% |
Outlook Connector für soziale Netzwerke |
keine |
| Navigieren Sie zur Seite Personen, der ich folge . |
3% |
Liste der Personen, denen man folgt |
http://my/MyPeople.aspx |
| Navigieren zur Standard-Dokumentbibliothek |
6% |
OneDrive |
https://msft-my.spoppe.com/personal/<Benutzer>/Dokumente |
| Navigieren Sie zur Seite "Gefolgte Dokumente" |
3% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
| Navigieren Sie zur Seite "Gefolgte Dokumente" |
3% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
| Navigieren zur Websitefeed-Seite |
8% |
Website-Feed |
Seite "Websitefeed"< (https:// domäne>/teams/<site>/newsfeed.aspx_ |
| Alle Antworten auf einen Thread anzeigen |
1% |
Newsfeed |
Newsfeedseite (http://my/default.aspx) |
|
JedenFeed anzeigen |
3% |
Newsfeed |
Newsfeedseite (http://my/default.aspx) |
| Weitere Beiträge im Newsfeed anzeigen |
2% |
Newsfeed |
Newsfeedseite (http://my/default.aspx) |
| Anzeigen der @mentions Seite |
1% |
Newsfeed |
Newsfeedseite (http://my/default.aspx) |
| Newsfeed (Mobil) anzeigen |
1% |
Mobil |
Mobile Representational State Transfer (REST)-Aufruf |
| Kategorisierten Newsfeed anzeigen |
3% |
Mobil |
Mobile REST-Aufruf |
Benutzer-Schreibaktionen
| Benutzeraktion | Prozentsatz | Szenario | Feature oder URL |
|---|---|---|---|
| Stammbeitrag im Feed erstellen |
0.5% |
Newsfeed |
Newsfeedseite (http://my/default.aspx) |
| Einen Beitrag im Feed mit „Gefällt mir“ bewerten |
0.3% |
Newsfeed |
Newsfeedseite (http://my/default.aspx) |
| Auf einen Beitrag im Feed antworten |
0.7% |
Newsfeed |
Newsfeedseite (http://my/default.aspx) |
| Erstellen eines Beitrags im Feed mit @mention |
0.1% |
Newsfeed |
Newsfeedseite (http://my/default.aspx) |
| Stammbeitrag im Websitefeed erstellen |
0.5% |
Website-Feed |
Websitefeedseite (https://< domain>/teams/<site>/newsfeed.aspx) |
| Erstellen eines Beitrags im Websitefeed mit @mention |
0.5% |
Website-Feed |
Websitefeedseite (https://< domain>/teams/<site>/newsfeed.aspx) |
| Auf einen Beitrag im Websitefeed antworten |
0.15% |
Website-Feed |
Websitefeedseite (https://< domain>/teams/<site>/newsfeed.aspx) |
| Beitrag im Websitefeed mit einem Tag erstellen |
0.05% |
Website-Feed |
Websitefeedseite (https://< domain>/teams/<site>/newsfeed.aspx) |
OneDrive-Clientaktionen
| Benutzeraktion** | Prozentsatz | Szenario | Feature oder URL |
|---|---|---|---|
| Erste OneDrive-Synchronisierung |
0.2% |
OneDrive |
Erstsynchronisierung |
| Inkrementelle OneDrive-Synchronisierung – Herunterladen einer Datei |
0.88% |
OneDrive |
Inkrementelle Synchronisierung |
| Inkrementelle OneDrive-Synchronisierung – keine Änderungen |
8.1% |
OneDrive |
Inkrementelle Synchronisierung |
Testmethodik
Wir haben mit einer Minimalkonfiguration der SharePoint Server 2013-Farm für features für soziale Netzwerke begonnen. Wir haben eine typische Last für soziale Netzwerke auf die Testfarm angewendet und haben die Auslastung erhöht, bis wir die Ebenen der normalen und maximalen Serverkapazität nachstellen konnten. Wir haben Engpässe bei diesen Auslastungsstufen analysiert und Rechner der überladenen Rolle für die Skalierung der Farmkonfiguration hinzugefügt. Diese Ergänzung entschärfte die Engpässe in jedem Fall und eine Ansicht der Skalierbarkeitsmerkmale des Servers für ein bestimmtes Dataset bereitgestellt. Wir haben diesen Prozess für die horizontale Skalierung für drei Bereitstellungsgrößen wiederholt, um repräsentative Zusammenfassungen der Skalierbarkeitsmerkmale und Richtlinien für die Kapazitätsplanung einer SharePoint Server 2013-Farm bereitzustellen.
Spezifikationen
Dieser Abschnitt enthält ausführliche Informationen zur Hardware, Software, Topologie und Konfiguration der Testumgebung.
Wichtig
Alle Webserver und Anwendungsserver in der Testumgebung wurden mithilfe von Hyper-V-Hosts virtualisiert. Datenbankserver wurden nicht virtualisiert. Die Hardware der physischen Hosts und virtuellen Computer sind weiter unten separat beschrieben.
Hardware
Die folgende Tabelle enthält die Hardware-Spezifikationen für die Computer, die in diesem Test verwendet wurden. Diese Spezifikationen werden auch von den Front-End-Webservern erfüllt, die während mehrerer Iterationen des Tests der Serverfarm hinzugefügt wurden.
Hyper-V-Hosts
Bei den Tests wurden insgesamt drei identisch konfigurierte Hyper-V-Hosts eingesetzt. Jeder Host wurde wird auf 1-4 VMs ausgeführt.
| Host-Hardware | Wert |
|---|---|
|
Prozessor(en) |
2 Quadcore-Prozessoren mit 2,27 GHz |
|
RAM |
64 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 8 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 | Webserver |
|---|---|
|
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 |
1 Gigabit |
|
Authentifizierung |
Windows NTLM |
|
Lastenausgleichstyp |
F5 Big IP |
|
Lokal ausgeführte Dienste |
Microsoft SharePoint Foundation-Webanwendung, Microsoft SharePoint Foundation-eingehende E-Mail-Nachrichten, Microsoft SharePoint Foundation-Workflow-Timerdienst, verwalteter Metadaten-Webdienst, Benutzerprofildienst |
| VM-Hardware | Cache |
|---|---|
|
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 |
1 Gigabit |
|
Authentifizierung |
Windows-NTLM |
|
Lokal ausgeführte Dienste |
Verteilter Cache, Microsoft SharePoint Foundation-Workflow-Timerdienst |
| VM-Hardware | Suchabfrage-Komponente |
|---|---|
|
Prozessoren |
4 virtuelle Prozessoren |
|
RAM |
12 GB |
|
Betriebssystem |
Windows Server 2008 R2 SP1 |
|
Anzahl der Netzwerkadapter |
2 |
|
Geschwindigkeit der Netzwerkadapter |
1 Gigabit |
|
Authentifizierung |
Windows-NTLM |
|
Lokal ausgeführte Dienste |
Microsoft SharePoint Foundation-Webanwendung, Microsoft SharePoint Foundation-eingehende E-Mail-Nachrichten, Microsoft SharePoint Foundation-Workflow-Timerdienst, Suchabfrage- und Website-Einstellungen-Dienst, SharePoint Server-Suche |
| VM-Hardware | Suchindexkomponente |
|---|---|
|
Prozessoren |
4 virtuelle Prozessoren |
|
RAM |
12 GB |
|
Betriebssystem |
Windows Server 2008 R2 SP1 |
|
Anzahl der Netzwerkadapter |
2 |
|
Geschwindigkeit der Netzwerkadapter |
1 Gigabit |
|
Authentifizierung |
Windows-NTLM |
|
Lokal ausgeführte Dienste |
Microsoft SharePoint Foundation-Webanwendung, Microsoft SharePoint Foundation-eingehende E-Mail-Nachrichten, Microsoft SharePoint Foundation-Workflow-Timerdienst, SharePoint Server-Suche |
Datenbankserver
Ein physischer Datenbankserver, auf dem die SQL Server-Standardinstanz ausgeführt wird, die die SharePoint-Datenbanken enthält. In diesem Artikel werden die Protokollierungsdatenbank nicht verfolgt.
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 dieser Labumgebung wurde die Protokollierung eingeschränkt, und die Protokollierungsdatenbank wurde in einer separaten Instanz von SQL Server gespeichert.
Datenbankserver - Standardinstanz
|
Prozessoren |
2 Quadcore-Prozessoren mit 3,3 GHz |
|
RAM |
32 GB |
|
Betriebssystem |
Windows Server 2008 R2 SP1 |
|
Speicher und Geometrie |
Direct-Attached Storage (DAS) Internes Array mit 6 x 300 GB Datenträger mit 15.000 U/min Internes Array mit 15 x 450 GB Datenträger mit 15.000 U/min 50 x Inhaltsdaten (externes RAID10, 2 x 3-Spindeln mit jeweils 300 GB) 50 x Inhaltsprotokolle (internes RAID10, 2 x 2-Spindel mit jeweils 300 GB) 1 x temporäre Daten (internes RAID10, 2 x 2-Spindeln mit jeweils 300 GB) 1 x temporäres Protokoll (internes RAID10, 2 x 2-Spindeln mit jeweils 300 GB) |
|
Anzahl der Netzwerkadapter |
1 |
|
Geschwindigkeit der Netzwerkadapter |
1 Gigabit |
|
Authentifizierung |
Windows NTLM |
|
Softwareversion |
SQL Server 2008 R2 |
Topologie
Im der folgenden Tabelle wird die in dieser Testumgebung verwendete Topologie gezeigt:
Testumgebungstopologie
| Rolle | Kleine Bereitstellung (10.000 Benutzer) | Mittlere Bereitstellung (100.000 Benutzer) | Große Bereitstellung (500.000 Benutzer) |
|---|---|---|---|
| Webserver |
2-4 |
4-8 |
8 |
| Cache |
1 |
1-2 |
3 |
| SQL Server |
1 |
1-2 |
2 |
Testprozess
Wichtig
Die Tests modellieren nur die normal übliche Geschäftszeiten-Nutzung auf einem typischen Social-Network-Portal. Wir haben nicht die zyklischen Änderungen in benutzerseitig generiertem Datenverkehr berücksichtigt, die in Tag/Nacht-Zyklen erzeugt werden. Wir haben Timeraufträge, wie z. B. die Profilsynchronisierung und Personensuchdurchforstung, die erhebliche Ressourcen erfordern, unabhängig voneinander mit derselben Test-Arbeitsauslastung getestet, um deren Auswirkungen zu ermitteln. > Die Tests konzentrieren sich auf soziale Aktivitäten, z. B. Newsfeeds, social tagging und Lesen von Personenprofilen. Die Testkombination umfasst eine kleine Menge von typischem Teamarbeitsdatenverkehr, mit der eine Produktionsumgebung besser simuliert werden kann. Wir erwarten, dass diese Ergebnisse dabei helfen, ein separates Portal zu entwerfen, das für persönliche Websites und Features für soziale Netzwerke vorgesehen ist. > Die Testmischung enthält keinen Datenverkehr aus der Suchinhaltsdurchforstung. >
Wir haben Tests für kleine, mittelgroße und große Bereitstellungen für die Features für soziale Netzwerke durchgeführt. Zum Konfigurieren der Server-Hardware haben wir bei den minimalen Konfigurationen für die kleinste Größe begonnen, und die Testdatenbank mit dem Dataset aufgefüllt, wie im Abschnitt Skalierungsansatz beschrieben.
Wir haben Visual Studio Team System (VSTS) verwendet, um eine Arbeitsauslastung zu simulieren und eine typische Auslastung für soziale Netzwerke anzuwenden, dabei haben wir zunächst eine kleine Last auf dem Server erzeugt. Wir haben diese Last langsam erhöht und Leistungsmetriken zu allen Serverrollen erfasst, bis wir maximal RPS feststellen konnten. Dies zeichnete sich dadurch ab, dass eine Erhöhung der zugewiesenen Last in der Farm durch Server-Einschränkungsengpässe zu keiner Zunahme in der ausgeführten RPS-Ausgabe führte.
Aus diesen erfassten Metriken haben wir grüne Zone und rote Zonen definiert, die den Status bei normaler und voller Last des VM-Servers bei einer bestimmten Computerkonfiguration darstellen. Anschließend haben wir eine gleichbleibende Auslastung auf die grüne und rote Zone angewendet, um bei diesen Lasten die Leistungsmetriken zu analysieren. Dadurch wird eine Serverstatus- und Leistungsdarstellung des VM-Servers unter den folgenden Bedingungen beim Laden für jede Topologiekonfiguration bereitgestellt.
Nachdem wir die Auslastungsmerkmale der grünen und roten Zone erläutert haben und die Skalierungskurve für jede Topologie, haben wir die Skalierungsengpässe ermittelt, durch die RPS eingeschränkt ist. Im Falle der Arbeitslasten in sozialen Netzwerken war das typischerweise die Webserver-CPU für kleine Datasets. Bei größeren Datasets konnten wir außerdem Druck auf den Speicher an den verteilten Cache-Knoten feststellen. Wir haben virtuelle Server der überladenen Rolle zur Konfiguration hinzugefügt, um Engpässe in jedem Fall zu vermeiden und mit dem Skalierungsprozess fortzufahren. Dann wiederholten wir die Analyse der Leistungstrends und die Konformität mit Definitionen für die grüne und rote Zone bei den einzelnen Konfigurationsgrößen, bis wir die Anforderungen für eine bestimmte Bereitstellungsgröße erreicht hatten.
Nachdem wir die Größe jeder Bereitstellung nachvollziehen konnten, haben wir die Testfarm auf die kleinste Konfiguration der nächst größeren Größe neu konfiguriert, das Dataset wie im Abschnitt Skalierungsansatz beschrieben aufgefüllt, den Analyse-/Skalierungsprozesszyklus wiederholt, und die Skalierungsmerkmale der einzelnen Datasetgrößen gemessen.
Ergebnisse und Analysen
In diesem Abschnitt werden die für die drei Bereitstellungsgrößen gemessenen Ergebnisse aufgeführt. Insbesondere werden daran die Auswirkungen der Skalierung der Serverfarm durch das Hinzufügen von Webservern in der RPS der grünen und roten Zone sowie der durchschnittlichen CPU-Auslastung aufgezeigt.
Die folgenden Trends konnten konsistent für alle drei Bereitstellungsgrößen beobachtet werden:
Die RPS der roten und grünen Zone RPS nimmt linear mit der Anzahl virtueller Webserver zu.
Der primäre Engpass bei allen getesteten Konfigurationen war die Webserver-CPU.
In der roten Zone steigt beim Hinzufügen der Webserver und Erhöhen der Last die Wartezeit geringfügig. Dies wird durch zusätzlichen Druck auf SQL Server und den Verteilten Cachedienst (der auf allen Webservern in der Testfarm ausgeführt wird) verursacht.
Darüber hinaus nimmt die durchschnittliche CPU-Auslastung auf SQL Server- und Verteilten Cachecomputern zu, wenn die Anzahl der Webserver zunimmt. Dies wird durch zusätzliche Zwischenspeicherungslast für den in SQL Server und den Verteilten Cachedienst verursacht.
Die Wartezeit in der grünen Zone bleibt durch das Erhöhen der Webserver relativ gering. Das liegt daran, dass die Webserver auf der Ebene der grünen Zone nicht überlastet werden.
Ergebnisse im kleinen Maßstab
Das folgende Diagramm veranschaulicht, wie sich das Erhöhen der Anzahl der Webserver auf RPS für grüne und rote Zonen auswirkt.
Das folgende Diagramm veranschaulicht, wie sich das Erhöhen der Anzahl der Webserver auf die Wartezeit für die grüne und rote Zone auswirkt.
Das folgende Diagramm veranschaulicht, wie sich das Erhöhen der Anzahl der Webserver auf die durchschnittliche CPU-Auslastung für die grüne und rote Zone auswirkt.
Ergebnisse im mittleren Maßstab
Das folgende Diagramm veranschaulicht, wie sich das Erhöhen der Anzahl der Webserver auf RPS für grüne und rote Zonen auswirkt.
Das folgende Diagramm veranschaulicht, wie sich das Erhöhen der Anzahl der Webserver auf die Wartezeit für die grüne und rote Zone auswirkt.
Das folgende Diagramm veranschaulicht, wie sich das Erhöhen der Anzahl der Webserver auf die durchschnittliche CPU-Auslastung für die grüne und rote Zone auswirkt.
Ergebnisse im großen Maßstab
Das folgende Diagramm veranschaulicht, wie sich das Erhöhen der Anzahl der Webserver auf RPS für grüne und rote Zonen auswirkt.
Das folgende Diagramm veranschaulicht, wie sich das Erhöhen der Anzahl der Webserver auf die Wartezeit für die grüne und rote Zone auswirkt.
Das folgende Diagramm veranschaulicht, wie sich das Erhöhen der Anzahl der Webserver auf die durchschnittliche CPU-Auslastung für die grüne und rote Zone auswirkt.
Wenn die Anzahl der Webservern zunimmt, treten folgende Ereignisse auf:
Durchschnittliche CPU-Auslastung für SQL Server- und Verteilte Cacheknoten aufgrund der zusätzlichen Belastung dieser gemeinsam genutzten Ressourcen.
Die durchschnittliche CPU-Auslastung des Webservers in der roten Zone nimmt leicht ab, da sich der Engpass leicht auf SQL Server- und Verteilte Cache-Computer verlagert.
Die durchschnittliche Webserver-CPU-Auslastung in der grünen Zone bleibt konstant, da die Server auf empfohlenen Auslastungsstufen gehalten werden.
Empfehlungen
Eine erfolgreiche SharePoint Server 2013-Bereitstellung in sozialen Netzwerken, gemessen an der Leistung, hängt von den folgenden Faktoren ab:
Die Anzahl der aktiven Benutzer, die Sie unterstützen möchten
Die erwartete Transaktionskombination von Lese- und Schreibvorgängen
Die Verteilung der Last auf die Farmserver
Die erwartete Anzahl der aktiven Benutzer ist ein wichtiger Faktor zum Ermitteln der Anzahl der Server, die Sie in der Topologie haben sollten. Die Anzahl der aktiven Benutzer bestimmt auch die Zusammensetzung des Hostings der verschiedenen Dienste, die für das soziale Szenario auf den Servern aktiviert werden müssen.
Obwohl in unseren Tests ein typisches Dataset verwendet und die Lastkomplexität angewendet wurde, die Sie in einer realen Kundenbereitstellung erwarten könnten, ist jede Bereitstellung einzigartig. Beim Planen des Aufwands für die Kapazität sollte die erwarteten Verwendungsmerkmale, die Feature-Konfiguration und die Hardware-Ressourcenverfügbarkeit. Einige Faktoren, die eine erhebliche Auswirkung oder Veränderung der Kapazitätszahlen haben, lauten wie folgt:
Ein Muster mit erhöhter E-Mail-Nutzung erhöht die Auslastung, die der Outlook Connector für soziale Netzwerke generiert.
Ein erheblicher Anstieg des Prozentsatzes der Schreibaktionen (z. B. eine Zunahme des Taggings oder @mention) des Transaktionsmixes kann die Last auf dem Datenbankserver erhöhen.
Sie können Webserver hinzufügen oder entfernen, um die CPU-Last zwischen Webservern, SQL Server und Verteilten Cacheknoten auszugleichen.
Befolgen Sie sorgfältig die Standardkonfigurationsanleitung für SharePoint Server 2013, um eine optimale Leistung zu erzielen. Überlegungen, die speziell für Transaktionen in sozialen Netzwerken gelten:
Separate physische Datenträger für Profile DB : Aufgrund der hohen Datenträgernutzung, die transaktionen in sozialen Netzwerken für Profile DB haben können, wird empfohlen, Profile DB auf einem eigenen Satz physischer Datenträger auf dem Server zu verwenden, auf dem SQL Server ausgeführt wird.
Speicheranforderungen für die Benutzerprofildienstanwendung : Die Benutzerprofildienstanwendung befindet sich auf Front-End-Webservern und ist stark von ihrem In-Memory-Cache abhängig. Stellen Sie sicher, dass die Front-End-Webserver über ausreichend RAM verfügen, um die vielen Datenanfragen zwischenspeichern zu können. Der empfohlene Mindestarbeitsspeicher beträgt 12 GB pro Front-End-Webserver.
Arbeitsspeicheranforderungen für verteilte Cache-Server – Features für soziale Netzwerke, insbesondere Mikroblogging, hängen stark davon ab, ob ausreichender und stabiler, verteilter Cache-Speicher. Situationen mit nicht genügend Arbeitsspeicher auf diesen Computern können die Kapazität der SharePoint-Farm beeinträchtigen, während dieser Cache aufgefüllt wird. Wir empfehlen daher, dass Sie die Server so konfigurieren, dass sie den verteilten Cache mit mindestens 12 GB RAM hosten, und bei Bedarf auf Grundlage der Gesamtanzahl der Benutzer in die Bereitstellung skaliert werden.
Die SharePoint Server 2013-Bereitstellung für soziale Netzwerke macht es obligatorisch, eine persönliche Website für jeden Benutzer bereitzustellen, der Features für soziale Netzwerke verwenden möchte. Planen Sie das Wachstum der Erstellung persönlicher Websitesammlungen auf der Ebene der Inhaltsdatenbank. Weitere Informationen zum Skalieren persönlicher Websitesammlungen finden Sie unter Software boundaries and limits for SharePoint 2013.
Siehe auch
Konzepte
Planen der Leistung in SharePoint Server 2013