Schätzen der Kapazität und Leistung von Web Content Management (SharePoint Server 2013)

 

**Gilt für:**SharePoint Server 2013

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

Zusammenfassung: Hier erhalten Sie Informationen zur Ermittlung der Anzahl und Typen von Computern, die Sie zum Veröffentlichen von Inhalten und zum Verwalten von Webinhalten in SharePoint Server 2013 benötigen.

Unternehmen verwenden oft SharePoint Server 2013 zum Veröffentlichen von Inhalten, dass anonyme Benutzerzugriff auf einer Internetwebsite oder, die Benutzern den Zugriff auf Intranet-Website authentifiziert. Dieser Artikel enthält die Kapazität und Leistung Daten, mit denen planen, die Anzahl der Computer verwenden und die Typen von Computern, die zum Veröffentlichen von Inhalten und Verwalten von Webinhalten in SharePoint Server 2013 erforderlich sind.

Inhalt dieses Artikels:

• Einführung

• Voraussetzungsinformationen

• Websiteübergreifende Veröffentlichung mithilfe der verwalteten Navigation

• Veröffentlichung über die direkte Dokumenterstellung

SharePoint-Veröffentlichung enthält verschiedene Arten von Veröffentlichungssites und zugeordneten Methoden, die für die einzelnen Standorte verfügbar sind. Die Veröffentlichungsfeatures von SharePoint Server 2013 dienen Branding Internet-, Intranet- und extranet-Websites erstellen. Weitere Informationen zum Veröffentlichen von SharePoint Server 2013 finden Sie unter Übersicht über die Veröffentlichung auf Internet-, Intranet und Extranet-Websites in SharePoint Server.

Einführung

In diesem Artikel werden die folgenden Szenarien beschrieben:

• Internetpräsenzwebsite

  Auf einer solchen Website werden Informationen für Kunden, Partner, Investoren und potenzielle Mitarbeiter bereitgestellt. Anonymen Internetbenutzern ermöglicht dieser Websitetyp das Suchen nach Informationen zu einem Unternehmen. Diese Websites sind in der Regel firmenspezifisch, und die Inhalte werden vom jeweiligen Unternehmen streng kontrolliert.

• Internetgeschäftswebsite

  Auf einer solchen Website werden Produkte und Dienstleistungen beworben, die ein Unternehmen seinen Kunden anbietet. Auf diesen Websites kann beispielsweise ein Katalog mit den vom Unternehmen angebotenen Produkten angezeigt werden.

• Intranetwebsite

  Ein Unternehmen veröffentlicht diesen Typ von Website intern innerhalb einer Organisation. Auf diesen Websites werden Informationen für authentifizierte Benutzer freigegeben, und Unternehmen können den Zugriff darauf entweder durch eine strikte Verwaltung einschränken oder für alle internen Benutzer ermöglichen.

• Extranetwebsite

  Dieser Websitetyp bietet Remotemitarbeitern sowie Partnern und Kunden Zugriff auf Inhalte für eine bestimmte Zielgruppe. Diese Websites können den Zugriff auf Wissensdatenbanken mit erstellten Inhalten ermöglichen, die zur Kategorisierung von Artikeln mit Metadaten markiert sind. Benutzer können dann nach bestimmten Informationen suchen, beispielsweise nach Artikeln zur Problembehandlung und zu Supportfragen.

In diesen Szenarien ermöglichen die websiteübergreifende Veröffentlichung von Sammlungen und das Inhaltssuche-Webpart die Wiederverwendung von Inhalten in Websitesammlungen. Diese Features und Funktionen haben Einfluss auf die Kapazitätsplanung. Weitere Informationen finden Sie unter Übersicht über die websiteübergreifende Veröffentlichung in SharePoint Server.

Verwalteter Navigation in SharePoint Server 2013 bietet taxonomiegesteuerte Navigation für eine Veröffentlichungswebsite. Weitere Informationen finden Sie unter Übersicht über die verwaltete Navigation in SharePoint Server.

Die in diesem Artikel enthaltenen Kapazitäts- und Leistungsdaten umfassen zwei Teile. Bei dem ersten Teil handelt es sich um die neue Methode der websiteübergreifenden Veröffentlichung und die verwaltete Navigation. Im zweiten Teil wird das Modell der direkten Dokumenterstellung verwendet.

In den in diesem Artikel verwendeten Modellen werden die zwei folgenden Schlüsselmetriken angegeben:

• Durchsatz

  Die von der Website unterstützte Anzahl der Seitenansichten pro Sekunde

• Serverantwortzeit

  Die vom Server zum Verarbeiten der Anforderung benötigte Zeit, die sich darauf auswirkt, wie lange es dauert, bis die Seite dem Benutzer angezeigt wird. Bei den in diesem Dokument angegebenen Serverantwortzeiten handelt es sich um Werte des 95. und 50. Quantils. Diese Werte bedeuten, dass 95 % und 50 % der Anforderungen schneller erfolgen als der jeweils angegebene Wert. Wir messen diese Werte anhand der in der SharePoint-Verwendungsdatenbank für eine bestimmte Anforderung aufgezeichneten "Dauer".

• Aktualität des Inhalts

  Die Dauer, bis ein aktualisiertes Element in den Suchergebnissen wiedergegeben wird, ist beim Arbeiten mit Szenarien der websiteübergreifenden Veröffentlichung eine wertvolle zu berücksichtigende Metrik.

In den Szenarien in diesem Artikel werden die zwei folgenden Statusangaben verwendet:

• Grüne Zone

  Die Auslastung der Server liegt unter 60 Prozent. Das sollte die meiste Zeit, in der die Server ausgeführt werden, das Ziel sein.

• Rote Zone

  Die Server sind nahezu voll ausgelastet. Dieser Zustand kann vorliegen, wenn die Auslastung der SharePoint-Website höher ist als üblich. In der roten Zone beginnen die Werte der Serverantwortzeiten zu steigen, da der Server versucht, den eingehenden Anforderungen nachzukommen.

Voraussetzungsinformationen

Bevor Sie diesen Artikel lesen, stellen Sie sicher, dass Sie die wichtigsten Konzepte hinter SharePoint Server 2013 Capacity Management verstehen. Die folgenden Artikel helfen Ihnen erfahren Sie mehr über die empfohlene Vorgehensweise bei der kapazitätsverwaltung und bieten Kontext, mit denen Sie verstehen, wie Sie eine effektive Verwendung der Informationen in diesem Artikel.

