Schätzen der Kapazität und Leistung von Web Content Management (SharePoint Server 2013)
GILT FÜR:
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
Zum Veröffentlichen von Inhalten, auf die anonyme Benutzer auf einer Internetwebsite oder authentifizierte Benutzer auf einer Intranetwebsite zugreifen, verwenden Unternehmen häufig SharePoint Server 2013. Dieser Artikel enthält Kapazitäts- und Leistungsdaten, mit deren Hilfe geplant werden kann, wie viele Computer von welchem Typ benötigt werden, um in SharePoint Server 2013 Inhalte zu veröffentlichen und Webinhalte zu verwalten.
Die SharePoint-Veröffentlichung umfasst unterschiedliche Typen von Veröffentlichungswebsites und verschiedene zugehörige Methoden, die für die einzelnen Websites verfügbar sind. Die Veröffentlichungsfeatures von SharePoint Server 2013 sollen Sie beim Erstellen firmenspezifischer Internet-, Intranet- und Extranetwebsites unterstützen. Weitere Informationen zur SharePoint Server 2013-Veröffentlichung finden Sie unter Übersicht über die Veröffentlichung in Internet-, Intranet- und Extranetwebsites 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.
Hinweis
Mit websiteübergreifender Veröffentlichung ist in diesem Artikel die websiteübergreifende Veröffentlichung von Sammlungen gemeint.
In SharePoint Server 2013 ermöglicht die verwaltete Navigation eine taxonomiegesteuerte Navigation auf einer 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.
Hinweis
Die in diesem Artikel behandelten Szenarien können für Websites sowohl durch die websiteübergreifende Veröffentlichung als auch durch die direkte Dokumenterstellung erreicht werden. Die Features für die websiteübergreifende Veröffentlichung und für die verwaltete Navigation sind nicht voneinander abhängig und können somit voneinander unabhängig verwendet werden.
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 Zeit, die der Server benötigt, um eine Anforderung zu verarbeiten, was sich auf die Zeit auswirkt, die ein Benutzer zum Anzeigen der Seite benötigt. Die in diesem Dokument angegebenen Serverantwortzeiten sind die Werte des 95. und 50. Perzentils. Diese Werte bedeuten, dass 95 % und 50 % der Anforderungen schneller sind als der bereitgestellte Wert. Wir messen diese Werte mithilfe der "Dauer", die in der SharePoint-Nutzungsdatenbank für eine bestimmte Anforderung aufgezeichnet wurde.
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
Zum besseren Verständnis dieses Artikels müssen Sie mit den wichtigsten Konzepten der Kapazitätsverwaltung in SharePoint Server 2013 vertraut sein. Die folgenden Artikel umfassen Erörterungen der empfohlenen Vorgehensweise bei der Kapazitätsverwaltung und bieten weiteren Kontext zur effizienten Verwendung der in diesem Artikel enthaltenen Informationen.
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 Webinhaltsverwaltungslösungen in SharePoint Server.
Weitere Informationen zu Kapazität und Leistung zum Besseren Verständnis der Daten in diesem Artikel finden Sie unter Leistungsplanung in SharePoint Server 2013.
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
Hinweis
Bei den in diesem Test verwendeten Computern handelt es sich um physische Computer unter Windows Server 2008 R2. Empfehlungen zur Verwendung von virtuellen Computern und Windows Server 2012 finden Sie in der Dokumentation zur Kapazitätsplanung und unter Kapazitätsplanung für SharePoint Server 2013.
Wichtig
Die Konfiguration unserer Testumgebungstopologie wurde für suchgesteuerte Veröffentlichungsszenarien optimiert. Diese Konfiguration unterscheidet sich von den Zusammenarbeitstypen von SharePoint-Bereitstellungen. In unserer Konfiguration werden beispielsweise die Front-End-Webserver als Suchindexserver verwendet, um die beste Leistung zu erzielen. > In unserer Testumgebungstopologie haben wir erfahren, dass der Computer, der den Anwendungsserver hostet, nicht ausgelastet war. Deshalb haben wir uns entschieden, den verteilten Cachedienst auf diesem Anwendungsserver und nicht auf einem dedizierten Server zu hosten. In Ihrer Umgebung möchten Sie den verteilten Cachedienst möglicherweise auf einem dedizierten Server hosten. Um eine optimale Leistung zu erzielen, sollten Sie den verteilten Cachedienst nicht auf einem Front-End-Webserver hosten, dem die Suchindexserver-Rolle zugewiesen ist.
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.
Hinweis
Bei unseren VSTS-Tests haben wir keine Browserzwischenspeicherung und keine abhängigen Anforderungen (wie beispielsweise Bilder oder JavaScript-Dateien) verwendet. Die Anzahl der abhängigen Anforderungen kann je nach Anpassung Ihrer Veröffentlichungswebsite erheblich variieren. > Die Seiten, die wir in unseren Tests verwendet haben, machten fast 50 Seitenladezeit 1 (PLT1) Anforderungstypen (leerer Browsercache) und etwa 3 Anforderungen für PLT2-Anforderungstypen (nachfolgende Anforderungen mit Ergebnissen aus dem Browsercache). In der Regel verarbeitet der SharePoint-BLOB-Cache Anforderungen für diese Elemente, und unsere Leistungswerte werden dadurch nicht wesentlich verändert.
| 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 – 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 erwartet wird, dass die SharePoint-Bereitstellung im Vergleich zum oben beschriebenen Baselinefall mehr oder weniger Datenverkehr empfängt, sollten Sie die Anzahl der Computer ändern, die mit der Rolle Index und Front-End-Webserver in der Farm ausgeführt werden, um diesen Datenverkehr zu bewältigen. Das folgende Diagramm zeigt die Ergebnisse für das Horizontale Aufskalieren derselben websiteübergreifenden Veröffentlichungswebsite mit unterschiedlichen Auslastungsmustern und einer unterschiedlichen Anzahl von Computern, die als Front-End-Webserver mit Indexknoten verwendet werden, beginnend mit einem einzelnen Computer in der Front-End-Webserverrolle mit Indexknoten und bis zu sechs Computern:
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 das horizontale Hochskalieren anzuzeigen. Die tatsächliche Leistung ändert sich abhängig davon, wie die SharePoint-Bereitstellung erstellt wird.
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, finden Sie informationen zur richtigen Größe Ihrer Suchtopologie unter Skalieren der Suche nach Internetwebsites in SharePoint Server .
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.
Verwenden Sie auf einer Seite nicht mehr als fünf synchrone Webparts für die Inhaltssuche oder für die Wiederverwendung von Katalogelementen. Während der Verarbeitung einer Anforderung für eine Seite führt SharePoint Server 2013 maximal fünf Abfragen parallel aus und gibt die Ergebnisse zurück. Bei mehr als fünf Abfragen auf einer Seite führt SharePoint Server 2013 die ersten fünf Abfragen aus, bevor dann die Ausführung der nächsten Gruppe von fünf Abfragen erfolgt. Wenn auf Seiten mehr als fünf Webparts für die Inhaltssuche oder für die Wiederverwendung von Katalogelementen benötigt werden, können Sie die zusätzlichen Inhaltssuche-Webparts im asynchronen Modus ausführen 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 Facettennavigation 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 Suche für Internetwebsites 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. Sie können Microsoft PowerShell verwenden, um die Cachedauer für die Webanwendung zu konfigurieren, 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.
Es wird empfohlen, den Cache immer auf Veröffentlichungsseiten zu verwenden, die hohen Datenverkehr erhalten. Einige Beispiele für diese Arten von Seiten sind die Homepage der Website und Kategorieseiten, die Suchwebparts verwenden. Es wird nicht empfohlen, die Zwischenspeicherung für Katalogelementseiten durchzuführen. Da auf eine einzelne Katalogelementseite viel seltener zugegriffen wird als auf einer Startseite, und es lohnt sich möglicherweise nicht, 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.
Legen Sie den Wert der Untereigenschaft "TryCache" in DataProviderJSON der -Eigenschaft des Webparts fest, um das Zwischenspeicherungsverhalten für ein einzelnes Webpart für die Verwendung (oder Nichtverwendung) des Caches für anonyme Suchergebnisse zu konfigurieren. 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
In Veröffentlichungsszenarien stellt die Ausgabezwischenspeicherung eine effiziente Methode zur Reduzierung der SharePoint Server 2013-Auslastung dar. Ausführlichere Informationen zur Funktionsweise des Ausgabecaches 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.
Wichtig
In SharePoint Server 2013 besteht ein bekanntes Problem, wenn Seiten mit aktivierter Ausgabezwischenspeicherung auch Inhaltssuche-Webparts enthalten. Installieren Sie das Update für SharePoint Server 2013: 12. März 2013 , um dieses Problem in Ihrer Bereitstellung zu vermeiden.
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
Hinweis
Für Inhaltssuche-Webparts gibt es eine Einstellung für die Ausführung im asynchronen Modus. Die Ausgabezwischenspeicherung ist von der Auslastung asynchroner Inhaltssuche-Webparts ausgenommen.
Verarbeitung der Verwendungsanalyse
Damit die Verwendungsanalysedaten verwendet werden können, verarbeitet SharePoint Server 2013 die in der Verwendungsdatenbank vorhandenen Daten. In unserer Topologie wird die Analyseverarbeitung auf dem Knoten ausgeführt, der den Suchverwaltungsknoten, den verteilten Cachedienst und andere Dienstanwendungen enthält. Weitere Informationen finden Sie unter Übersicht über die Analyseverarbeitung in SharePoint Server.
Wir haben einige Analyseverarbeitungszeiten mithilfe der in unseren vorherigen Tests verwendeten websiteübergreifenden Veröffentlichungswebsite gemessen. Wir haben die Zeit gemessen, die SharePoint Server 2013 benötigt, um eine große Anzahl von Klickereignissen auf den Seiten der Website zu verarbeiten. Diese Ergebnisse stammen zwar von einer websiteübergreifenden Veröffentlichungswebsite, lassen sich aber auch auf Websites übertragen, auf denen die Methode zur Veröffentlichung über die direkte Dokumenterstellung verwendet wird.
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
Die SharePoint-Veröffentlichung wird häufig auf Intranetwebsites verwendet. Mit SharePoint Server 2013 können diese Websites auch durch die websiteübergreifende Veröffentlichung unterstützt werden. In den folgenden Abschnitten werden einige wichtige Merkmale aufgeführt, die Sie beim Planen einer websiteübergreifenden Veröffentlichungswebsite berücksichtigen sollten, auf die authentifizierte Benutzer zugreifen. Außer den in den folgenden Abschnitten erwähnten Ausnahmen gelten für Websites, auf die authentifizierte Benutzer zugreifen, auch die für anonym aufgerufene Websites geltenden Regeln.
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.
Wichtig
Für Inhaltssuche-Webparts gibt es eine Einstellung, die bei entsprechender Aktivierung die Ausführung im asynchronen Modus zur Folge hat. Der Ausgabecache ist von der Auslastung asynchroner Inhaltssuche-Webparts ausgenommen.
Größerer Suchindex
Abhängig von der Größe des Unternehmens, das SharePoint Server 2013 bereitstellt, wird in Intranetbereitstellungen von SharePoint Server 2013 in der Regel eine größere Anzahl von Dokumenten indiziert. Das bedeutet, das sich die zum Indizieren dieser Dokumente erforderliche Suchtopologie von der im vorherigen Abschnitt beschriebenen Topologie unterscheidet. Informationen zur richtigen Größe Ihrer SharePoint-Bereitstellung finden Sie unter Planen der Suche in SharePoint Server .
Veröffentlichung über die direkte Dokumenterstellung
Dieser Abschnitt enthält Anleitungen und Ergebnisse, die SharePoint Server 2013 verwenden, enthält jedoch keine Details zu den verschiedenen Features, die sich auf die Kapazitätsplanung auswirken. Ausführliche Informationen zu diesem Bereich finden Sie unter 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 – 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
In Veröffentlichungsszenarien stellt die Ausgabezwischenspeicherung eine effiziente Methode zur Reduzierung der SharePoint Server 2013-Auslastung dar. 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 können Sie für Veröffentlichungswebsites auch die verwaltete Navigation verwenden. Ausführliche 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 mehr Durchsatz von einer SharePoint-Bereitstellung benötigen, ist das Horizontale Hochskalieren (Erhöhen der Anzahl der Computer, auf denen SharePoint Server 2013 gehostet wird) eine Option, die Sie in Betracht ziehen sollten. Im folgenden Diagramm ist dargestellt, wie der Durchsatz bei zunehmender Computeranzahl in der Farm steigt:
Abbildung 11: Auswirkungen des Hinzufügens von Front-End-Webservern auf den Durchsatz
In unseren Tests haben wir die Auslastung auf dem Server mit SharePoint Server 2013 für jeden hinzugefügten Computer erhöht, sodass die Antwortzeiten des Servers ungefähr gleich waren (etwa 11 Millisekunden für die grüne Zone, ca. 250 Millisekunden für die rote Zone).
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
Siehe auch
Konzepte
Planen von Web Content Management in SharePoint Server
Konfigurieren von Web Content Management-Lösungen in SharePoint Server
Konfigurieren von Cacheeinstellungen für eine Webanwendung in SharePoint Server
Planen von Zwischenspeicherung und Leistung in SharePoint Server