Leistungstests für SharePoint Server 2013
GILT FÜR:2013 2016 2019 Subscription Edition SharePoint in Microsoft 365
In diesem Artikel wird beschrieben, wie Sie die Leistung von SharePoint Server 2013 testen. Die Test- und Optimierungsphase ist eine wichtige Komponente eines effektiven Kapazitätsmanagements. Sie sollten neue Architekturen testen, bevor Sie sie in der Produktion bereitstellen, und Sie sollten Akzeptanztests mit den bewährten Methoden für die Überwachung durchführen, um sicherzustellen, dass die von Ihnen entworfenen Architekturen die Leistungs- und Kapazitätsziele erreichen. Auf diese Weise können Sie potenzielle Engpässe identifizieren und optimieren, bevor sie sich auf Benutzer in einer Livebereitstellung auswirken. Wenn Sie ein Upgrade von einer Office SharePoint Server 2007-Umgebung durchführen und Planen, Architekturänderungen vorzunehmen, oder die Benutzerauslastung der neuen SharePoint Server 2013-Features schätzen, sollten Sie unbedingt testen, um sicherzustellen, dass Ihre neue SharePoint Server 2013-basierte Umgebung die Leistungs- und Kapazitätsziele erfüllt.
Nachdem Sie die Umgebung getestet haben, können Sie die Testergebnisse analysieren, um zu ermitteln, welche Änderungen erforderlich sind, damit die in Schritt 1: Modellierung unter Kapazitätsplanung für SharePoint Server 2013 von Ihnen festgelegten Zielvorgaben für Leistung und Kapazität umgesetzt werden.
Dies sind die empfohlenen Unterschritte, die Sie für die Vorproduktion ausführen sollten:
Erstellen der Testumgebung, mit der die von Ihnen in Schritt 2: Entwurfserstellung entworfene Ausgangsarchitektur imitiert wird
Füllen Sie den Speicher mit dem Dataset oder einem Teil des Datasets auf, das Sie in Schritt 1: Modellierung identifiziert haben.
Belasten Sie das System mit synthetischer Last, welche die Arbeitslast darstellt, die Sie Schritt 1: Modellierung identifiziert haben.
Führen Sie Tests aus, analysieren Sie Ergebnisse, und optimieren Sie Ihre Architektur.
Bereitstellen der optimierten Architektur im Rechenzentrum und Einführen einer Pilotbereitstellung mit einer kleineren Benutzergruppe
Analysieren Sie die Pilotergebnisse, identifizieren Sie mögliche Engpässe, und optimieren Sie die Architektur. Führen Sie bei Bedarf einen erneuten Test durch.
Bereitstellen für die Produktionsumgebung
Bevor Sie diesen Artikel lesen, sollten Sie Capacity management and sizing overview for SharePoint Server 2013 lesen.
Erstellen eines Testplans
Stellen Sie sicher, dass im Plan Folgendes berücksichtigt wurde:
Es ist Hardware vorhanden, die dafür vorgesehen ist, unter den erwarteten Zielvorgaben für die Leistung in der Produktion eingesetzt zu werden. Messen Sie die Leistung von Testsystemen immer vorsichtig.
Wenn Sie über benutzerdefinierten Code oder eine benutzerdefinierte Komponente verfügen, ist es wichtig, dass Sie die Leistung dieser Komponenten isoliert testen, um ihre Leistung und Stabilität zu überprüfen. Nachdem sie stabil sind, sollten Sie das System mit diesen installierten Komponenten testen und die Leistung mit der Farm vergleichen, ohne dass sie installiert sind. Benutzerdefinierte Komponenten sind häufig eine der Hauptursachen für Leistungs- und Zuverlässigkeitsprobleme in Produktionssystemen.
Kennen Sie das Ziel Ihrer Tests. Verstehen Sie im Voraus, was Ihre Testziele sind. Soll die Leistung einiger neuer benutzerdefinierter Komponenten überprüft werden, die für die Farm entwickelt wurden? Ist es zu sehen, wie lange es dauert, einen Satz von Inhalten zu durchforsten und zu indizieren? Soll ermittelt werden, wie viele Anforderungen pro Sekunde Ihre Farm unterstützen kann? Während eines Tests kann es viele verschiedene Ziele geben, und der erste Schritt bei der Entwicklung eines guten Testplans besteht darin, zu entscheiden, was Ihre Ziele sind.
Sie sollten wissen, womit Sie das Testziel messen müssen. Wenn Sie z. B. die Durchsatzkapazität Ihrer Farm messen möchten, sollten Sie die RPS- und Seitenlatenz messen. Wenn Sie die Suchleistung messen, sollten Sie die Durchforstungszeit und die Indizierungsraten für Dokumente messen. Wenn das Testziel klar ist, können Sie klar definieren, welche Key Performance Indicators Sie überprüfen müssen, um die Tests auszuführen.
Erstellen der Testumgebung
Nachdem Sie die Testziele festgelegt, die Messungen definiert und die Kapazitätsanforderungen für die Farm ermittelt haben (Schritte 1 und 2 dieses Prozesses), besteht das nächste Ziel darin, die Testumgebung zu entwerfen und zu erstellen. Der Aufwand für die Erstellung einer Testumgebung wird oft unterschätzt. Die Produktionsumgebung sollte dabei so genau wie möglich dupliziert werden. Beim Entwerfen der Testumgebung sollten Sie unter anderem diese Features und Funktionen berücksichtigen:
Authentifizierung: Entscheiden Sie, ob die Farm Active Directory Domain Services (AD DS), formularbasierte Authentifizierung (und falls ja, mit welchem Verzeichnis), anspruchsbasierte Authentifizierung usw. verwendet wird. Unabhängig davon, welches Verzeichnis Sie verwenden, wie viele Benutzer benötigen Sie in Ihrer Testumgebung und wie erstellen Sie sie? Wie viele Gruppen oder Rollen benötigen Sie, und wie werden Sie sie erstellen und auffüllen? Außerdem müssen Sie sicherstellen, dass Ihren Authentifizierungsdiensten genügend Ressourcen zugeordnet sind, damit diese während der Tests nicht zu einem Engpass werden.
DNS: Kennen Sie die Namespaces, die Sie während Der Tests benötigen. Ermitteln Sie, welche Server auf diese Anforderungen reagieren, und stellen Sie sicher, dass Sie einen Plan mit den IP-Adressen enthalten haben, die von welchen Servern verwendet werden und welche DNS-Einträge Sie erstellen müssen.
Lastenausgleich: Angenommen, Sie verwenden mehr als einen Server (was Sie normalerweise oder wahrscheinlich nicht über genügend Auslastung verfügen würden, um Auslastungstests zu rechtfertigen), benötigen Sie eine Art Lastenausgleichslösung. Dabei kann es sich um ein Hardwaregerät für den Lastenausgleich handeln, oder Sie können einen Softwarelastenausgleich wie den Windows-Netzwerklastenausgleich verwenden. Ermitteln Sie, was Sie verwenden werden, und notieren Sie alle Konfigurationsinformationen, die Sie benötigen, um sie schnell und effizient einzurichten. Beachten Sie auch, dass Auslastungstest-Agents in der Regel versuchen, die Adresse nur alle 30 Minuten in eine URL aufzulösen. Dies bedeutet, dass Sie keine lokale Hostdatei oder kein Roundrobin-DNS für den Lastenausgleich verwenden sollten, da die Test-Agents wahrscheinlich für jede einzelne Anforderung auf denselben Server wechseln, anstatt alle verfügbaren Server abzuwägen.
Testserver: Wenn Sie Ihre Testumgebung planen, müssen Sie nicht nur die Server für die SharePoint Server 2013-Farm planen, sie müssen auch die Computer planen, die zum Ausführen der Tests erforderlich sind. In der Regel umfasst dies mindestens drei Server; möglicherweise mehr erforderlich sein. Wenn Sie Visual Studio Team System (Team Test Load Agent) für die Tests verwenden, wird ein Computer als Auslastungstestcontroller verwendet. In der Regel gibt es zwei oder mehr Computer, die als Auslastungstest-Agents verwendet werden. Bei den Agents handelt es sich um die Computer, die die Anweisungen des Testcontrollers zum Testen übernehmen und die Anforderungen an die SharePoint Server 2013-Farm ausgeben. Die Testergebnisse selbst werden auf einem SQL Server-basierten Computer gespeichert. Sie sollten nicht denselben SQL Server-basierten Computer verwenden, der für die SharePoint Server 2016-Farm verwendet wird, da das Schreiben der Testdaten die verfügbaren SQL Server-Ressourcen für die SharePoint Server 2013-Farm verzerrt. Außerdem müssen Sie Ihre Testserver beim Ausführen der Tests auf die gleiche Weise überwachen wie die Server in der SharePoint Server 2013-Farm oder Domänencontroller usw., um sicherzustellen, dass die Testergebnisse repräsentativ für die Farm sind, die Sie einrichten. Manchmal können die Lade-Agents oder der Controller selbst zum Engpass werden. Wenn dies der Fall ist, ist der Durchsatz, den Sie in Ihrem Test sehen, in der Regel nicht die maximale Farm unterstützen kann.
SQL Server: Befolgen Sie in der Testumgebung die Anweisungen in den Abschnitten "Konfigurieren von SQL Server" und "Überprüfen und Überwachen des Speichers und der SQL Server-Leistung" im Artikel Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server).
Datasetüberprüfung: Denken Sie bei der Entscheidung, für welche Inhalte Sie Tests ausführen möchten, daran, dass Sie im besten Fall Daten aus einem vorhandenen Produktionssystem verwenden. Beispielsweise können Sie Ihre Inhaltsdatenbanken aus einer Produktionsfarm sichern und in Ihrer Testumgebung wiederherstellen und dann die Datenbanken anfügen, um den Inhalt in die Farm zu übertragen. Wenn Sie Tests anhand von erstellten oder Beispieldaten ausführen, besteht das Risiko, dass Ihre Ergebnisse aufgrund von Unterschieden in Ihrem Inhaltskorpus verzerrt werden.
Wenn Sie dennoch Beispieldaten erstellen müssen, sollten Sie dabei ein paar Punkte bedenken:
Alle Seiten sollten veröffentlicht werden; nichts sollte ausgecheckt werden.
Die Navigation sollte realistisch sein; erstellen Sie nicht mehr Inhalte, als Sie erwartungsgemäß in der Produktion verwenden würden.
Sie sollten eine Vorstellung von den Anpassungen haben, die von der Produktionswebsite verwendet werden. Beispielsweise sollten Gestaltungsvorlagen, Stylesheets, JavaScript usw. in der Testumgebung so nah wie möglich an der Produktionsumgebung implementiert werden.
Legen Sie fest, wie viele SharePoint-Gruppen und/oder Berechtigungsstufen Sie benötigen und wie Sie ihnen Benutzer zuordnen möchten.
Überlegen Sie sich, ob Sie Profilimporte vornehmen müssen und wie lange dies dauern wird.
Ermitteln Sie, ob Sie Benutzergruppen benötigen und wie Sie sie erstellen und auffüllen.
Bestimmen Sie, ob Sie weitere Suchinhaltsquellen benötigen und was Sie für deren Erstellung benötigen. Wenn Sie sie nicht erstellen müssen, ermitteln Sie, ob Sie über den Netzwerkzugriff verfügen, um sie durchforsten zu können.
Ermitteln Sie, ob Sie über genügend Beispieldaten verfügen – Dokumente, Listen, Listenelemente usw. Wenn dies nicht der Fall ist, erstellen Sie einen Plan für die Erstellung dieser Inhalte.
Sie haben einen Plan für genügend eindeutigen Inhalt, um die Suche angemessen zu testen. Ein häufiger Fehler besteht darin, dasselbe Dokument – vielleicht hunderte oder sogar tausende Male – in verschiedene Dokumentbibliotheken mit unterschiedlichen Namen hochzuladen. Dies kann sich auf die Suchleistung auswirken, da der Abfrageprozessor eine ordinate Zeit für die Erkennung von Duplikaten aufwendet, die er andernfalls in einer Produktionsumgebung mit echtem Inhalt nicht hätte.
Erstellen von Tests und Tools
Nachdem die Testumgebung funktionsfähig ist, ist es an der Zeit, die Tests zu erstellen und zu optimieren, die verwendet werden, um die Leistungskapazität der Farm zu messen. In diesem Abschnitt wird gelegentlich speziell auf Visual Studio Team System (Team Test Load Agent) verwiesen, aber viele Konzepte sind unabhängig vom verwendeten Auslastungstesttool anwendbar. Weitere Informationen zu Testtools, die für Azure DevOps (früher VSTS) verfügbar sind, finden Sie unter Übersicht über DevOps-Tools für Azure DevOps.
Sie können auch das SharePoint Load Test Kit (LTK) mit VSTS für Auslastungstests von SharePoint 2010-Farmen verwenden. Mit dem Auslastungstestkit wird ein Visual Studio Team System 2008-Auslastungstest basierend auf IIS-Protokollen von Windows SharePoint Services 3.0 und Microsoft Office SharePoint Server 2007 generiert. Der VSTS-Auslastungstest kann verwendet werden, um synthetische Last für SharePoint Foundation 2010 oder SharePoint Server 2010 im Rahmen einer Kapazitätsplanungsübung oder eines Vorabbelastungstests zu generieren.
Das Auslastungstestkit ist im Microsoft SharePoint 2010 Administration Toolkit v2.0 enthalten, das im Microsoft Download Center verfügbar ist.
Ein Hauptkriterium für den Erfolg der Tests besteht darin, dass Sie eine realistische Arbeitsauslastung effektiv simulieren können, indem Sie Anforderungen für eine große Menge der Testwebsitedaten generieren, da Benutzer in einer SharePoint Server 2013-Produktionsfarm ebenfalls auf eine große Menge an Inhalten zugreifen. Dazu müssen Sie Ihre Tests in der Regel so konstruieren, dass sie datengesteuert sind. Statt Hunderte einzelner Tests zu erstellen, die für den Zugriff auf eine bestimmte Seite hartcodiert sind, sollten Sie nur einige wenige Tests verwenden, in denen für den dynamischen Zugriff auf diese Seiten Datenquellen mit den URLs für diese Elemente verwendet werden.
In Visual Studio Team System (Team Test Load Agent) kann eine Datenquelle in verschiedenen Formaten vorliegen, aber ein CSV-Dateiformat ist häufig am einfachsten zu verwalten und zwischen Entwicklungs- und Testumgebungen zu transportieren. Beachten Sie, dass beim Erstellen von CSV-Dateien mit diesem Inhalt möglicherweise benutzerdefinierte Tools erstellt werden müssen, um die SharePoint Server 2013-basierte Umgebung aufzulisten und die verschiedenen verwendeten URLs aufzuzeichnen.
Unter anderem für folgende Aufgaben ist möglicherweise die Verwendung von Tools erforderlich:
Erstellen von Benutzern und Gruppen in Active Directory oder in einem anderen Authentifizierungsspeicher bei Verwendung der formularbasierten Authentifizierung
Aufzählen von URLs für Websites, Listen und Bibliotheken, Listenelemente, Dokumente usw. und Schreiben der URLs in CSV-Dateien für Auslastungstests
Hochladen von Beispieldokumenten in verschiedene Dokumentbibliotheken und Websites
Erstellen von Websitesammlungen, Websites, Listen, Bibliotheken, Ordnern und Listenelementen
Erstellen von Meine Websites
Erstellen von CSV-Dateien mit Benutzernamen und Kennwörtern für Testbenutzer; dabei handelt es sich um die Benutzerkonten, mit denen die Auslastungstests ausgeführt werden. Es sollten mehrere Dateien erstellt werden, sodass bestimmte Dateien beispielsweise nur Administratorbenutzer enthalten, andere Dateien Benutzer mit erhöhten Rechten (wie Autor/Mitwirkender, Hierarchie-Manager usw.) und wieder andere nur Leser enthalten usw.
Erstellen einer Liste mit Beispielen für Suchschlüsselwörter und -ausdrücke
Auffüllen von SharePoint-Gruppen und Berechtigungsstufen mit Benutzern und Active Directory-Gruppen (oder Rollen bei Verwendung der formularbasierten Authentifizierung)
Beim Erstellen der Webtests sollten Sie weitere bewährte Methoden beachten und implementieren. Hierzu zählen unter anderem folgende bewährte Methoden:
Zeichnen Sie einfache Webtests als Ausgangspunkt auf. Diese Tests enthalten hartcodierte Werte für Parameter wie URL, IDs usw. Ersetzen Sie diese hartcodierten Werte durch Links aus Ihren CSV-Dateien. Die Datenbindung dieser Werte in Visual Studio Team System (Team Test Load Agent) ist einfach.
Sie sollten grundsätzlich Gültigkeitsprüfungsregeln für den Test verwenden. Wenn beispielsweise eine Seite angefordert wird und ein Fehler auftritt, erhalten Sie häufig die error.aspx Seite als Antwort. Aus Sicht eines Webtests erscheint es nur als eine weitere positive Antwort, da Sie den HTTP-Statuscode 200 (erfolgreich) in den Auslastungstestergebnissen erhalten. Es ist aber offensichtlich ein Fehler aufgetreten, also sollte dies anders nachverfolgt werden. Durch die Erstellung einer oder mehrerer Gültigkeitsprüfungsregeln können Sie feststellen, wann bestimmter Text als Antwort gesendet wird, sodass bei der Gültigkeitsprüfung ein Fehler auftritt und die Anforderung als Fehler markiert wird. Beispielsweise kann in Visual Studio Team System (Team Test Load Agent) eine einfache Validierungsregel eine ResponseUrl-Überprüfung sein: Sie zeichnet einen Fehler auf, wenn die Seite, die nach Umleitungen gerendert wird, nicht dieselbe Antwortseite ist, die im Test aufgezeichnet wurde. Sie können auch eine FindText-Regel hinzufügen, die einen Fehler aufgibt, wenn das Wort "Zugriff verweigert" in der Antwort gefunden wird.
Verwenden Sie mehrere Benutzer in unterschiedlichen Rollen für Tests. Bestimmte Verhaltensweisen, z. B. das Zwischenspeichern von Ausgaben, funktionieren je nach den Rechten des aktuellen Benutzers unterschiedlich. Ein Websitesammlungsadministrator oder ein authentifizierter Benutzer mit Genehmigungs- oder Erstellungsrechten erhält beispielsweise keine zwischengespeicherten Ergebnisse, da er immer die aktuellste Version des Inhalts sehen soll. Anonyme Benutzer erhalten jedoch den zwischengespeicherten Inhalt. Sie müssen sicherstellen, dass sich Ihre Testbenutzer in einer Mischung dieser Rollen befinden, die ungefähr der Mischung der Benutzer in der Produktionsumgebung entsprechen. In der Produktion gibt es z. B. wahrscheinlich nur zwei oder drei Websitesammlungsadministratoren, sodass Sie keine Tests erstellen sollten, bei denen 10 % der Seitenanforderungen von Benutzerkonten erfolgen, die Websitesammlungsadministratoren über den Testinhalt sind.
Das Analysieren von abhängigen Anforderungen ist ein Attribut von Visual Studio Team System (Team Test Load Agent), mit dem bestimmt wird, ob mit dem Test-Agent versucht werden soll, nur die Seite oder die Seite und alle zugehörigen Anforderungen abzurufen, die Bestandteil der Seite sind, z. B. Bilder, Stylesheets, Skripts usw. Bei Auslastungstests werden diese Elemente normalerweise aus bestimmten Gründen ignoriert:
Wenn ein Benutzer eine Website zum ersten Mal besucht, werden diese Elemente oft vom lokalen Browser zwischengespeichert.
Diese Elemente stammen in der Regel nicht aus SQL Server in einer auf SharePoint Server 2013 basierenden Umgebung. Wenn die BLOB-Zwischenspeicherung aktiviert ist, werden sie stattdessen von den Webservern bereitgestellt, sodass sie keine SQL Server-Last generieren.
Wenn Sie regelmäßig über einen hohen Anteil erstmaliger Benutzer Ihrer Website verfügen oder die Browserzwischenspeicherung deaktiviert haben oder wenn Sie den BLOB-Cache aus einem bestimmten Grund nicht verwenden möchten, kann es sinnvoll sein, das Analysieren von abhängigen Anforderungen in den Tests zu aktivieren. Dies ist für die meisten Implementierungen aber nicht die Regel, sondern die Ausnahme. Beachten Sie, dass es durch das Aktivieren dieser Funktion zu einer deutlichen Erhöhung der vom Testcontroller gemeldeten RPS-Anzahl kommen kann. Diese Anforderungen werden so schnell verarbeitet, dass Sie möglicherweise falsch denken, dass in der Farm mehr Kapazität verfügbar ist, als tatsächlich vorhanden ist.
Denken Sie daran, auch die Clientanwendungsaktivität zu modellieren. Clientanwendungen wie Microsoft Word, PowerPoint, Excel und Outlook generieren auch Anforderungen an SharePoint Server 2013-Farmen. Sie fügen der Umgebung Last hinzu, indem sie die Serveranforderungen senden, z. B. RSS-Feeds abrufen, Informationen zu sozialen Netzwerken abrufen, Details zur Website- und Listenstruktur anfordern, Daten synchronisieren usw. Diese Arten von Anforderungen sollten einbezogen und modelliert werden, wenn Sie diese Clients in Ihrer Implementierung haben.
In den meisten Fällen sollte ein Webtest nur eine einzelne Anforderung enthalten. Es ist einfacher, Ihre Testumgebung und einzelne Anforderungen zu optimieren und probleme zu beheben, wenn der Test nur eine einzelne Anforderung enthält. Webtests müssen in der Regel mehrere Anforderungen enthalten, wenn der simulierte Vorgang aus mehreren Anforderungen besteht. Zum Testen dieses Aktionssatzes benötigen Sie beispielsweise einen Test mit mehreren Schritten: Auschecken eines Dokuments, Bearbeiten, Einchecken und Veröffentlichen des Dokuments. Es erfordert auch den Reservierungsstatus zwischen den Schritten. Beispielsweise sollte dasselbe Benutzerkonto verwendet werden, um es auszuchecken, die Änderungen vorzunehmen und es wieder einzuchecken. Diese mehrstufigen Vorgänge, bei denen der Zustand zwischen den einzelnen Schritten übertragen werden muss, werden am besten von mehreren Anforderungen in einem einzelnen Webtest verarbeitet.
Führen Sie jeden Webtest einzeln aus. Stellen Sie sicher, dass der jeweilige Test erfolgreich ausgeführt werden kann, bevor Sie ihn im Rahmen eines umfangreicheren Auslastungstests ausführen. Vergewissern Sie sich, dass alle Namen für Webanwendungen aufgelöst werden und dass die im Test verwendeten Benutzerkonten ausreichende Rechte zum Ausführen des Tests besitzen.
Webtests umfassen die Anforderungen für einzelne Seiten, das Hochladen von Dokumenten, das Anzeigen von Listenelementen usw. Alle diese Komponenten werden in Auslastungstests zusammengefasst. In einem Auslastungstest können Sie alle verschiedenen Webtests einbinden, die ausgeführt werden sollen. Jedem Webtest kann ein Prozentsatz der Ausführungszeit zugewiesen werden. Wenn Sie z. B. feststellen, dass 10 % der Anforderungen in einer Produktionsfarm Suchabfragen sind, konfigurieren Sie im Auslastungstest einen Abfragewebtest für die Ausführung von 10 % der Zeit. In Visual Studio Team System (Team Test Load Agent) konfigurieren Sie mithilfe von Auslastungstests auch Dinge wie die Browsermischung, die Netzwerkmischung, die Auslastungsmuster und die Ausführungseinstellungen.
Für Auslastungstests sollten einige zusätzliche bewährte Methoden beachtet und implementiert werden:
Verwenden Sie in den Tests ein angemessenes Verhältnis zwischen Lese- und Schreibvorgängen. Durch eine zu hohe Anzahl von Schreibvorgängen in einem Test kann der Gesamtdurchsatz eines Tests deutlich beeinträchtigt werden. Selbst in Zusammenarbeitsfarmen sind im Verhältnis zwischen Lese- und Schreibvorgängen meist viel mehr Lesevorgänge als Schreibvorgänge enthalten.
Berücksichtigen Sie die Auswirkungen anderer ressourcenintensiver Vorgänge, und entscheiden Sie, ob sie während eines Auslastungstests ausgeführt werden sollen. Beispielsweise werden Vorgänge wie das Sichern und Wiederherstellen im Allgemeinen nicht während eines Auslastungstests ausgeführt. Eine vollständige Suchdurchforstung sollte in der Regel nicht während eines Auslastungstests ausgeführt werden, eine inkrementelle Durchforstung kann hingegen normal sein. Sie müssen berücksichtigen, wie diese Vorgänge in der Produktion geplant werden - werden sie zu Spitzenauslastungszeiten ausgeführt? Wenn dies nicht der Fall ist, sollten sie wahrscheinlich während des Auslastungstests ausgeschlossen werden, wenn Sie versuchen, die maximale Last im stabilen Zustand zu ermitteln, die Sie für Spitzendatenverkehr unterstützen können.
Verwenden Sie keine Denkzeiten. Think Times sind ein Feature von Visual Studio Team System (Team Test Load Agent), mit dem Sie die Zeit simulieren können, die Benutzer zwischen Klicks auf einer Seite anhalten. Beispielsweise kann ein typischer Benutzer eine Seite laden, drei Minuten damit verbringen, sie zu lesen, und dann auf einen Link auf der Seite klicken, um eine andere Website zu besuchen. Der Versuch, dies in einer Testumgebung zu modellieren, ist nahezu unmöglich, und die Testergebnisse werden praktisch nicht richtig genutzt. Es ist schwierig zu modellieren, da die meisten Organisationen keine Möglichkeit haben, verschiedene Benutzer und die Zeit zu überwachen, die sie zwischen Klicks auf verschiedene Arten von SharePoint-Websites verbringen (z. B. Veröffentlichen im Vergleich zur Suche im Vergleich zur Zusammenarbeit usw.). Es bietet auch keinen wirklichen Mehrwert, da die SharePoint Server 2013-basierten Server dies nicht tun, obwohl ein Benutzer zwischen Seitenanforderungen anhalten kann. Sie erhalten nur einen stetigen Strom von Anforderungen, die im Laufe der Zeit Gipfel und Täler haben können, aber sie warten nicht im Leerlauf, da jeder Benutzer zwischen dem Klicken auf Links auf einer Seite anhält.
Sie sollten zwischen Benutzern und Anforderungen unterscheiden. In Visual Studio Team System (Team Test Load Agent) ist ein Auslastungsmuster vorhanden, für das Sie die Anzahl der zu simulierenden Benutzer eingeben müssen. Dies hat nichts mit Anwendungsbenutzern zu tun, es ist nur die Anzahl der Threads, die auf den Auslastungstest-Agents verwendet werden, um Anforderungen zu generieren. Ein häufiger Fehler besteht darin, zu denken, dass, wenn die Bereitstellung beispielsweise 5.000 Benutzer enthält, 5.000 die Zahl ist, die in Visual Studio Team System (Team Test Load Agent) verwendet werden sollte– nicht! Dies ist einer der vielen Gründe dafür, dass bei der Schätzung der Kapazitätsplanungsanforderungen die Verwendungsanforderungen auf der Anzahl der Anforderungen pro Sekunde basieren sollen - nicht auf der Anzahl der Benutzer. In einem Visual Studio Team System(Team Test Load Agent)-Auslastungstest werden Sie feststellen, dass Sie häufig Hunderte von Anforderungen pro Sekunde mit nur 50 bis 75 Auslastungstestbenutzern generieren können.
Verwenden Sie für die meisten zuverlässigen und reproduzierbaren Testergebnisse ein Muster mit konstanter Auslastung. In Visual Studio Team System (Team Test Load Agent) haben Sie die Möglichkeit, die Auslastung auf einer konstanten Anzahl von Benutzern (Threads, wie im vorherigen Punkt erläutert), einem verstärkten Auslastungsmuster von Benutzern oder einem zielbasierten Nutzungstest zu basieren. Es handelt sich um ein Muster mit gesteigerter Auslastung, wenn Sie mit einer niedrigeren Anzahl von Benutzern beginnen und sie dann erhöhen, indem Sie alle paar Minuten weitere Benutzer hinzufügen. Es handelt sich um einen zielbasierten Nutzungstest, wenn Sie für einen bestimmten Diagnoseindikator, z. B. für die CPU-Auslastung, einen Schwellenwert festlegen und mit dem Test die Auslastung erhöht wird, sodass dieser Indikator immer zwischen einem minimalen und einem maximalen Schwellenwert liegt, den Sie dafür definieren. Wenn Sie jedoch nur versuchen, den maximalen Durchsatz zu ermitteln, den Ihre SharePoint Server 2013-Farm während der Spitzenlast erhalten kann, ist es effektiver und genauer, nur ein konstantes Auslastungsmuster zu wählen. Auf diese Weise können Sie einfacher ermitteln, welche Auslastung vom System unterstützt wird, bevor die Schwellenwerte, die in einer fehlerfreien Farm eingehalten werden sollen, regelmäßig überschritten werden.
Jedes Mal, wenn Sie einen Auslastungstest ausführen, denken Sie daran, dass daten in der Datenbank geändert werden. Ob beim Hochladen von Dokumenten, beim Bearbeiten von Listenelementen oder auch nur beim Aufzeichnen von Aktivitäten in der Verwendungsdatenbank - es werden immer Daten in SQL Server geschrieben. Damit konsistente und gültige Testergebnisse aus den einzelnen Auslastungstests sichergestellt sind, sollten Sie über eine Sicherung verfügen, bevor Sie den ersten Auslastungstest ausführen. Nachdem jeder Auslastungstest abgeschlossen ist, sollte die Sicherung verwendet werden, um den Inhalt wieder auf die Weise wiederherzustellen, die vor dem Start des Tests war.
Siehe auch
Konzepte
Kapazitätsplanung für SharePoint Server 2013
Warten und Überwachen von SharePoint Server 2013
Softwarebeschränkungen und -grenzen für SharePoint Server 2016
Weitere Ressourcen
Capacity management and sizing overview for SharePoint Server 2013