Einige neue Features, die funktionelle Auswirkungen auf Veröffentlichungsszenarien haben, werden in diesem Artikel nicht erwähnt. Diese Szenarien umfassen Gerätekanäle, SEO-Optimierung, Anzeigevorlagen und Abfrageregeln. Zudem enthält dieser Artikel auch keine detaillierte Beschreibung der Funktionalität und Konfiguration einer websiteübergreifenden Veröffentlichungswebsite. Weitere Informationen finden Sie unter Planen der websiteübergreifenden Veröffentlichung in SharePoint Server und Konfigurieren von Web Content Management-Lösungen in SharePoint Server.

Weitere Informationen zur Kapazität und Leistung, die zum besseren Verständnis der Daten in diesem Artikel beitragen, finden Sie unter Planen der Leistung in SharePoint Server 2013 Planung.

Websiteübergreifende Veröffentlichung mithilfe der verwalteten Navigation

In diesem Abschnitt finden Sie unsere Testdaten für zwei Bereiche: die websiteübergreifende Veröffentlichung mit anonymen Benutzern und die Veröffentlichung über die direkte Dokumenterstellung.

Websiteübergreifende Veröffentlichung mit anonymen Benutzern

Die Testergebnisse in diesem Abschnitt basieren auf einem Basiswebsitemodell für die websiteübergreifende Veröffentlichung, das als Leitfaden für die Kapazitätsplanung dient. Wenn Sie eine SharePoint-Bereitstellung für den Zugriff auf eine Website durch anonyme Benutzer planen, können Sie diesen Leitfaden verwenden und Ihre Bereitstellungsspezifikationen entsprechend anpassen.

In dem Testszenario für unsere Tests wird das Feature für die websiteübergreifende Veröffentlichung verwendet. In diesem Szenario werden Inhalte in mehreren Websitesammlungen bereitgestellt, die als Kataloge markiert sind und dann von der SharePoint-Suchdienstanwendung durchforstet werden. Webparts, die Suchtechnologien verwenden, wie beispielsweise das Inhaltssuche-Webpart und das Webpart für die Wiederverwendung von Katalogelementen, zeigen Inhalte auf Seiten auf einer anderen Website an. Weitere Informationen finden Sie unter Übersicht über die websiteübergreifende Veröffentlichung in SharePoint Server.

Für die Modellwebsite, die wir zum Testen der websiteübergreifenden Veröffentlichung erstellt haben, werden die folgenden Merkmale verwendet:

• Eine Veröffentlichungswebsite mit ca. 5 Millionen Seiten oder Elementen

• Die Elemente sind ca. 1.000 Kategorien zugeordnet.

• Die Inhalte befinden sich in anderen Websitesammlungen in mindestens einem Katalog.

• Die Website verwendet die verwaltete Navigation, die mit den Kategorien verknüpft ist, denen die Elemente zugeordnet sind.

• Im Rahmen der weiter unten in dieser Liste beschriebenen Basisbereitstellungstopologie erfolgen auf der Website durchschnittlich 80 Seitenansichten pro Sekunde. Zu Spitzenzeiten werden bis zu 100 Seitenansichten pro Sekunde erreicht. Zum Hochskalieren dieses Durchsatzes fügen Sie der Topologie Computer hinzu. Zum Runterskalieren dieses Durchsatzes entfernen Sie Computer aus der Topologie.

• Der Suchcrawler wird mit kontinuierlichen Durchforstungen in einem einminütigen Intervall ausgeführt, wobei pro Sekunde fünf Aktualisierungen des Katalogs stattfinden.

• Die Website weist die folgenden Seiten- und Datenverkehrsmuster auf:

  • Die Homepage mit drei Inhaltssuche-Webparts und einem Einschränkungsbereich-Webpart empfängt 15 % des Datenverkehrs.

  • Kategorieseiten mit drei Inhaltssuche-Webparts, einem Taxonomieeinschränkungsbereich-Webpart und einem Einschränkungsbereich-Webpart empfangen 45 % des Datenverkehrs.

  • Katalogelementseiten mit einem Webpart für die Wiederverwendung von Katalogelementen und zwei Inhaltssuche-Webparts empfangen 40 % des Datenverkehrs.

• Jedes Webpart für die Inhaltssuche und für die Wiederverwendung von Katalogelementen gibt eine synchrone Abfrage aus.

• Von den Katalogelementseiten wird der Cache für anonyme Suchergebnisse nicht verwendet, weil sie nur wenig Datenverkehr empfangen.

• In der Farm ist der BLOB-Cache (Binary Large Object) für Computer aktiviert, die als Front-End-Webserver ausgeführt werden.

Die zum Testen dieses Szenarios verwendete Servertopologie ist im folgenden Diagramm dargestellt:

Abbildung 1: Servertopologie der Testumgebung

• Ein Computer, auf dem SQL Server mit allen von SharePoint verwendeten Datenbanken gehostet wird

• Ein Computer, auf dem SharePoint-Dienstanwendungen, der verteilte Cachedienst, die Suchanalyse-Verarbeitungskomponente und Suchverwaltungsrollen gehostet werden

• Ein Computer, auf dem die Suchcrawler- und Inhaltsverarbeitungsrollen (Content Processing, CPC) gehostet werden

• Drei Computer, auf denen Suchindexknoten mit der Abfrageverarbeitung gehostet werden und die als Front-End-Webserver dienen

Testumgebungsberichte

Wir haben die in Abbildung 1 dargestellte Topologie für unsere Testumgebung mit physischen Computern und für einen Visual Studio Team System-Auslastungstest (VSTS) verwendet. Weitere Informationen finden Sie unter Visual Studio Team System. Die technischen Spezifikationen der Testcomputer finden Sie in den nachfolgenden Tabellen.

Serverkomponenten	Server mit SharePoint Server
Prozessoren	Intel Xeon-CPUs @2.27GHz (2 Prozessoren, 8 Prozessorkerne, 16 Threads)
RAM	24 GB
Betriebssystem	Windows Server 2008 R2 Enterprise SP1, 64-Bit
Größe des SharePoint-Laufwerks	200 GB auf interner Festplatte
Speicher für Suchindex	78 GB auf einem externen Datenträgerarray (2 x Dell PERC H700 SCSI)
Anzahl der Netzwerkadapter	2
Geschwindigkeit der Netzwerkadapter	1 Gigabit
Authentifizierung	Keine \endash anonym
Softwareversion	SharePoint Server 2013

