Schätzen der Leistungs- und Kapazitätsanforderungen für soziale Umgebungen (SharePoint Server 2013)
**Gilt für:**SharePoint Server 2013
**Letztes Änderungsdatum des Themas:**2017-08-25
Zusammenfassung: In diesem Artikel wird erklärt, wie sich die Anzahl und Typen von Computern ermitteln lässt, die für einen Kapazitätsplan für eine Website vom Typ "Meine Website" und ein Social-Network-Portal auf Grundlage von SharePoint Server 2013 erforderlich sind.
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
Inhalt dieses Artikels:
Einführung in diese Umgebung
Glossar
Übersicht
Spezifikationen
Ergebnisse und Analysen
Einführung in diese Umgebung
Unternehmen verwenden oft SharePoint Server 2013 Meine Website und soziale Netzwerke Portale, die authentifizierten Benutzerzugriff auf Intranet-Website veröffentlichen. Dieser Artikel enthält die Kapazität und Leistung Daten, mit denen planen, die Anzahl der zu verwendenden Computer und die Typen von Computern, die zum Veröffentlichen von Meine Website und soziale Netzwerke Portalen in SharePoint Server 2013 erforderlich sind.
Zusätzliche Hinweise erläutert zur horizontalen Skalierung der Server in einer SharePoint Server 2013 Enterprise Meine Website und soziale Netzwerke Portal-Lösung. Planen der Kapazität informiert Entscheidungen im Hinblick auf Hardware zum Kauf und System-Konfigurationen, die Ihre Lösung zu optimieren.
Da einzelne SharePoint Server 2013 Farmen eindeutig sind, hat jede Farm verschiedene Anforderungen, die Hardware, Benutzerverhalten, die Konfiguration der installierten Features und viele andere Faktoren abhängig sind. Aus diesem Grund ergänzen dieser Anleitung durch zusätzliche Tests auf Ihrer eigenen Hardware in Ihrer Umgebung. Wenn der geplanten Entwurf und die Arbeitslast ähnelt die in diesem Artikel beschriebenen Umgebung, können in diesem Artikel Sie dazu, wie Sie für die horizontale Skalierung die Umgebung Schlussfolgerungen 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
Bevor Sie diesen Artikel lesen, lesen Sie die folgenden Artikel, um sicherzustellen, dass Sie die wichtigsten Konzepte hinter Capacity Management in SharePoint Server 2013 verstehen.
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 % |
10K |
100K |
500K |
Anzahl der bereitgestellten "Meine Websites" |
100 % |
10K |
100K |
500K |
Anzahl der Benutzerprofile, die Benutzerfotos enthalten |
50 % |
5K |
50K |
250K |
Anzahl der Benutzerprofile, die Beiträge enthalten |
10 % |
1K |
10K |
50K |
Anzahl der Teams |
1,860 |
18,600 |
93K |
|
Anzahl der aktiven Benutzer pro Tag |
10 % |
1K |
10K |
50K |
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 for Business Zugriff auf Seiten
OneDrive for Business 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 | Anzahl |
---|---|
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 |
Newsfeed-Seite (http://my/default.aspx) |
Navigieren Sie zu der öffentlichen Profilseite des Benutzers |
8 % |
Profil |
Profilseite (http://my/person.aspx?accountname=<alias>) |
Navigieren Sie zu 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 zu der Seite Personen, denen ich folge |
3 % |
Liste der Personen, denen man folgt |
http://my/MyPeople.aspx |
Navigieren zur Standard-Dokumentbibliothek |
6 % |
OneDrive for Business |
https://msft-my.spoppe.com/personal/<user>/Documents |
Navigieren Sie zur Seite "Gefolgte Dokumente" |
3 % |
OneDrive for Business |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
Navigieren Sie zur Seite "Gefolgte Dokumente" |
3 % |
OneDrive for Business |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
Navigieren zur Websitefeed-Seite |
8 % |
Website-Feed |
Websitefeed-Seite (https://<domain>/teams/<site>/newsfeed.aspx_ |
Alle Antworten auf einen Thread anzeigen |
1 % |
Newsfeed |
Newsfeed-Seite (http://my/default.aspx) |
JedenFeed anzeigen |
3 % |
Newsfeed |
Newsfeed-Seite (http://my/default.aspx) |
Weitere Beiträge im Newsfeed anzeigen |
2 % |
Newsfeed |
Newsfeed-Seite (http://my/default.aspx) |
@mentions-Seite anzeigen |
1 % |
Newsfeed |
Newsfeed-Seite (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 |
Newsfeed-Seite (http://my/default.aspx) |
Einen Beitrag im Feed mit „Gefällt mir" bewerten |
0.3% |
Newsfeed |
Newsfeed-Seite (http://my/default.aspx) |
Auf einen Beitrag im Feed antworten |
0.7% |
Newsfeed |
Newsfeed-Seite (http://my/default.aspx) |
Beitrag mit @mention im Feed erstellen |
0.1% |
Newsfeed |
Newsfeed-Seite (http://my/default.aspx) |
Stammbeitrag im Websitefeed erstellen |
0.5% |
Website-Feed |
Websitefeed-Seite (https://<domain>/teams/<site>/newsfeed.aspx) |
Beitrag mit @mention im Websitefeed erstellen |
0.5% |
Website-Feed |
Websitefeed-Seite (https://<domain>/teams/<site>/newsfeed.aspx) |
Auf einen Beitrag im Websitefeed antworten |
0.15% |
Website-Feed |
Websitefeed-Seite (https://<domain>/teams/<site>/newsfeed.aspx) |
Beitrag im Websitefeed mit einem Tag erstellen |
0.05% |
Website-Feed |
Websitefeed-Seite (https://<domain>/teams/<site>/newsfeed.aspx) |
OneDrive for Business-Clientaktionen
Benutzeraktion | Prozentsatz | Szenario | Feature oder URL |
---|---|---|---|
OneDrive for Business-Erstsynchronisierung |
0.2% |
OneDrive for Business |
Erstsynchronisierung |
OneDrive for Business inkrementelle Synchronisierung - Download einer Datei |
0.88% |
OneDrive for Business |
Inkrementelle Synchronisierung |
OneDrive for Business inkrementelle Synchronisierung - keine Änderungen |
8.1% |
OneDrive for Business |
Inkrementelle Synchronisierung |
Testmethodik
Wir beginnen mit einer Farmkonfiguration minimale SharePoint Server 2013 für Features für soziale Netzwerke. Wir eine charakteristische für soziale Netzwerke Last auf die testfarm angewendet und die Last erhöht, bis wir Ebenen der normalen und der maximalen Kapazität beobachtet. Wir analysiert Engpässen bei diesen Ebenen laden und hinzugefügten Rechner der überladenen Rolle zur horizontalen Skalierung der Konfiguration einer Farm. Dieser Zusatz Engpässe in jedem Fall überwinden und eine Ansicht der Skalierbarkeit Merkmale des Servers für ein bestimmtes Dataset bereitgestellt. Dieser Prozess Skalierung für drei bereitstellungsgrößen repräsentative Übersicht über die Skalierbarkeit Merkmale einer SharePoint Server 2013 Farm bereitzustellen und Richtlinien wiederholt für die kapazitätsplanung.
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 führt die SQL Server-Standardinstanz aus, auf dem sich die SharePoint-Datenbanken befinden. 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 Laborumgebung war die Protokollierung eingeschränkt, und die Protokollierungsdatenbank wurde in einer separaten SQL Server-Instanz 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 Vorgänge für soziale Netzwerke, wie z. B. Newsfeeds, thematische Kategorien und das 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 Testkombination umfasst 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. Das liegt an dem zusätzlichen Druck auf den SQL Server und den verteilten Cachedienst (der auf allen Webservern in der Testfarm ausgeführt wird).
Außerdem nimmt die durchschnittliche CPU-Auslastung auf dem SQL Server und den verteilten Cache-Computern bei der Erhöhung der Webserver zu. Das liegt an der zusätzlichen Zwischenspeicherungsauslastung auf dem SQL Server und durch den verteilten Cachedienst.
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:
Die durchschnittliche CPU-Auslastung für SQL Server und verteilte Cache-Knoten erhöht sich aufgrund der zusätzlichen Belastung für diese gemeinsam genutzten Ressourcen.
Die durchschnittliche Server-CPU-Auslastung in der rote Zonen verringert sich geringfügig, da sich die Engpässe etwas auf die SQL Server- und verteilten Cache-Computer verlagern.
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 für soziale Netzwerke Bereitstellung hängt durch die Leistung gemessen auf 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 den Aufbau des Hostings der verschiedenen Dienste, die erforderlich sind, um das Szenario für soziale Netzwerke auf den Servern zu aktivieren.
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.
Eine deutliche Zunahme des Prozentsatzes der Schreibaktionen (z. B. eine Zunahme der Kategorien oder @mention) in der Transaktionskombination kann die Last auf dem Datenbankserver erhöhen.
Sie können Webserver hinzufügen oder entfernen, um die CPU-Last zwischen den Webservern, SQL Server, und verteilten Cache-Knoten auszugleichen.
Folgen Sie standard SharePoint Server 2013 Konfiguration Anleitung für eine optimale Leistung sorgfältig. Aspekte, die speziell für soziale Transaktionen Bedeutung lauten wie folgt:
Trennen von Festplatten für Profile DB – Aufgrund der hohen Datenträgerauslastung, die Transaktionen in sozialen Netzwerken in Profile DB aufweisen können, empfiehlt es sich, Profile DB auf einem eigenen Satz von Festplatten auf dem Server zu belassen, auf dem SQL Server ausgeführt wird.
Arbeitsspeicheranforderungen für die Benutzerprofil-Dienstanwendung – Die Benutzerprofildienst-Anwendung befindet sich auf den Front-End-Webservern und hängt stark vom In-Memory-Cache ab. 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 für soziale Netzwerke-Bereitstellung vereinfacht obligatorisch zum Bereitstellen einer persönlichen Websites für jeden Benutzer, die Features für soziale Netzwerke verwenden möchte. Planen Sie die Vergrößerung für die Erstellung der persönlichen Websitesammlungen auf der Ebene der Inhaltsdatenbank. Weitere Informationen dazu, wie Sie für die horizontale Skalierung persönlichen Websitesammlungen finden Sie unter Softwarebeschränkungen und -grenzen für SharePoint 2013.