Serverkomponenten	Datenbankserver
Prozessoren	Intel Xeon-CPUs L5520 @2,27 GHz (2 Prozessoren, 8 Prozessorkerne, 16 Threads)
RAM	24 GB
Betriebssystem	Windows Server 2008 R2 Enterprise SP1, 64-Bit
Datenträgerarray	2 x Dell H700 SCSI
Anzahl der Netzwerkadapter	2
Geschwindigkeit der Netzwerkadapter	1 Gigabit
Authentifizierung	NTLM
Softwareversion	Microsoft SQL Server 2008 R2 SP1

Die Ergebnisse einer zehnminütigen Ausführung lauten wie folgt:

Testfeatures	Grüne Zone	Rote Zone
Anzahl der VSTS-Benutzer (Simulation gleichzeitiger Benutzer):	60	100
Serverantwortzeit, 50. Quantil*:	219 ms	302 ms
Serverantwortzeit, 95. Quantil*:	412 ms	635 ms
Seitenansichten pro Sekunde:	78	98

Das ist ein Szenario der websiteübergreifenden Veröffentlichung, in dem Inhalt aus dem Suchindex angezeigt wird. Es kann zweckmäßig sein, die Anzahl der Abfragen, die von den zum Hosten von Suchabfragen verwendeten Servern verarbeitet werden, sowie die Anzahl der vom Cache für anonyme Suchergebnisse verarbeiteten Abfragen zu prüfen. In diesem Modell verarbeitet der Cache für anonyme Suchergebnisse ca. 60 % der Abfragen. Der Cache für anonyme Suchergebnisse wird weiter unten in diesem Artikel erörtert.

Testfeatures	Grüne Zone	Rote Zone
Gesamtanzahl der Abfragen pro Sekunde:	235	294
Vom Cache für anonyme Suchergebnisse verarbeitete Abfragen:	145	182
Von der Suche verarbeitete Abfragen:	90	112

Die Werte für die durchschnittliche CPU-Auslastung und für die maximale Arbeitsspeicherauslastung dieser Computer während der Durchführung der Tests lauten wie folgt:

Testfeatures	Grüne Zone	Rote Zone
Durchschnittliche CPU-Auslastung (Suchindexknoten pro Front-End-Webserver)	59%	80%
Durchschnittliche CPU-Auslastung (Anwendungsserver einschl. des verteilten Caches)	8%	9%
Durchschnittliche CPU-Auslastung (Suche, CPC-Knoten)	5%	5%
Durchschnittliche CPU-Auslastung ( SQL Server)	Nicht gemessen	Nicht gemessen
Maximale Arbeitsspeicherauslastung (Suchindexknoten pro Front-End-Webserver)	7.5 GB	7.5 GB
Maximale Arbeitsspeicherauslastung (Anwendungsserver einschl. des verteilten Caches)	10.1 GB	10 GB
Maximale Arbeitsspeicherauslastung (Suche, CPC-Knoten)	6.5 GB	6.5 GB

Die Arbeitsspeicherauslastung kann leicht variieren, weil bei normaler Nutzung verschiedene Zeitgeberaufträge auf dem Server ausgeführt werden. Nach einem zweiwöchigen Testlauf unter Dauerlast haben wir festgestellt, dass die Index-/Front-End-Webserverknoten 12 GB Arbeitsspeicher in Anspruch nahmen.

So zeigen Suchwebparts Inhalte auf websiteübergreifenden Veröffentlichungsseiten an

Wenn eine Veröffentlichungsseite ein Suchwebpart (beispielsweise das Inhaltssuche-Webpart) enthält, beginnt der Browser vor dem Abschluss der Suchabfrage mit der Verarbeitung der Seite. Dadurch wird die wahrgenommene Wartezeit der Seite verbessert. Nach Abschluss der Suchabfrage werden die vollständigen Ergebnisse der Abfrage an den Browser gesendet, und die Verbindung mit dem Browser wird beendet. Benutzer könnten meinen, dass die Suchergebnisse asynchron geladen werden. Die Abfragen werden jedoch weiterhin vom Server gesendet, während die Seite angefordert wird.

Für das Inhaltssuche-Webpart gibt es einen separaten asynchronen Modus, bei dem die Abfragen nach dem Laden einer Seite vom Browser gesendet werden.

Auswirkungen von Laständerungen auf Ihre websiteübergreifende Veröffentlichungswebsite

Beim Auslastungstest haben wir die Anzahl der VSTS-Benutzer (analog zur Anzahl der gleichzeitig auf die Website zugreifenden Benutzer) variiert. Aus dem folgenden Diagramm geht hervor, dass die Serverantwortzeiten bei steigender Last zunehmen und es einige inkrementelle Zunahmen bei der Anzahl der pro Sekunde verarbeiteten Seiten gibt. Es empfiehlt sich, dafür zu sorgen, dass die Serverantwortzeiten unter 750 Millisekunden bleiben, damit die Benutzer im Rahmen der SharePoint-Bereitstellung von schnellen Antwortzeiten profitieren.

Abbildung 2: Diagramm mit Durchsätzen und Serverantwortzeiten bei unterschiedlichen Lasten

Horizontales Skalieren Ihrer websiteübergreifenden Veröffentlichungswebsite

Wenn der Datenverkehr der SharePoint-Bereitstellung voraussichtlich höher oder geringer als in dem zuvor beschriebenen Basisreferenzfall ausfällt, können Sie in der Farm die Anzahl der Computer, die mit der Index- und Front-End-Webserverrolle ausgeführt werden, entsprechend ändern. Im folgenden Diagramm sehen Sie die Ergebnisse der horizontalen Skalierung derselben websiteübergreifenden Veröffentlichungswebsite mit unterschiedlichen Lastmustern und einer variierenden Anzahl von Computern, die als Front-End-Webserver mit Indexknoten verwendet werden. Die Skala umfasst einen einzigen Computer mit der Front-End-Webserverrolle mit Indexknoten bis hin zu sechs Computer:

Abbildung 3: Horizontales Skalieren Ihrer Bereitstellung

In den einzelnen Konfigurationen haben wir die Last so angepasst, dass die Werte der Serverantwortzeiten mit denen des Basisreferenzfalls aus dem vorherigen Abschnitt vergleichbar sind.

Mit zunehmender Anzahl der Computer holt die Komplexität der Topologie die Gewinne ein. Jeder zusätzliche Computer hat im Vergleich zu den bereits in der Umgebung vorhandenen Computern einen geringeren Durchsatz. Diese Zahlen werden bereitgestellt, um das Muster für die horizontale Skalierung aufzuzeigen. Die tatsächliche Leistung ändert sich entsprechend der jeweiligen Konfiguration der SharePoint-Bereitstellung.

Richtlinien zur Planung Ihrer Website

Bei den meisten unserer Leistungstests wurde die in den vorherigen Abschnitten beschriebene Bereitstellung verwendet. Die im Folgenden aufgelisteten Richtlinien sollen Sie dabei unterstützen, die richtigen Entscheidungen in Bezug auf die Kapazitätsplanung treffen zu können, wenn sich Ihre Bereitstellungen von den in unserer Testumgebung verwendeten Bereitstellungen unterscheiden.

• Eine größere Anzahl von Elementen im Suchindex bedeutet im Allgemeinen längere Wartezeiten. Jede Indexpartition kann bis zu 10 Millionen Elemente enthalten. Auf Standardwebsites werden selten mehr als 10 Millionen Elemente angezeigt. Daher benötigen diese Websites nur eine Partition wie in der zuvor beschriebenen Topologie. Sie können mehr Indexpartitionen verwenden, wenn Sie entweder mehr als 10 Millionen Elemente hosten oder über eine größere Anzahl von kleineren und schnelleren Indexpartitionen verfügen möchten. Wenn Sie mehrere Indexpartitionen verwenden möchten, lesen Sie Skalieren der Suchfunktion für Internetsites in SharePoint Server, um Informationen zur richtigen Dimensionierung Ihrer Suchtopologie zu erhalten.

• Durch jedes Steuerelement oder Webpart, das Sie einer Seite (oder einem Seitenlayout) hinzufügen, wird der Aufwand/die Serverantwortzeit für die Seite erhöht.

• Vermeiden der Verwendung von mehr als fünf synchron Inhaltssuche-Webparts oder Katalogelementen Wiederverwenden von Webparts auf einer Seite. Während der Verarbeitung einer Anforderung für eine Seite, SharePoint Server 2013 bis zu fünf Abfragen gleichzeitig ausgeführt und gibt die Ergebnisse zurück. Wenn mehr als fünf Abfragen auf einer Seite befinden, führt SharePoint Server 2013 die ersten fünf Abfragen, bevor er beginnt den nächsten Satz von fünf Abfragen ausführen. Wenn Seiten mehr als fünf Inhaltssuche-Webparts oder Katalogelementen Wiederverwenden von Webparts benötigen, können Sie Ausführen der zusätzliche Inhaltssuche-Webparts im asynchronen Modus oder Abfrageregeln und ergebnisblöcke verwenden.

• Webparts für die Inhaltssuche und für die Wiederverwendung von Katalogelementen verfügen über einen asynchronen Modus. Die mit dem Webpart verknüpfte Abfrage wird ausgeführt, nachdem der Browser die Seite geladen hat. Verwenden Sie diesen Modus für langsame Abfragen, damit den Benutzern die restlichen Inhalte der Seite schneller angezeigt werden. Andernfalls empfehlen wir die Verwendung von synchronen Abfragen, um optimale Seitenladezeiten zu erzielen.

• Die Verwendung eines Einschränkungsbereich-Webparts mit vielen Einschränkungen erhöht die zum Verarbeiten einer Abfrage benötigte Zeit. Sie können die Anzahl der anzuzeigenden Einschränkungen für eine verwaltete Eigenschaft ändern. Weitere Informationen finden Sie unter Konfigurieren von Einschränkungen und facettierte Navigation in SharePoint Server.

• Wenn Sie das Taxonomieeinschränkungsbereich-Webpart in einer tiefen Hierarchie von Navigationsknoten verwenden, erhöht sich die zum Verarbeiten einer Abfrage benötigte Zeit. Wir raten davon ab, das Taxonomieeinschränkungsbereich-Webpart auf einer Seite zu verwenden, deren Struktur mehr als 200 Navigationsknoten umfasst. Die große Anzahl an Navigationsknoten kann zu langsameren Serverantwortzeiten und zu einem geringeren Durchsatz führen.

• Wenn Sie eine SharePoint-Bereitstellung für hohe Verfügbarkeit entwerfen, müssen Sie die folgenden Komponenten hinzufügen:

  • Einen zusätzlichen Computer, auf dem die Dienstanwendungen mit Rollen für den verteilten Cache ausgeführt werden, für den Fall, dass der vorhandene Computer nicht verfügbar ist

  • Zusätzliche Computer, die die Last bewältigen können, falls die als Front-End-Webserver fungierenden Computer mit Indexknoten nicht verfügbar sind

  • Einen zusätzlichen Computer mit CPC-Rollen, um sicherzustellen, dass die Aktualisierungen auch dann auf Ihrer Website widergespiegelt werden, wenn der Computer mit der CPC-Rolle nicht verfügbar ist

  • Eine SQL Server-Topologie, die Datenbankabfragen weiterhin verarbeitet, falls einer der Datenbankserver nicht verfügbar ist

Suchdurchforstungsgeschwindigkeit und Aktualität des Inhalts

Im Rahmen unserer Tests haben wir auch den Vorgang zum Aktualisieren der veröffentlichten Kataloginhalte getestet. Anschließend haben wir die Zeit beobachtet, die verstreicht, bis ein aktualisiertes Element auf der Veröffentlichungswebsite angezeigt wird. In unseren Experimenten haben wir pro Sekunde fünf Aktualisierungen am Katalog vorgenommen und die kontinuierlichen Durchforstungen des Katalogs auf ein einminütiges Intervall festgelegt. Wir konnten beobachten, dass es durchschnittlich zwei Minuten dauert, bis die Änderungen auf der Veröffentlichungswebsite angezeigt werden. Die Mindestdauer betrug etwas weniger als eine Minute, und die Höchstdauer lag bei drei Minuten. Diese Zahlen haben sich auch nicht wesentlich verändert, als wir die Anzahl der mit der CPC-Rolle ausgeführten Computer erhöhten.

Bei der vollständigen Durchforstung des Katalogs konnten jedoch durch Erhöhen der Anzahl der mit der CPC-Rolle ausgeführten Computer mehr Elemente pro Sekunde verarbeitet werden. Im folgenden Diagramm ist der Zusammenhang zwischen den pro Sekunde verarbeiteten Elementen und der Anzahl der in der Farm mit der CPC-Rolle ausgeführten Computer dargestellt. Wir möchten jedoch darauf hinweisen, dass diese Testdaten aus einer anderen als der in den Basistests verwendeten SharePoint-Bereitstellung stammen. Die Ergebnisse sind auf die SharePoint-Bereitstellungen anwendbar, weil das Hinzufügen weiterer CPC-Knoten zu besseren Zeiten bei vollständigen Durchforstungen führt.

Abbildung 4: Auswirkungen der Anzahl von CPC-Computern auf eine vollständige Durchforstung

Wenn die vollständigen Durchforstungen Ihrer Kataloge also schneller erfolgen sollen, können Sie in Ihrer Bereitstellung die Anzahl der Computer mit CPC-Rolle erhöhen.

Auslastung der Dienstanwendung für verwaltete Metadaten

Aus unseren Tests geht hervor, dass Veröffentlichungsszenarien mit Websites, die die verwaltete Navigation verwenden, keine erheblichen Arbeitsspeicher- oder CPU-Anforderungen an die Dienstanwendung für verwaltete Metadaten stellen. In einer wie der zuvor beschriebenen Bereitstellung können Sie die Dienstanwendung für verwaltete Metadaten auf einem Computer ausführen, auf dem weitere SharePoint-Dienstanwendungen ausgeführt werden. Die verwaltete Navigation stellt beim Empfangen der ersten Anforderung für eine Website eine Verbindung mit der Dienstanwendung her. Für nachfolgende Anforderungen werden von Front-End-Webservern zwischengespeicherte Werte verwendet. Daher erfolgt keine Auslastung der Dienstanwendung für verwaltete Metadaten, wenn Front-End-Webserver Anforderungen erfüllen.

Cache für anonyme Suchergebnisse

Der Cache für anonyme Suchergebnisse speichert Ergebnisse einer Abfrage, Einschränkungsdaten für die Abfrage sowie zusätzliche Daten aus Ergebnistabellen, die vom verteilten Cachedienst in SharePoint zurückgegeben werden. Jeder Cacheeintrag ist von den Parametern einer Abfrage abhängig, beispielsweise von der Sortierreihenfolge der Ergebnisse, den angeforderten Einschränkungen und von Regeln zur dynamischen Neuanordnung. Der Cache beeinflusst alle von einer Webanwendung verarbeiteten Abfragen, einschließlich der Abfragen von Suchwebparts und CSOM-Clients. Weitere Informationen finden Sie unter Übersicht über die Sucharchitektur in SharePoint Server und Skalieren der Suchfunktion für Internetsites in SharePoint Server.

Für aus Sicherheitsgründen authentifizierte Abfragen wird dieser Cache nicht verwendet.

Zur Erzielung optimaler Ergebnisse empfehlen wir, den verteilten Cachedienst nur für die Ausführung auf dem Computer zu konfigurieren, auf dem die SharePoint-Dienstanwendungen ausgeführt werden. Der verteilte Cachedienst darf keinesfalls auf den Computern mit Front-End-Webserverrollen ausgeführt werden.

Der Cache für anonyme Suchergebnisse aktualisiert Elemente standardmäßig alle 15 Minuten. Mit Microsoft PowerShell können Sie die Cachedauer in der Webanwendung festlegen, in der der Cache konfiguriert ist:

$webapp.Properties["SearchResultsCacheTTL"] = <number of seconds to keep in cache> 
$webapp.Update()

Wenn die Suchergebnisse aktueller als der vorgegebene Standardwert sein sollen, verkleinern Sie den Wert. Bedenken Sie, dass dadurch die Anzahl der vom Suchdienst zu verarbeitenden Abfragen zunimmt.

Bei Veröffentlichungsseiten mit hohem Datenverkehr wird empfohlen, den Cache immer zu verwenden. Beispiele für diese Seitentypen sind die Homepage einer Website und Kategorieseiten mit Suchwebparts. Bei Katalogelementseiten raten wir von der Zwischenspeicherung ab, weil auf eine einzelne Katalogelementseite viel seltener zugegriffen wird als auf eine Homepage und es sich wahrscheinlich nicht lohnt, das Element im Cache zu speichern.

Das Deaktivieren des Caches für anonyme Suchergebnisse hatte in unserer Testumgebung, die dieselben Lastmuster aufweist, zur Folge, dass sich die Serverantwortzeiten erheblich erhöhten und der Durchsatz der Anzahl der Seitenansichten pro Sekunde sank. Aus dem folgenden Diagramm geht dieser Zusammenhang hervor:

Abbildung 5: Auswirkungen des Caches für anonyme Suchergebnisse

Inhaltssuche-Webparts sind standardmäßig für die Verwendung des Caches für anonyme Suchergebnisse konfiguriert. Webparts für die Wiederverwendung von Katalogelementen, die auf Katalogelementseiten verwendet werden, sind aufgrund der im Allgemeinen seltenen Zugriffe auf diese Seiten nicht für die Verwendung des Caches konfiguriert.

Um das Zwischenspeicherungsverhalten eines einzelnen Webparts für die Verwendung (oder Nichtverwendung) des Caches für anonyme Suchergebnisse zu konfigurieren, legen Sie in der DataProviderJSON-Eigenschaft des Webparts den Wert der untergeordneten Eigenschaft "TryCache" fest. Wenn der Wert auf "True" festgelegt ist, verwendet die Abfrage den Cache. Wenn der Wert auf "False" festgelegt ist, wird der Cache für anonyme Suchergebnisse nicht verwendet.

Auswirkungen des Ausgabecaches

Zwischenspeichern der Ausgabe ist eine effiziente Möglichkeit, die Belastung SharePoint Server 2013 in Szenarien für die Veröffentlichung zu reduzieren. Weitere Informationen zur Funktionsweise der Ausgabecache in diesem Artikel finden Sie unter Ausgabezwischenspeicherung und Cacheprofile.

In einer SharePoint-Bereitstellung können Sie die Vorteile der Ausgabezwischenspeicherung nutzen, um die Auslastung von SharePoint-Inhaltsdatenbanken und der Suchdienstanwendung zu reduzieren. Nachfolgend werden ein paar Beispielszenarien aufgelistet:

• Einige Ihrer Seiten empfangen viel Datenverkehr.

• Die SharePoint-Inhaltsdatenbanken empfangen viel Datenverkehr.

• Computer, die Suchabfragen verarbeiten, werden mit hoher CPU-Auslastung ausgeführt.

Wir empfehlen, die Ausgabezwischenspeicherung für sehr beliebte Seiten Ihrer Website zu verwenden, beispielsweise für die Homepage der Website oder für Kategorieseiten der obersten Ebene und für bestimmte Elementseiten mit sehr hohem Datenverkehr.

Im folgenden Diagramm sind einige Ergebnisse aus unserer Testumgebung dargestellt, in der wir die Ausgabezwischenspeicherung auf der Homepage und auf Kategorieseiten verwendet haben, die 60 % des Datenverkehrs der Website empfangen.

Abbildung 6: Auswirkungen der Ausgabezwischenspeicherung auf Homepage und Kategorieseiten

Verarbeitung der Verwendungsanalyse

Um Informationen zu betriebsbereit SharePoint Server 2013 Verwendungsanalyse haben verarbeitet Informationen, die in der Datenbank befindet. In unserem Topologie tritt auf, Analytics Processing auf den Knoten, der den Knoten Search Admin, verteilten und anderen dienstanwendungen enthält. Weitere Informationen finden Sie unter Übersicht über die Analyseverarbeitung in SharePoint Server

Wir haben die Zeitmaßeinheiten einige analyseverarbeitung mithilfe der websiteübergreifenden Veröffentlichungswebsite, die wir in unseren früheren Tests verwendet. Wir haben der Zeit, SharePoint Server 2013 gemessen hat großen Datenmengen verarbeiten, klicken Sie auf Ereignisse auf den Seiten der Website. Während dieser Ergebnisse aus einer websiteübergreifenden Veröffentlichungswebsite sind, gelten jedoch auch für Websites, die die Veröffentlichung Autor-in-Place-Methode verwenden.

Für unsere Tests zur Verarbeitung der Verwendungsanalyse haben wir eine Woche lang die folgenden simulierten Ereignisse generiert:

• 27,5 Millionen Klickereignisse \endash verteilt auf 3 Millionen Listenelemente und 400.000 Benutzer

  Es wurde die Zipf-Verteilung verwendet, sodass einige Elemente und Benutzer viele Ereignisse und andere Elemente und Benutzer wenige Ereignisse auslösen.

Auf diese Weise wurden insgesamt 7,5 Millionen Ereignisse pro Tag generiert, wobei unterschiedliche Benutzer simuliert wurden, die verschiedene Datenverkehrsmuster für die Website generierten.

Wir haben die Analyseausführungen sieben Mal ausgelöst, um den Datenverkehr einer Woche zu simulieren. Wir haben den Verwendungsanalyseauftrag für die über sechs Tage kumulierten Daten täglich ausgeführt. Dann haben wir die Zeit für den siebten Tag gemessen. Der siebte Tag ist der Tag mit der längsten Verarbeitungsdauer, weil alle Elemente der gesamten Woche verarbeitet werden und das Beziehungsdiagramm aktualisiert wird. Laufzeit und Datenträgerverwendung für Tag 8 gleichen den Angaben von Tag 1.

Die Analyseverarbeitung hatte keine wesentlichen Auswirkungen auf den Computer, auf dem sie ausgeführt wurde, und wir konnten auf der suchgesteuerten Website weiterhin Abfragen erfolgreich verarbeiten und den Inhalt aktualisieren.

Die Ergebnisse sind in der folgenden Tabelle zusammengefasst:

Testzeitplan	Beziehungsdiagramm aktualisieren	Laufzeit (Stunden)	Maximale Datenträgerauslastung (gesamt)	Maximale Datenträgerauslastung (Verwendungsanalyse)
Tag 1	Nein	02:35:00		2.65 GB
Tag 2	Nein	02:43:00
Tag 3	Nein	03:23:00
Tag 4	Nein	04:39:00
Tag 5	Nein	06:08:00
Tag 6	Nein	07:35:00
Tag 7	Ja	08:29	82.4 GB	4 GB

Im folgenden Diagramm sind die Laufzeiten für die verschiedenen Tage dargestellt:

Abbildung 7: Laufzeitstunden pro Tag

Websiteübergreifende Veröffentlichung mit authentifizierten Benutzern

SharePoint-Veröffentlichung wird häufig auf Intranetsites verwendet. Mithilfe von SharePoint Server 2013 können diese Websites auch von Cross-Site Publishing versorgt werden. Die folgenden Abschnitte zeigen einige wichtige Unterschiede zu berücksichtigen sind, wenn eine websiteübergreifende Veröffentlichungswebsite planen Sie, dass Benutzer, verwendet authentifiziert. Als die Ausnahmen in den folgenden Abschnitten erwähnt gelten die Regeln, die anonym zugegriffen Websites liegen, weiterhin für Websites, die authentifizierten Benutzerzugriff.

Fehlender Cache für anonyme Suchergebnisse

Wie im obigen Abschnitt Cache für anonyme Suchergebnisse erwähnt, wirkt sich dieser Cache nur auf Benutzer aus, die anonym auf die SharePoint-Website zugreifen. Im Vergleich zu anonym aufgerufenen Websites, die den Cache für anonyme Suchergebnisse verwenden, ist die Durchsatzleistung von Websites, auf die authentifizierte Benutzer zugreifen, wesentlich geringer. Intranetwebsites sind in der Regel selten so hohen Auslastungen (bis zu 100 Seitenansichten pro Sekunde) ausgesetzt, wie die im vorherigen Abschnitt erwähnten Websites). Dies ist jedoch ein wichtiger zu berücksichtigender Unterschied.

In diesen Szenarien können Sie den fehlenden Cache für anonyme Suchergebnisse in einem gewissen Maß durch die Verwendung des Ausgabecaches abfangen. Für websiteübergreifende Veröffentlichungswebsites, auf denen voraussichtlich mehrere Seiten pro Sekunde angezeigt werden, sollten Sie in Erwägung ziehen, den Ausgabecache zu aktivieren.

Größerer Suchindex

Je nach der Größe des Unternehmens, die SharePoint Server 2013 bereitgestellt wird, werden Intranetbereitstellungen mit für SharePoint Server 2013 größere Anzahl von Dokumenten in der Regel indizieren. Dies bedeutet, dass die erforderliche Suchtopologie zur Indizierung dieser Dokumente unterschiedliche wird im Vergleich zu den im vorherigen Abschnitt beschriebenen Topologie. Planen der Suche in SharePoint Server entsprechend Größe die SharePoint-Bereitstellung finden Sie unter.

Veröffentlichung über die direkte Dokumenterstellung

Dieser Abschnitt enthält Hinweise und Ergebnisse, die SharePoint Server 2013 verwenden, aber es ist nicht detailliert die verschiedenen Features, die kapazitätsplanung betreffen. Weitere Informationen in diesem Bereich finden Sie unter Planen von Web Content Management in SharePoint Server.

Veröffentlichung über die direkte Dokumenterstellung mit anonymen Benutzern

Für unsere Tests haben wir eine Website mit den folgenden Merkmalen verwendet:

• Eine Website mit bis zu 20.000 Artikelseiten in 20 Ordnern aus 1.000 Seiten, aufgeteilt auf 50 Websites einer einzigen Websitesammlung

• Die Website verwendet die strukturierte Navigation.

• Die Website erhält im Allgemeinen mindestens 50 bis 100 Seitenaufrufe pro Sekunde.

• Die Datenverkehrsmuster erfassen die folgende Seitenmischung:

  • 20 Seiten, die ein einziges Webpart für Inhaltsabfragen enthalten, das Inhaltsdatenbankabfragen unterschiedlichen Umfangs sendet (20 % des Datenverkehrs)

  • 30 Seiten, die mehrere Webparts für Inhaltsabfragen enthalten, die Inhaltsdatenbankabfragen unterschiedlichen Umfangs senden (30 % des Datenverkehrs)

  • 1.600 Artikel mit 40T-Text und zwei Bildern (empfangen 50 % des Datenverkehrs)

Die empfohlene Servertopologie ist im folgenden Diagramm dargestellt:

Abbildung 8: Testtopologie für die Veröffentlichung über die direkte Dokumenterstellung

• 1 Computer, auf dem SQL Server gehostet wird

• 1 Computer, der als Front-End-Webserver fungiert und auf dem die SharePoint-Dienstanwendungen gehostet werden

Ergebnisse der Testumgebung

Wir haben die im vorstehenden Diagramm dargestellte Topologie für unsere Testumgebung mit physischen Computern und für einen Visual Studio Team System-Auslastungstest (VSTS) verwendet.

In der folgenden Tabelle sind die technischen Spezifikationen der für die Tests verwendeten Computer aufgeführt:

Serverkomponenten	Server mit SharePoint
Prozessoren	Intel Xeon-CPUs @2,33 GHz (2 Prozessoren, 8 Prozessorkerne, 8 Threads)
RAM	24 GB
Betriebssystem	Windows Server 2008 R2 Enterprise, 64-Bit
Anzahl der Netzwerkadapter	2
Geschwindigkeit der Netzwerkadapter	1 Gbit/s
Authentifizierung	Keine \endash anonym
Lastenausgleichstyp	Windows-softwarebasierter Lastenausgleich
Softwareversion	SharePoint Server 2013

Serverkomponenten	Datenbankserver
Prozessoren	Intel Xeon-CPUs MP7130M @2,79 GHz (2 Prozessoren, 8 Prozessorkerne, 16 Threads)
RAM	16 GB
Betriebssystem	Windows Server 2008 R2 Enterprise, 64-Bit
Datenträgerarray	2 x Dell PERC 5/E
Anzahl der Netzwerkadapter	1
Geschwindigkeit der Netzwerkadapter	1 Gigabit oder Gbit/s
Authentifizierung	NTLM
Softwareversion	Microsoft SQL Server 2008 R2 SP1

In der folgenden Tabelle sind unsere Ergebnisse einer zehnminütigen Ausführung aufgeführt:

Testfeatures	Grüne Zone	Rote Zone
Anzahl der VSTS-Benutzer:	5	15
Serverantwortzeit, 50. Quantil:	69 ms	112 ms
Serverantwortzeit, 95. Quantil:	92 ms	221 ms
Seitenansichten pro Sekunde:	57	93
Durchschnittliche CPU-Auslastung (Anwendungsserver und Front-End-Webserver)	55	97
Durchschnittliche CPU-Auslastung ( SQL Server)	7	9
Maximale Arbeitsspeicherauslastung (Anwendungsserver und Front-End-Webserver)	8.9 GB	8.9 GB

Auswirkungen des Ausgabecaches

Zwischenspeichern der Ausgabe ist eine effiziente Möglichkeit, die Belastung SharePoint Server 2013 in Szenarien für die Veröffentlichung zu reduzieren. Weitere Informationen finden Sie unter Planen von Zwischenspeicherung und Leistung in SharePoint Server.

In der folgenden Tabelle sind unsere Ergebnisse einer zehnminütigen Ausführung mit aktiviertem Ausgabecache und einem Trefferverhältnis von 90 % aufgeführt:

Testfeatures	Grüne Zone	Rote Zone
Anzahl der VSTS-Benutzer:	5	15
Serverantwortzeit, 50. Quantil:	2 ms	2 ms
Serverantwortzeit, 95. Quantil:	74 ms	88 ms
Seitenansichten pro Sekunde:	190	418
Durchschnittliche CPU-Auslastung (Anwendungsserver und Front-End-Webserver)	58	85
Durchschnittliche CPU-Auslastung ( SQL Server)	5	7
Maximale Arbeitsspeicherauslastung (Anwendungsserver und Front-End-Webserver)	9.2 GB	9.4 GB

Aus den Testergebnissen geht hervor, dass durch die Verwendung der Ausgabezwischenspeicherung die Durchsätze einer SharePoint-Veröffentlichungswebsite erheblich erhöht und die Serverantwortzeiten reduziert werden können. Bei vom Ausgabecache verarbeiteten Anforderungen sind sehr kurze Reaktionszeiten möglich.

Im folgenden Diagramm sehen Sie eine Zusammenfassung unserer Testergebnisse:

Abbildung 9: Auswirkungen der Ausgabezwischenspeicherung mit einem Cachetrefferverhältnis von 90 %

Auswirkungen der verwalteten Navigation

In SharePoint Server 2013 kann die Veröffentlichungswebsites auch verwalteten Navigation verwenden. Weitere Informationen zur Einrichtung finden Sie unter Übersicht über die verwaltete Navigation in SharePoint Server.

Für unsere Testwebsite mit der verwalteten Navigation haben wir dieselben Tests wie für die Testwebsite mit der strukturierten Navigation ausgeführt. Aus unseren Tests geht hervor, dass es keine wesentlichen Leistungsunterschiede zwischen Websites mit verwalteter oder mit strukturierter Navigation gibt.

Testfeatures	Grüne Zone	Rote Zone
Anzahl der VSTS-Benutzer:	5	15
Serverantwortzeit, 50. Quantil:	70 ms	111 ms
Serverantwortzeit, 95. Quantil:	95 ms	215 ms
Seitenansichten pro Sekunde:	56	94
Durchschnittliche CPU-Auslastung (Anwendungsserver und Front-End-Webserver)	54	97
Durchschnittliche CPU-Auslastung ( SQL Server)	7	9
Maximale Arbeitsspeicherauslastung (Anwendungsserver und Front-End-Webserver)	8 GB	8 GB

Im folgenden Diagramm sind die unterschiedlichen Navigationstypen für dieselbe Website aufgeführt:

Abbildung 10: Verwaltete Navigation und strukturierte Navigation im Vergleich

Auswirkungen des Hinzufügens von Computern (der horizontalen Skalierung)

Wenn Sie feststellen, dass Sie weitere Durchsatz aus einer SharePoint-Bereitstellung benötigen, ist das Skalieren (sich eine Erhöhung der Anzahl der Computer, auf denen SharePoint Server 2013 gehostet) Option zu berücksichtigen sind. Das folgende Diagramm zeigt, wie Durchsatz erhöht, wie wir mehr Computer in der Farm hinzuzufügen:

Abbildung 11: Auswirkungen des Hinzufügens von Front-End-Webservern auf den Durchsatz

Bei unseren Tests erhöht wir die Last auf dem Server mit SharePoint Server 2013 für jeden Computer, der hinzugefügt wurde, damit die Serverantwortzeiten etwa der gleichen (rund um 11 Millisekunden für die grüne Zone rund 250 Millisekunden für die rote Zone) wurden.

Websites zur Veröffentlichung über die direkte Dokumenterstellung mit authentifizierten Benutzern

Die SharePoint-Veröffentlichung wird häufig im Intranet verwendet, wo Benutzer, die auf eine Website zugreifen, authentifiziert werden. In diesem Abschnitt werden unsere Tests mit authentifizierten Benutzern und die jeweiligen Auswirkungen aufgezeigt.

In der folgenden Tabelle sind die Testergebnisse der Veröffentlichungswebsites mit direkter Dokumenterstellung aufgeführt, auf die authentifizierte Benutzer über die anspruchsbasierte Authentifizierung mit NTLM zugegriffen haben. Bei diesen Tests wurde dieselbe Hardware wie bei den im vorherigen Abschnitt genannten Tests verwendet.

Testfeatures	Grüne Zone	Rote Zone
Anzahl der VSTS-Benutzer:	5	15
Serverantwortzeit, 50. Quantil:	76 ms	107 ms
Serverantwortzeit, 95. Quantil:	103 ms	194 ms
Seitenansichten pro Sekunde:	54	100
Durchschnittliche CPU-Auslastung (Anwendungsserver und Front-End-Webserver)	50	97
Durchschnittliche CPU-Auslastung ( SQL Server)	6	9
Maximale Arbeitsspeicherauslastung (Anwendungsserver und Front-End-Webserver)	9.5 GB	9.5 GB

Aus den Zahlen geht hervor, dass es in Bezug auf Serverantwortzeiten und Durchsatz keine wesentlichen Unterschiede zwischen anonymen und authentifizierten Anforderungen gibt.

Im folgenden Diagramm sind die unterschiedlichen Anforderungstypen für dieselbe Website aufgeführt:

Abbildung 12: Anonyme und authentifizierte Anforderungen im Vergleich

Auswirkungen des Ausgabecaches in Authentifizierungsszenarien

Bei an den Server gesendeten authentifizierten Anforderungen ist ein Roundtrip zur Inhaltsdatenbank erforderlich, um sicherzustellen, dass das auf den Inhalt zugreifende Konto über Berechtigungen zum Anzeigen des Inhalts verfügt. Das bedeutet, dass sich die Leistungsmerkmale der Ausgabezwischenspeicherung von authentifizierten Websites von den Leistungsmerkmalen anonymer Websites unterscheiden.

In der folgenden Tabelle sind unsere Ergebnisse einer zehnminütigen Ausführung mit aktiviertem Ausgabecache und einem Cachetrefferverhältnis von 90 % aufgeführt:

Testfeatures	Grüne Zone	Rote Zone
Anzahl der VSTS-Benutzer:	6	18
Serverantwortzeit, 50. Quantil:	17 ms	29 ms
Serverantwortzeit, 95. Quantil:	87 ms	118 ms
Seitenansichten pro Sekunde:	114	236
Durchschnittliche CPU-Auslastung (Anwendungsserver und Front-End-Webserver)	50	97
Durchschnittliche CPU-Auslastung (SQL Server)	7	10
Maximale Arbeitsspeicherauslastung (Anwendungsserver und Front-End-Webserver)	9.9 GB	10 GB

Im folgenden Diagramm sehen Sie eine Zusammenfassung dieser Ergebnisse:

Abbildung 13: Auswirkungen der authentifizierten Ausgabezwischenspeicherung

See also

Planen von Web Content Management in SharePoint Server
Konfigurieren von Web Content Management-Lösungen in SharePoint Server
Verwalten von Web Content Management in SharePoint Server
Configure cache settings for a web application in SharePoint Server
Planen von Zwischenspeicherung und Leistung in SharePoint Server