Schätzen der Leistungs- und Kapazitätsanforderungen für Web Content Management in SharePoint Server 2010

 

Gilt für: SharePoint Server 2010

Letztes Änderungsdatum des Themas: 2016-11-30

Dieser Artikel enthält Hinweise zur Kapazitätsverwaltung von Microsoft SharePoint Server 2010-Websites, bei denen die Veröffentlichungsinfrastruktur aktiviert wurde. Dieses Dokument enthält spezifische Hinweise für SharePoint Server 2010; die erläuterten Informationen beziehen sich nicht auf SharePoint Foundation.

In diesem Artikel werden die folgenden Szenarien erläutert:

• Eine Internetveröffentlichungssite - eine Website für die Präsenz eines Unternehmens.

  Diese Art von Website wird im Internet veröffentlicht und ermöglicht es anonymen Internetbenutzern, Informationen über ein Unternehmen zu finden. Auf Websites wie diese wird Branding angewendet, und die Inhalte werden stark gesteuert.

• Eine Intranetveröffentlichungssite - eine Website für interne Nachrichten.

  Diese Art von Website wird intern innerhalb einer Organisation veröffentlicht. Ihre Hauptaufgabe besteht darin, Informationen an authentifizierte Benutzer innerhalb der Organisation weiterzugeben. Die Informationen in der Website können straff verwaltet werden, wobei manche Bereiche möglicherweise weniger stark kontrolliert werden.

• Ein Unternehmenswiki - ein Wissensrepository.

  Bei einem Unternehmenswiki handelt es sich um eine Website mit einer einzelnen Farm, die kontinuierlich anwächst, wenn Mitwirkende neue Seiten erstellen und diese mit anderen Seiten verknüpfen, die möglicherweise bereits oder noch nicht existieren. Unternehmenswikis werden in der Regel innerhalb einer Organisation veröffentlicht. Diese Website ermöglicht es Benutzern innerhalb eines Unternehmens oder einer Organisation, Wissen mithilfe einer Lösung, die in ihre SharePoint-Umgebung integriert ist und optimiert wird, zu erfassen und gemeinsam zu nutzen.

Nach der Lektüre dieses Dokuments sind Sie mit den folgenden Konzepten vertraut:

• Die Schlüsselmetriken (Durchsatz), die zur Unterstützung von vielen Lesevorgängen maximiert werden sollten.

• Verschiedene potenzielle Engpässe, die für die SharePoint Server 2010-Bereitstellung mit Web Content Management relevant sind.

• Die Bedeutung des Ausgabecaches bei der Maximierung des Durchsatzes.

• Die Auswirkungen von Schreibvorgängen auf die Benutzerfreundlichkeit für Endbenutzer beim Lesen.

Inhalt dieses Artikels

• Voraussetzungen

• Testdetails und Ansatz

• Web Content Management-Bereitstellungen

• Optimierung

• Testergebnisse und Empfehlungen

• Informationen zu den Autoren

Voraussetzungen

Ehe Sie mit der Lektüre dieses Dokuments beginnen, sollten Sie mit den Schlüsselkonzepten der SharePoint Server 2010-Kapazitätsverwaltung vertraut sein. Die folgende Dokumentation bietet Informationen über den empfohlenen Ansatz für die Kapazitätsverwaltung und enthält Kontext, der Ihnen dabei hilft, die Informationen in diesem Dokument sinnvoll einzusetzen.

Weitere konzeptionelle Informationen zur Leistung und Kapazität, die sich für das Verständnis des Kontexts der Daten in diesem Artikel als hilfreich erweisen können, finden Sie in den folgenden Dokumenten:

• Kapazitätsverwaltung und Größenanpassung für SharePoint Server 2010

• Technische Fallstudien zu Leistung und Kapazität (SharePoint Server 2010)

Testdetails und Ansatz

Bei jedem Test kommen Variablen aus der realen Welt vor, die zur Darstellung bestimmter Empfehlungen abstrahiert wurden. Deshalb ist es äußerst wichtig, dass Sie die Tests und Kontrollen in Ihrer eigenen Umgebung ausführen, um eine korrekte Skalierung sicherzustellen, die an das zu erwartende Anforderungsvolumen angepasst ist. Weitere Informationen zu den Konzepten der Kapazitätsverwaltung finden Sie unter Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht).

In diesem Artikel wird die Leistung im Zusammenhang mit Websitesammlungs-Features, der SharePoint Server-Veröffentlichungsinfrastruktur und dem Zwischenspeichern der Ausgabe erläutert. Diese Features stehen nur zur Verfügung, wenn die SharePoint Server-Veröffentlichungsinfrastruktur aktiviert ist. Dieses Feature ist standardmäßig für die Veröffentlichungsportale aktiviert.

Dataset

Die Tests wurden mithilfe eines Datasets ausgeführt, das gemeinsame Eigenschaften mit tatsächlichen Web Content Management-Bereitstellungen aufweist. Bei konstanter Auslastung wurden verschiedene Seiten angefordert. In der folgenden Tabelle wird das Dataset für diese Tests beschrieben.

Dataset

Objekt	Veröffentlichungssite
Größe der Inhaltsdatenbanken	2,63 GB
Anzahl der Inhaltsdatenbanken	1
Anzahl der Websitesammlungen	1
Anzahl der Webanwendungen	1
Anzahl der Websites	50
Seitenanzahl	20.000 Seiten, unterteilt in 20 Ordner mit jeweils 1.000 Seiten
Zusammensetzung der Seiten	Artikelseiten in einfachem HTML mit Verweisen auf zwei Bilder
Seitengröße	42 KB unkomprimiert; 12 KB komprimiert
Bilder	3.000 mit jeweils 30 KB bis 1,3 MB

Es wird die Konfiguration der Internetinformationsdienste (Internet Information Services, IIS) empfohlen, damit Dateien immer komprimiert werden, anstelle der Standardeinstellung zur dynamischen Komprimierung von Dateien. Wenn die dynamische Komprimierung aktiviert ist, werden Seiten von IIS komprimiert, bis die CPU-Auslastung über einen bestimmten Schwellenwert ansteigt. Die Komprimierung von Seiten wird erst dann von IIS fortgesetzt, wenn die Auslastung wieder unter den Schwellenwert sinkt. Die in diesem Artikel aufgeführten Tests wurden stets bei aktivierter Komprimierung durchgeführt.

In diesem Testdataset wurden nur SharePoint Server 2010-Standardfeatures verwendet, die zum Lieferumfang des Produkts gehören. Abgesehen von diesen Grundfeatures sind in Ihrer Website vermutlich Anpassungen enthalten. Deshalb ist es wichtig, dass Sie die Leistung Ihrer eigenen Lösung testen.

Hardware

Die Anzahl der Webserver in der Farm variierte von einem Test zum anderen. Bei jedem Test wurde jedoch die identische Hardware verwendet. In der folgenden Tabelle wird die Hardware von Web- und Anwendungsservern beschrieben, die bei diesen Tests verwendet wurde.

Hardwarespezifikationen für Anwendungs- und Webserver

	Webserver
Prozessoren	2 Quad-Core mit 2,33 GHz
RAM	8 GB
Betriebssystem	Windows Server 2008 (64-Bit)
Größe des SharePoint-Laufwerks	300 GB
Anzahl der Netzwerkadapter	2
Geschwindigkeit des Netzwerkadapters	1 Gigabit
Authentifizierung	Windows-Standardauthentifizierung
Lastenausgleichstyp	Hardwarelastenausgleich
Softwareversion	SharePoint Server 2010 (Vorabversion)
Lokal ausgeführte Dienste	Zentraladministration Eingehende Microsoft SharePoint Foundation-E-Mail Microsoft SharePoint Foundation-Webanwendung Microsoft SharePoint Foundation-Workflowtimerdienst

In der folgenden Tabelle wird die Hardware der Datenbankserver für diese Tests beschrieben.

Hardwarespezifikationen für Datenbankserver

	Datenbankserver
Prozessoren	4 Quad-Core mit 3,19 GHz
RAM	16 GB
Betriebssystem	Windows Server 2008 (64-Bit)
Speicherung	15 Festplatten mit 300 GB @ 15.000 RPM
Anzahl der Netzwerkadapter	2
Geschwindigkeit des Netzwerkadapters	1 Gigabit
Authentifizierung	NTLM
Softwareversion	Microsoft SQL Server 2008

Glossar

In diesem Dokument werden einige Fachbegriffe verwendet. Es folgen die Definitionen zu einigen Schlüsselbegriffen:

• Anforderungen pro Sekunde (RPS) Die Anzahl der von einer Farm oder einem Server in einer Sekunde empfangenen Anforderungen. Die Server- und Farmauslastung wird häufig mit diesem Wert gemessen.

  Beachten Sie, dass zwischen Anforderungen und dem Laden von Seiten ein Unterschied besteht; jede Seite enthält verschiedene Komponenten, durch die beim Laden der Seite eine oder mehrere Anforderungen erstellt werden. Deshalb werden beim Laden einer einzelnen Seite verschiedene Anforderungen erstellt. In der Regel werden beim Messen von RPS Überprüfungen der Authentifizierung und Ereignisse, die wenig Ressourcen benötigen, nicht gezählt.

• Grüner Bereich   Dies ist der Zustand, in dem der Server die folgenden Kriterien einhalten kann:

  • Die serverseitige Wartezeit beträgt bei mindestens 75 Prozent der Anforderungen weniger als 1 Sekunde.

  • Alle Server weisen eine CPU-Auslastung von weniger als 50 Prozent auf.

  • Die Fehlerrate ist niedriger als 0,01 Prozent.

Web Content Management-Bereitstellungen

Es existieren zwei Modelle für das Erstellen von Inhalten in SharePoint-Veröffentlichungssites, die sich auf die Wahl der Serverfarmtopologie auswirken können.

Beim Modell der direkten Dokumenterstellung wird eine einzelne Websitesammlung von Autoren und Besuchern gemeinsam genutzt. Autoren können Inhalte erstellen und jederzeit aktualisieren, was zu einer variablen Verteilung von Lese- und Schreibvorgängen im Verlauf eines bestimmten Tages führt. In einer solchen Serverfarm werden in der Regel viele Lesevorgänge und eine begrenzte Anzahl von Schreibvorgängen verzeichnet.

Im folgenden Diagramm wird die Funktionsweise der direkten Dokumenterstellung aus Sicht der Topologie dargestellt.

Beim Modell der Inhaltsbereitstellung wird das Erstellen und Veröffentlichen von Inhalten von mehreren Websitesammlungen getrennt und exklusiv unterstützt. Inhalt wird in der Erstellungsumgebung erstellt und dann in regelmäßigen Abständen in der Veröffentlichungsumgebung bereitgestellt, um von Besuchern gelesen zu werden. In der Veröffentlichungsumgebung werden in erster Linie Leseanforderungen ausgeführt, mit Ausnahme der Bereitstellung von Inhalt aus der Erstellungsumgebung. Im Gegensatz zum Modell der direkten Dokumenterstellung kann die Serverlast, die von der Inhaltsbereitstellung ausgeht, auf regelmäßige Intervalle angepasst werden.

Im folgenden Diagramm wird die Funktionsweise der Inhaltsbereitstellung aus Sicht der Topologie dargestellt.

Diese Modelle der Inhaltserstellung schließen sich gegenseitig aus.

Obwohl für Internetveröffentlichungssites und Intranetveröffentlichungssites sowohl das Modell der direkten Dokumenterstellung als auch der Inhaltsbereitstellung verwendet werden kann, werden Unternehmenswikis am besten mit der direkten Inhaltserstellung ausgeführt. Bei einem Unternehmenswiki werden in der Regel mehr Schreibvorgänge als Lesevorgänge verzeichnet, da ein höherer Anteil von Benutzern Seiten bearbeiten kann. Unternehmenswikiseiten unterscheiden sich von Veröffentlichungsseiten und zeichnen sich durch andere Leistungseigenschaften aus.

Optimierung

Dieser Abschnitt enthält Informationen über die Optimierung Ihrer Web Content Management-Umgebung. Zur Optimierung der Umgebung gehört auch die Verwaltung des Durchsatzes, von Engpässen und der Zwischenspeicherung.

Inhalt dieses Abschnitts:

• Durchsatz als Schlüsselmetrik

• Engpässe und Abhilfe

• Hilfe durch Caching

Durchsatz als Schlüsselmetrik

Durchsatz und Antwortzeit sind die wichtigsten Metriken, die bei der Kapazitätsplanung einer Web Content Management-Bereitstellung von SharePoint Server 2010 optimiert werden müssen. Der Durchsatz gibt die Anzahl der Vorgänge an, die in einer Serverfarm pro Sekunde durchgeführt werden können, gemessen in Anforderungen pro Sekunde (RPS).

Engpässe und Abhilfe

Eine Systemressource, durch die bei einem Mangel verhindert wird, dass zusätzliche Anforderungen in der Serverfarm bereitgestellt werden, ist ein Engpass. Im folgenden Diagramm werden die Elemente einer Serverfarm dargestellt, die zu Engpässen werden können und überwacht werden sollten.

CPU-Auslastung der Webserver

Die Webserver-CPU sollte den Engpass in einer gut abgestimmten Topologie darstellen, da sie die am einfachsten zu skalierende Komponente darstellt. Anforderungen werden vom Lastenausgleichsmodul zwischen den Webservern weitergeleitet, der auch sicherstellt, dass kein einzelner Server deutlich mehr beansprucht wird als andere.

Obwohl zusätzliche Benutzer die Website besuchen können, nachdem die Webserver-CPU vollständig ausgelastet ist, steigt die Serverantwortzeit für diese Benutzer. Dieses Verhalten erweist sich bei der Verwaltung von Belastungsspitzen beim Anforderungsvolumen als hilfreich. Eine anhaltende Auslastung hingegen, die über die Kapazität der Serverfarm hinausgeht, führt schließlich zu Rückständen, die so groß sind, dass der Schwellenwert für wartende Anforderungen überschritten wird. An diesem Punkt werden die Anforderungen von den Webservern gedrosselt und der HTTP-Fehler 503 ausgegeben. In der folgenden Abbildung ist das Absinken der Serverantwortzeit nach Überschreiten des Schwellenwerts für wartende Anforderungen dargestellt, weil ausschließlich HTTP-Fehler ausgegeben werden.

Die folgenden Änderungen werden in diesem Diagramm veranschaulicht:

1. Antwortzeit steigt, wenn die CPU-Auslastung der Webserver gegen 100 Prozent steigt.

2. Nach Überschreiten des Schwellenwerts für wartende Anforderungen werden bei weiteren Anforderungen Fehler ausgegeben.

Sonstige Engpässe

Wenn die Webserver-CPU nicht den Engpass darstellt, sollten als nächstes die Farmtopologie, die Farmkonfiguration oder der Inhalt der bereitgestellten Seiten als mögliche Engpässe überprüft werden. Potenzielle Engpässe können u. a. die folgenden Elemente sein:

1. Netzwerk    In Situationen mit hohem Durchsatz kann entweder das Netzwerk zwischen dem Webserver und dem Datenbankserver oder zwischen dem Webserver und Endbenutzern gesättigt sein. Sie können diese Situation vermeiden, indem Dual Gigabit-Netzwerkadapter für die Webserver verwendet werden.

2. Datenbankserver-CPU    Wenn die CPU des Datenbankservers den Engpass darstellt, kann der maximale Durchsatz der Farm durch Hinzufügen von Webservern zur Serverfarm nicht gesteigert werden. Ein Engpass der Datenbank-CPU, jedoch nicht der Webserver-CPUs, kann mit zwei Situationen zusammenhängen:

   1. Unzureichende Cacheeinstellungen oder äußerst langsame Seiten, vor allem jene, deren Ausgabe nicht zwischengespeichert wird. Dieser Zustand zeichnet sich durch eine hohe CPU-Auslastung des Datenbankservers, kombiniert mit niedrigem oder mittlerem Durchsatz und niedriger oder mittlerer Webserverauslastung aus.

   2. Möglicherweise hat der Datenbankserver die Kapazitätsgrenze für den für die Farm erforderlichen Durchsatz erreicht. Dieser Zustand zeichnet sich durch eine hohe CPU-Auslastung von Webserver und Datenbankserver bei hohem Durchsatz aus.

Hilfe durch Caching

In SharePoint Server 2010 werden drei Arten von Caching verwendet. Gemeinsames Ziel dieser Caches ist es, die Effizienz durch Senken der Aufrufe an die Datenbank nach häufig angeforderten Daten zu verbessern. Nachfolgende Anforderungen einer Seite können vom Cache des Webservers bedient werden, was eine signifikant niedrigere Ressourcenauslastung auf den Web- und Datenbankservern zur Folge hat.

Die drei Arten des Caching sind folgende:

• Ausgabecache   Dieser Cache speichert angeforderte Seiteninhalte im Arbeitsspeicher des Webservers. Weitere Informationen zum Ausgabecache finden Sie unter Ausgabezwischenspeicherung und Cacheprofile (https://go.microsoft.com/fwlink/?linkid=121543&clcid=0x407).

• Objektcache   Dieser Cache speichert SharePoint-Objekte, wie Web- und Listenelement-Metadaten, im Arbeitsspeicher des Webservers. Weitere Informationen zum Objektcache finden Sie unter Objectzwischenspeicherung (https://go.microsoft.com/fwlink/?linkid=123948&clcid=0x407).

• Datenträgerbasierter Cache für BLOBs (Binary Large Objects)   Dieser Cache speichert Bild-, Sound-, Grafikdateien sowie andere umfangreiche Binärdateien auf Datenträgern. Weitere Informationen zum BLOB-Cache finden Sie unter Datenträgerbasiertes Zwischenspeichern für BLOBs (https://go.microsoft.com/fwlink/?linkid=123947&clcid=0x407).

Jeder dieser Caches ist für die Beibehaltung eines hohen Durchsatzes wichtig. Die Aktivierung des Ausgabecaches hat jedoch die stärksten Auswirkungen und wird in diesem Artikel ausführlich besprochen.

Testergebnisse und Empfehlungen

In diesem Abschnitt werden bestimmte Testbereiche erläutert und Empfehlungen gegeben, die aus diesen Tests resultieren.

Inhalt dieses Abschnitts:

• Auswirkungen aus der Aktivierung des Ausgabecaches

• Anonyme und authentifizierte Benutzer

• Skalierungseigenschaften von Lese- und Schreibvorgängen

• Einschränkungen im Zusammenhang mit dem Ausgabecache

• Auswirkungen des Volumens von Lesevorgängen auf die CPU und die Antwortzeit

• Auswirkungen von Schreibvorgängen auf den Durchsatz

• Auswirkungen der Inhaltsbereitstellung

• Auswirkungen von Datenbankmomentaufnahmen während des Exports im Rahmen der Inhaltsbereitstellung

• Eigenschaften von Inhalten

Auswirkungen aus der Aktivierung des Ausgabecaches

Der Ausgabecache zeichnet sich als ein wertvolles Feature bei der Optimierung einer SharePoint Server 2010-Lösung für hohe Mengen an Lesevorgängen aus.

Im Rahmen dieser Tests wurde zur Messung der maximalen RPS die Anzahl der aktiven Benutzer, die Anforderungen an die Farm sendeten, so lange gesteigert, bis der Datenbankserver oder die Webserver 100 Prozent erreichten und einen Engpass darstellten. Der Test wurde auf den Farmtopologien 1x1 (ein Webserver und ein Datenbankserver), 2x1, 4x1 und 8x1 ausgeführt, um die Auswirkungen durch die horizontale Skalierung der Webserver bei verschiedenen Ausgabecache-Trefferraten vorzuführen.

Ausgabecache-Trefferrate

Bei der Ausgabecache-Trefferrate werden die Ausgabecachetreffer im Verhältnis zu Cachefehlern gemessen.

• Ein Cachetreffer tritt auf, wenn der Cache eine Anforderung nach Objektdaten erhält, die bereits im Cache gespeichert sind.

• Ein Cachefehler tritt auf, wenn eine Anforderung nach Objektdaten eintrifft, die nicht im Cache gespeichert sind. Bei einem Cachefehler versucht der Cache, die angeforderten Objektdaten so zu speichern, dass nachfolgende Anforderungen dieser Daten einen Cachetreffer zur Folge haben.

Eine Seitenanforderung kann aus verschiedenen Gründen zu einem Cachefehler führen.

• Seiten, die so konfiguriert wurden, dass kein Ausgabecache verwendet wird.

• Personalisierte Seiten, beispielsweise Seiten mit Daten, die für den aktuellen Benutzer spezifisch sind.

• Erstmaliges Durchsuchen per Ausgabecache-Variationsschlüssel.

• Erstmaliges Durchsuchen nach Ablauf des zwischengespeicherten Inhalts.

Im folgenden Diagramm werden die Auswirkungen des Zwischenspeicherns von Ausgaben auf den Spitzendurchsatz in Farmen mit einer Größe zwischen einem und vier Webservern und einem Datenbankserver dargestellt.

Die folgende Tabelle enthält eine Liste der Auswirkungen der Ausgabecache-Trefferraten auf Farmtopologien mit 1 bis 4 Webservern und einem Datenbankserver.

Auswirkungen der Ausgabecache-Trefferrate auf verschiedene Farmtopologien

Ausgabecache-Trefferrate	Measure	1x1	2x1	4x1
100%	Maximale RPS CPU-Auslastung von SQL Server	3.463 0%	7.331 0%	11.032 0%
95%	Maximale RPS CPU-Auslastung von SQL Server	2.137 5,93%	3.945 12,00%	5.937 21,80%
90%	Maximale RPS CPU-Auslastung von SQL Server	1.518 7,12%	2.864 14,40%	4.518 28,00%
50%	Maximale RPS CPU-Auslastung von SQL Server	459 9,86%	913 19,50%	1.596 42,00%
0%	Maximale RPS CPU-Auslastung von SQL Server	172 9,53%	339 19,00%	638 36,30%

Schlussfolgerungen und Empfehlungen im Hinblick auf die Aktivierung des Ausgabecaches

Höhere Ausgabecache-Trefferraten haben signifikante Steigerungen der maximalen RPS zur Folge. Deshalb wird die Aktivierung des Ausgabecaches empfohlen, um die SharePoint Server 2010-Veröffentlichungslösung zu optimieren. Der Ausgabecache kann auf der Seite mit den Ausgabecacheeinstellungen für die Websitesammlung konfiguriert werden. Weitere Informationen finden Sie unter Konfigurieren der Seitenausgabe-Cacheeinstellungen für eine Websitesammlung (https://go.microsoft.com/fwlink/?linkid=205058&clcid=0x407) auf der Website Office.Microsoft.com.

In Tests mit aktiviertem Ausgabecache wurde die erste Anforderung, bei der eine Seite zwischengespeichert wurde, weggelassen; ein bestimmter Prozentsatz von Seiten sind also bereits im Cache gespeichert. Wenn ein Benutzer zuerst eine Seite anfordert, die nicht zwischengespeichert ist, wird die Seite dem Cache hinzugefügt. Erreicht der Cache die maximale Kapazität, werden die Daten, deren Anforderung am längsten zurückliegt, aus dem Cache entfernt.

Bei der Ausgabecache-Trefferrate von 0 Prozent wird der kurze Zeitraum in einer Umgebung simuliert, während dem der Ausgabecache nach dem Leeren wieder aufgefüllt wird. Dies findet beispielsweise täglich in einer realen Umgebung statt, wenn der Anwendungspool wiederverwendet wird. Die adäquate vertikale oder horizontale Skalierung Ihrer Hardware ist wichtig in Situationen mit einer Cache-Trefferrate von 0 Prozent für den kurzen Zeitraum zwischen der Wiederverwendung des Anwendungspools und dem nächsten Anfordern und Zwischenspeichern von Seiten. Die Cachetrefferrate von 0 Prozent simuliert auch eine Umgebung, in der der Ausgabespeicher nicht aktiviert wurde.

Anonyme und authentifizierte Benutzer

Im vorhergehenden Test wurde angenommen, dass alle Anforderungen für die Website von anonymen Lesern stammen. In Ihrer Website sind einige oder sogar alle Benutzer möglicherweise authentifiziert. Beispiele für authentifizierte Leseszenarien sind u. a. eine Intranetveröffentlichungssite in einem Unternehmen und für Mitglieder vorbehaltene Inhalte einer Internetwebsite.

Mithilfe von Ausgabecacheprofilen können Sie das Ausgabecacheverhalten für authentifizierte Benutzer festlegen, das vom Verhalten für anonyme Benutzer abweicht.

Cacheprofile

In den Cacheprofilen werden Einstellungen gesammelt, die Sie auf Seiten, Seitenelemente, Inhaltstypen und Skalierungsebenen in einer Websitebereitstellung anwenden können. Durch ein Cacheprofil werden die folgenden Arten von Cacheverhalten definiert:

• Die Zeitdauer, die Elemente im Cache aufbewahrt werden sollten.

• Die Sicherheitsrichtlinie für Trimming.

• Das Ablaufdatum von Einstellungen, wie z. B. Dauer und Änderungen.

• Die Variationen zwischengespeicherter Inhalte, z. B. auf der Grundlage von Benutzerberechtigungen, Benutzerrechten und sonstigen benutzerdefinierten Variablen.

Alle Änderungen am Cacheprofil wirken sich unmittelbar auf die entsprechenden Inhalte der Website aus. Sie können verschiedene Cacheprofile für anonyme Benutzer und authentifizierte Benutzer festlegen.

Für anonyme Benutzer wurde das Ausgabecacheprofil Öffentliches Internet (vollständig anonym) verwendet, während für authentifizierte Benutzer das Ausgabecacheprofil Extranet (veröffentlichte Website) verwendet wurde.

Im folgenden Diagramm sind die Auswirkungen des authentifizierten Durchsatzes auf die CPU-Auslastung des Datenbankservers dargestellt.

Als Authentifizierungsmodell wurde die Windows-Standardauthentifizierung verwendet. Obwohl die Verwendung der Windows-Standardauthentifizierung nicht für Internetsites empfohlen wird, wurde diese Authentifizierungsmethode gewählt, um vorzuführen, dass zusätzlicher Aufwand durch die Authentifizierung entsteht. Der Umfang des Aufwands hängt von Ihrem spezifischen Authentifizierungsmechanismus ab. Wenn Sie Ihre Bereitstellung testen, sollten Sie die Auswirkungen des Authentifizierungsmechanismus berücksichtigen. Weitere Informationen zu den von SharePoint Server 2010 unterstützten Authentifizierungsmechanismen finden Sie unter Planen von Authentifizierungsmethoden (SharePoint Server 2010).

Schlussfolgerungen und Empfehlungen für anonyme und authentifizierte Benutzer

Bei authentifizierten Benutzern sind die Anforderungen pro Sekunde (RPS) niedriger, und es besteht ein geringeres horizontales Skalierungspotenzial, da für die Überprüfung der Anmeldeinformationen zusätzliche Last für den Datenbankserver entsteht. Wie in den Testergebnissen gezeigt, ist die maximale RPS bei authentifizierten Benutzern signifikant niedriger als bei einer Farm mit anonymem Zugriff.

Skalierungseigenschaften von Lese- und Schreibvorgängen

Bei unseren Tests wurden die Schreibvorgänge pro Stunde aufgezeichnet. Im Rahmen dieses Artikels bezeichnet ein Schreibvorgang entweder das Erstellen und Einchecken einer neuen Veröffentlichungsseite oder das Bearbeiten und Einchecken einer vorhandenen Veröffentlichungsseite.

Für die folgenden Tests wurden dem System so lange Leser hinzugefügt, bis die CPU-Auslastung der Webserver ca. 80-90 Prozent erreichte. Dann wurden Schreibvorgänge in der Umgebung unter Anwendung einer künstlichen Verzögerung ausgeführt. Die Gesamtanzahl der Schreibvorgänge pro Stunde für den Test betrug ca. 500. Bei allen Tests wurde eine Ausgabecache-Trefferrate von 90 Prozent verwendet. Derselbe Test wurde für die Farmtopologien 1x1, 2x1 und 4x1 ausgeführt; zusätzlich zum Gesamtdurchsatz der Lesevorgänge für die einzelnen Konfigurationen wurde die CPU-Auslastung der Webserver und von SQL Server ermittelt. Darüber hinaus wurde eine anonyme schreibgeschützte Konfiguration als Baseline und eine Konfiguration mit authentifizierten Lesern unter Verwendung der Windows-Standardauthentifizierung getestet.

Obwohl die Webserver-CPU während der schreibgeschützten Skalierungstests bei 100 Prozent vollständig ausgelastet war, wurde die CPU-Auslastung der Webserver bei den Skalierungstests mit Schreibvorgängen bei 80-90 Prozent gehalten. Damit sollte bei der Ausführung von Schreibvorgängen eine zusätzliche CPU-Auslastung möglich sein.

Das folgende Diagramm zeigt die Gesamt-RPS für Lesevorgänge, die während der einzelnen Tests ermittelt wurde. Die RPS für Lesevorgänge skaliert linear, während zusätzliche Webserver hinzugefügt werden, selbst bei Schreibaktivität. Werden Schreibvorgänge hinzugefügt, sinkt der Wert von RPS jedoch.

Die CPU-Auslastung des Datenbankservers nahm bei steigender Anzahl von Webservern zu. Im folgenden Diagramm werden die Trends für die Zunahme der SQL Server-CPU-Auslastung in den verschiedenen Konfigurationen dargestellt. Wie im Abschnitt Anonyme und authentifizierte Benutzer weiter oben in diesem Artikel erwähnt, wirkt sich die Authentifizierung auf die CPU-Auslastung des Datenbankservers aus, was sich bei zusätzlicher Schreibaktivität noch verstärkt (was sich ebenfalls auf die CPU-Auslastung des Datenbankservers auswirkt).

Der extrapolierte Trend bei der SQL Server-Verwendung zeigt, dass SQL Server bei sechs Webservern mit authentifizierten Leseanforderungen zum Engpass wird. Bei den anonymen Lesevorgängen hingegen ist die vertikale Skalierung zu einer größeren Anzahl von Webservern machbar.

Es ist wichtig, darauf zu achten, dass sich zusätzliche Faktoren in einer Standardbereitstellung auf die Auslastung des Datenbankservers auswirken; diese Faktoren müssen bei der Kapazitätsplanung berücksichtigt werden. Wenn Sie mehr über die Bestimmung eines grünen Bereichs für die CPU-Standardauslastung von Datenbankservern erfahren möchten, lesen Sie die Informationen unter Kapazitätsverwaltung und Größengestaltung für SharePoint Server 2010 (Übersicht).

Schlussfolgerungen und Empfehlungen für Skalierungseigenschaften von Lese- und Schreibvorgängen

Unsere Daten zeigen, dass die vertikale Skalierung der Anzahl von Webservern eine effektive Strategie zur Steigerung des Durchsatzes ist, sofern der Datenbankserver nicht den Engpass darstellt. Im Durchschnitt führte die Testmischung aus anonymen Lesevorgängen und authentifizierten Schreibvorgängen zu einer Steigerung um 52 Prozent bei der Webserver-CPU-Auslastung verglichen mit einer Testmischung aus anonymen Lesevorgängen und keinen Schreibvorgängen. Darüber hinaus steigt die zusätzliche SQL Server- Auslastung bei authentifizierten Lesevorgängen stark an, da bei jeder Anforderung zusätzliche Authentifizierungsprüfungen ausgeführt werden, die einen Roundtrip zu SQL Server erfordern.

Im folgenden Diagramm sind die Auswirkungen des Durchsatzes auf die CPU-Auslastung des Datenbankservers dargestellt.

Einschränkungen im Zusammenhang mit dem Ausgabecache

Wenn das einzige Anliegen bei der Kapazitätsplanung die Maximierung der RPS wäre, könnte aus diesen Tests die Schlussfolgerung gezogen werden, dass die optimale Cachetrefferrate bei 100 Prozent liegt. Aufgrund von Anforderungen hinsichtlich der Datenaktualität oder von Speicherbeschränkungen ist es jedoch nicht möglich oder wünschenswert, die Zwischenspeicherung der Ausgabe einiger oder aller Seiten zu aktivieren.

Datenaktualität

Daten, die aus dem Ausgabecache stammen, enthalten möglicherweise keine kürzlich vorgenommenen Aktualisierungen des Originalinhalts. In der Quelle der Inhaltsbereitstellung oder (für authentifizierte Autoren) in einem direkten Dokumenterstellungsszenario sind Autoren daran interessiert, dass neueste Änderungen direkt nach dem Aktualisieren des vorhandenen Inhalts angezeigt werden.

Dies wird in der Regel durch Festlegen der Eigenschaft Dauer im Cacheprofil erreicht; diese Eigenschaft gibt an, wie lange eine zwischengespeicherte Seite im Ausgabecache vor dem Ablaufen aufbewahrt wird. Nach Ablauf der Seite wird sie aus dem Cache entfernt und eine nachfolgende Anforderung führt zu einem Cachefehler, durch den der Seiteninhalt aktualisiert wird.

Die Eigenschaft Auf Änderungen überprüfen im Cacheprofil kann ebenfalls festgelegt werden; dabei vergleicht der Server den Zeitpunkt der Zwischenspeicherung einer Seite mit dem Zeitpunkt der letzten Änderung in einer Websitesammlung. Die Anforderung einer Seite mit nicht übereinstimmenden Zeitstempeln hat die Cacheinvalidierung aller Seiten in der Websitesammlung zur Folge. Da sich die Eigenschaft Auf Änderungen überprüfen auf alle Seiten in einer Websitesammlung auswirkt, wird empfohlen, diese Option nur bei einer direkten Dokumenterstellungslösung zu aktivieren, die selten aktualisiert und im Grunde genommen statisch ist. Die Kombination dieser Option mit einer langen Dauer bietet die Möglichkeit, dass alle Seiten aus dem Cache bereitgestellt werden, bis eine Aktualisierung an der Website vorgenommen wird.

Die Eigenschaft Auf Änderungen überprüfen ist standardmäßig nicht aktiviert. Das bedeutet, dass der Webserver Daten aus dem Ausgabecache als Antwort auf Anforderungen nach einer noch nicht abgelaufenen Seite bereitstellt, unabhängig davon, ob die zugrunde liegende ASPX-Originalseite geändert wurde oder nicht.

In diesem in einer Serverfarm mit 1x1-Topologie ausgeführten Test stimmen alle Variablen mit den Variablen der Tests im Abschnitt Skalierungseigenschaften von Lese- und Schreibvorgängen überein, mit Ausnahme der Eigenschaft Auf Änderungen überprüfen. Wenn die Eigenschaft Auf Änderungen überprüfen aktiviert ist, wird der Cache häufiger geleert, was zu einer niedrigeren Ausgabecache-Trefferrate führt.

Im folgenden Diagramm sind die Auswirkungen der Eigenschaft Auf Änderungen überprüfen auf den Durchsatz dargestellt.

Die Verwendung der Eigenschaft Auf Änderungen überprüfen im Ausgabecacheprofil wird, abgesehen von Sonderfällen, nicht empfohlen. Eine Website, in der das Modell der direkten Dokumenterstellung verwendet wird und nur selten inhaltliche Änderungen vorgenommen werden, kann für authentifizierte Benutzer zusammen mit einer langen Cachedauer möglicherweise von dieser Einstellung profitieren; bei anderen Arten von Websites ist vermutlich jedoch eine Verschlechterung der RPS feststellbar.

Abhängig von Ihren Anforderungen ist es sinnvoll, dass Inhalte, bei denen die Aktualität eine wichtige Rolle spielt, sofort oder zumindest schneller als dies die Standardeinstellungen unterstützen, angezeigt werden. In diesem Fall sollten Sie die Dauer reduzieren oder das Zwischenspeichern von Ausgaben nicht aktivieren.

Schlussfolgerungen und Empfehlungen im Hinblick auf die Einschränkungen des Ausgabecaches

Durch das Zwischenspeichern von Ausgaben werden nicht alle Probleme im Zusammenhang mit der Kapazitätsverwaltung gelöst. In einigen Situationen ist die Zwischenspeicherung von Ausgaben nicht sinnvoll, was Sie beim Aktivieren des Ausgabecaches und dem Konfigurieren der Ausgabecacheprofile bedenken sollten.

Auswirkungen des Volumens von Lesevorgängen auf die CPU und die Antwortzeit

Dieser Test wurde auf einer 1x1-Farm mit anonymem Zugriff und aktiviertem Ausgabecache durchgeführt.

Im folgenden Diagramm sind die Auswirkungen des Volumens von Lesevorgängen auf die CPU und die Antwortzeit dargestellt.

Schlussfolgerungen und Empfehlungen im Hinblick auf die Auswirkungen des Volumens von Lesevorgängen auf die CPU und die Antwortzeit

Wie im Abschnitt Engpässe und Abhilfe erläutert, bleibt die Serverantwortzeit im Allgemeinen konstant bis der Webserver ausreichend Anforderungsvolumen empfangen hat, sodass die CPU vollständig ausgelastet ist. Bei vollständiger Auslastung der Webserver-CPU steigt die Antwortzeit signifikant. Die Serverfarm ist jedoch weiterhin in der Lage, zusätzliches Anforderungsvolumen zu bearbeiten.

Auswirkungen von Schreibvorgängen auf den Durchsatz

Das Verhältnis zwischen Erstellungs- und Bearbeitungsvorgängen ist über die Dauer der Tests gleichmäßig verteilt. Die Werte für Schreibvorgänge pro Stunde wurden bis ca. 500 getestet, da das Erstellen oder Bearbeiten von mehr als 500 Seiten pro Stunde außerhalb des Bereichs liegt, in dem sich die meisten SharePoint-Bereitstellungen bewegen. Bei diesem Test wurden keine automatisierten Prozesse erfasst, wie die Inhaltsbereitstellung, die im Abschnitt Auswirkungen der Inhaltsbereitstellung besprochen ist. Diese Erstellungs- und Bearbeitungsvorgänge können zu mehreren SQL Server-Vorgängen führen. Deshalb ist es wichtig, zu wissen, dass die in diesen Tests gemessenen Schreibvorgänge sich nicht auf der SQL Server-Ebene befinden, sondern dem entsprechen, was von einem Benutzer als Schreibvorgang betrachtet wird. Alle Tests von RPS verglichen mit Schreibvorgängen pro Stunde wurden in einer 1x1-Farm durchgeführt.

Zunächst wurden dem Test so lange Lesevorgänge hinzugefügt, bis die Webserver-CPU einen Wert zwischen 60 und 80 Prozent erreichte, um Puffer für Belastungsspitzen zu lassen. Diese durchschnittliche Auslastung wurde im Verlauf des Tests beibehalten. Dann wurden Schreibvorgänge unter Anwendung einer künstlichen Verzögerung zur Steuerung der Anzahl der Schreibvorgänge hinzugefügt. Während der Schreibvorgänge traten jedoch Spitzen bei der Auslastung der Webserver- und SQL Server-CPU auf. Einige dieser Spitzen überschritten bei einigen Cachetrefferraten den Schwellenwert für Normalbetrieb, wie im folgenden Diagramm dargestellt, obwohl der Durchschnitt innerhalb der Spanne für Normalbetrieb lag.

Wie im vorhergehenden Diagramm zu sehen, ist eine geringe Reduzierung des Durchsatzes feststellbar, wenn der Umgebung Schreibvorgänge hinzugefügt werden. Im Diagramm wird die Änderung des Durchsatzes zwischen einem schreibgeschützten Szenario und Lesevorgängen im Verlauf von ca. 500 Schreibvorgängen pro Stunde veranschaulicht. Für jede Ausgabecache-Trefferrate wurden zwei Datenpunkte aufgezeichnet. Deshalb ist das Verhältnis zwischen Datenpunkten nicht unbedingt linear.

Die Reduzierung des Prozentwertes fällt bei niedrigeren Cachetrefferraten deutlicher aus, wie im folgenden Diagramm zu sehen. Die Gesamt-RPS für Lesevorgänge bleibt, unabhängig von den Schreibvorgängen, weitgehend abhängig von der Ausgabecache-Trefferrate.

Im folgenden Diagramm wird gezeigt, dass die Datenbankserver-CPU-Auslastung bei Hinzufügen von Schreibvorgängen zum System nicht merklich anstieg. Beachten Sie, dass die vertikale Skalierung zwischen 0 und 10 Prozent der CPU-Auslastung liegt.

Während der Schreibvorgänge wurde erwartungsgemäß eine zusätzliche SQL Server-Auslastung festgestellt. Die höchste Steigerung lag jedoch bei 2,06 Prozent, was nicht signifikant ist. Die durchschnittliche Datenbankserver-CPU-Auslastung blieb im Verlauf aller Tests unter 10 Prozent. Dieser Test wurde in einer 1x1-Farm durchgeführt. Die Datenbankserver-CPU-Auslastung steigt, wenn die Anzahl der Webserver horizontal skaliert wird. Weitere Informationen hierzu finden Sie unter Skalierungseigenschaften von Lese- und Schreibvorgängen.

Während der Tests wurde auch die Webserver-CPU-Auslastung gemessen. Im folgenden Diagramm wird deutlich, dass die durchschnittliche Webserver-CPU-Auslastung im Bereich von 60-80 Prozent während der Tests blieb, selbst als die Anzahl der Schreibvorgänge pro Stunde 500 erreichte.

Die gemessene CPU-Auslastung erreicht jedoch Spitzenwerte während der Schreibvorgänge, wie im folgenden Diagramm zu sehen. Im Allgemeinen stellen diese CPU-Spitzen kein Problem dar. Zweck des grünen Bereichs ist es, CPU-Reserven freizuhalten, um Spitzen bei der CPU-Auslastung abfangen zu können. Wenn zusätzliche Webserver hinzugefügt werden, werden darüber hinaus die Spitzen zwischen diesen Servern verteilt, sodass die Auswirkungen auf die CPU eines einzelnen Webservers geringer ausfallen. Sie sollten jedoch wissen, dass solche Spitzen in tatsächlichen Bereitstellungen zu erwarten sind; die Aktivität von Schreibvorgängen ist nicht gleichmäßig verteilt, da sie im Allgemeinen in Bursts auftritt.

Eine Cachetrefferrate von 90 Prozent ist bei einer Standardbereitstellung sehr niedrig. Die meisten SharePoint Server 2010-Bereitstellungen mit zahlreichen Lesevorgängen weisen eine Ausgabecache-Trefferrate von 95 Prozent oder höher auf.

Schlussfolgerungen und Empfehlungen im Hinblick auf die Auswirkungen von Schreibvorgängen auf den Durchsatz

Die präsentierten Daten zeigen, dass Schreibvorgänge keine umfassenden negativen Auswirkungen auf den Gesamtdurchsatz des Systems für Leser haben. Sie sollten sich bewusst sein, dass die Aktivität von Schreibvorgängen zu Spitzen bei der CPU-Auslastung führen kann und Ihre Standardkonfiguration unter Berücksichtigung dieser Spitzen planen. Die richtige Strategie zum Ausgleichen dieser Spitzen besteht darin, auf mehrere Webserver zu skalieren. Dies bringt zwei Vorteile mit sich:

• Verteilung der Last durch Schreibvorgänge auf mehrere Webserver, wodurch die Spitzen im Allgemeinen abgeschwächt werden.

• Gesteigerte RPS für Lesevorgänge, vor allem bei hohen Ausgabecache-Trefferraten.

Auswirkungen der Inhaltsbereitstellung

Eine Alternative zum Modell der direkten Dokumenterstellung, bei der eine einzelne Umgebung für das Bearbeiten und Lesen verwendet wird, besteht darin, die Umgebung in zwei getrennte Umgebungen zu unterteilen - eine Umgebung für die Dokumenterstellung und eine Umgebung für die Produktion. Mithilfe der Inhaltsbereitstellung wird dann der Inhalt aus der Dokumenterstellungsumgebung in die Produktionsumgebung kopiert.

In dieser Konfiguration variiert die Produktionsumgebung von geringer Schreibaktivität bis hin zu keiner Schreibaktivität, außer beim Importieren von Inhalt durch die Inhaltsbereitstellung. Bei diesen Tests wurden so lange Lesevorgänge hinzugefügt, bis die Webserver-CPU-Auslastung den Bereich von 70-80 Prozent erreichte. Durch den Inhaltsbereitstellungsauftrag wurden dann 10 Websites mit jeweils 500 Seiten als Paket aus der Dokumenterstellungs-Websitesammlung exportiert und das Paket dann in die Veröffentlichungssitesammlung importiert. Die Größe des bereitgestellten Pakets ist größer als Pakete in tatsächlichen Umgebungen, um die Dauer des Inhaltsbereitstellungsauftrags so lange zu verlängern, bis Testergebnisse vorliegen. Zusätzliche Informationen zu den Eigenschaften des bereitgestellten Inhalts finden Sie im Abschnitt Dataset.

Nach Abschluss des Exports wird der Inhalt in eine gesonderte Websitesammlung importiert und die Auslastung von Anwendungsserver und SQL Server während des Imports zusätzlich zum Durchsatz gemessen. Der Importtest wurde für mehrere unterschiedliche Ausgabecache-Trefferraten durchgeführt.

Als Wichtigstes konnte festgestellt werden, dass der Import nur eine geringfügige Auswirkung auf die Gesamt-RPS für Lesevorgänge hat, wie im folgenden Diagramm dargestellt. Darüber hinaus wurde deutlich, dass der Import unabhängig von der Cachetrefferrate keine signifikante Auswirkung auf die Webserver-CPU-Auslastung hat, wie in den folgenden Tabellen zu sehen. Eine deutlichere Auswirkung ergab sich hingegen für die SQL Server-CPU, wie im folgenden Diagramm dargestellt. Dies war zu erwarten, da der Datenbankserver einer höheren Auslastung unterliegt, wenn Inhalt importiert wird. Die Auslastung der SQL Server-CPU blieb jedoch bei allen getesteten Cachetrefferraten selbst während des Imports unter 12 Prozent.

In den folgenden Tabellen werden die Auswirkungen des Imports bei der Inhaltsbereitstellung auf die CPU-Auslastung von Webserver und Datenbankserver dargestellt.

Auswirkungen des Imports bei der Inhaltsbereitstellung auf die Webserver-CPU-Auslastung

Cachetreffer	100%	99%	98%	95%	90%	50%	0%
Baseline	72,32%	73,26%	71,28%	73,53%	71,79%	68,05%	63,97%
Mit Import	70,93%	74,45%	69,56%	74,12%	70,95%	67,93%	63,94%

Auswirkungen des Imports bei der Inhaltsbereitstellung auf die Datenbankserver-CPU-Auslastung

Cachetreffer	100%	99%	98%	95%	90%	50%	0%
Baseline	1,19%	1,64%	2,01%	3,00%	3,73%	5,40%	6,82%
Mit Import	6,03%	6,82%	6,97%	7,96%	8,52%	10,29%	10,56%

Schlussfolgerungen und Empfehlungen im Hinblick auf die Auswirkungen der Inhaltsbereitstellung

Die Ergebnisse der Tests zeigen, dass die Durchführung von Inhaltsbereitstellungsvorgängen während regulärer Websitevorgänge keine signifikanten Leistungsminderungen mit sich bringt. Diese Ergebnisse verdeutlichen, dass es nicht unbedingt erforderlich ist, Inhalt zu Zeiten mit geringem Datenverkehr bereitzustellen, um die Auswirkungen des Vorgangs auf die Gesamtleistung zu minimieren. Die Bereitstellungszeiten können also in erster Linie abhängig von Geschäftsanforderungen und nicht von Leistungsanforderungen gewählt werden.

Auswirkungen von Datenbankmomentaufnahmen während des Exports bei der Inhaltsbereitstellung

In SharePoint Server 2010 kann die Inhaltsbereitstellung so konfiguriert werden, dass vor dem Exportieren des Inhalts aus der Quellinhaltsdatenbank eine Momentaufnahme der Datenbank erstellt wird. Dadurch wird der Exportvorgang vor Dokumenterstellungsaktivitäten geschützt, die während des Exports stattfinden. Momentaufnahmen können sich jedoch auf die Schreibleistung des Datenbankservers auswirken, da die Momentaufnahme als Multiplikator für die Schreibvorgänge fungiert. Wenn beispielsweise zwei Momentaufnahmen einer Quelldatenbank vorliegen und Sie dann in die Quelldatenbank schreiben, werden die bestehenden Daten vom Datenbankserver in jede Momentaufnahme kopiert und die neuen Daten dann in die Quelldatenbank geschrieben. Das bedeutet, dass ein einzelner Schreibvorgang in der Quelldatenbank drei eigentliche Schreibvorgänge mit sich bringt: einen in die Quelldatenbank und jeweils einen für jede Datenbankmomentaufnahme.

Um die Auswirkungen einer Momentaufnahme auf die Erstellungsumgebung zu ermitteln, wurde die RPS für Schreibvorgänge, die Antwortzeit und die CPU-Auslastung der Webserver, Datenbankserver und Anwendungsserver während eines Exportvorgangs gemessen, während dem auch Schreibaktivitäten stattfanden. Die folgenden Tabellen enthalten die Ergebnisse.

Auswirkungen von Datenbankmomentaufnahmen während der Inhaltsbereitstellung

Metrik	4 WPH - Keine Momentaufnahmen	4 WPH - Mit Momentaufnahmen
RPS für Schreibvorgänge	0,2	0,16
Antwortzeit	0,13	0,15
Webserver-CPU (%)	0,42%	0,27%
Anwendungsserver-CPU (%)	8,67%	8,98%
Datenbankserver-CPU (%)	3,34%	2,41%

Auswirkungen von Datenbankmomentaufnahmen während der Inhaltsbereitstellung

Metrik	8 WPH - Keine Momentaufnahmen	8 WPH - Mit Momentaufnahmen
RPS für Schreibvorgänge	0,44	0,44
Antwortzeit	0,13	0,13
Webserver-CPU (%)	0,61%	0,73%
Anwendungsserver-CPU (%)	14,6%	12%
Datenbankserver-CPU (%)	7,04%	7,86%

Schlussfolgerungen und Empfehlungen im Hinblick auf Datenbankmomentaufnahmen während des Exports bei der Inhaltsbereitstellung

Die Ergebnisse der Tests zeigten keine signifikante Auswirkung auf die gemessenen Datenpunkte mit Datenbankmomentaufnahmen. Die gesamte verzeichnete Abweichung lag innerhalb der Fehlermarge. Damit wird bestätigt, dass Datenbankmomentaufnahmen ohne große Bedenken hinsichtlich der Leistung verwendet werden können.

Eigenschaften von Inhalten

Die Tests wurden unter Verwendung eines einzelnen Datasets ausgeführt, das zur Beantwortung einer bestimmten Reihe von Fragen erstellt wurde. Ihr Dataset weicht davon ab und verändert sich im Laufe der Zeit. In diesem Abschnitt wird untersucht, wie Eigenschaften von Inhalten, wie die Anzahl der Seiten in der Seitenbibliothek und die in den Seiten enthaltenen Features, sich auf Entscheidungen zur Kapazitätsverwaltung auswirken können.

Seitenanzahl

Die maximale RPS wurde für Seitenbibliotheken unterschiedlicher Größe getestet. Dieser Test wurde in einer 4x1-Topologie bei deaktiviertem Ausgabecache und mit anonymem Zugriff ausgeführt. Die Größe aller Seiten lag unkomprimiert bei 42 KB, komprimiert bei 12 KB. Die Testergebnisse sind in der folgenden Tabelle enthalten.

Auswirkungen der Anzahl der Bibliotheksseiten auf RPS

Seitenanzahl	3	1.000	20.000
Maximale RPS	860	801	790

Die Erhöhung der Seitenanzahl auf 20.000 hatte keine signifikanten Auswirkungen auf die maximale RPS.

Mehrwertige Nachschlagefelder

Ein mehrwertiges Nachschlagefeld ist eine Spalte in einer Liste, die auf mindestens ein Element in einer anderen Liste verweist, wie z. B. Spalten mit verwalteten Unternehmensmetadaten. Diese Felder werden im Allgemeinen als Stichwörter der Suche für eine Seite verwendet und werden nicht unbedingt gerendert. In manchen Fällen, wie beispielsweise bei Unternehmenswikis, ist es sinnvoll, dass diese Feldwerte im Seiteninhalt gerendert werden. So werden beispielsweise Seiten beim Erstellen möglicherweise nach Kategorien unterteilt (z. B. Aus aller Welt, Wissen und Sport auf einer Nachrichtenseite), und die Gestaltungsvorlage enthält einen Platzhalter, über den dem Benutzer angezeigt wird, in welche Kategorien die Seite eingeteilt wird.

Bei mehrwertigen Nachschlagefeldern werden beim Anfordern einer Seite mehr Daten abgerufen. Deshalb kann sich die Verwendung zahlreicher mehrwertiger Nachschlagefelder auf einer Seite auf die Leistung auswirken.

Im folgenden Diagramm sind die Auswirkungen mehrwertiger Nachschlagefelder auf den Durchsatz dargestellt.

Im folgenden Diagramm sind die Auswirkungen mehrwertiger Nachschlagefelder auf die Verwendung von Farmressourcen dargestellt.

Bei zunehmender Anzahl der mehrwertigen Nachschlagefeldern kommt es zu einer Beeinträchtigung der maximalen RPS, da sich der Anstieg auf das Netzwerk zwischen Webserver und Datenbankserver auswirkt.

Auswirkungen der Verwendungsberichterstellung

Die Verwendungsberichterstellung ist ein Dienst, der Administratoren bei der Überwachung von Statistiken über die Verwendung ihrer Websites hilft. Weitere Informationen zur Verwendungsberichterstellung finden Sie unter Konfigurieren der Erfassung von Verwendungs- und Integritätsdaten (SharePoint Server 2010).

Die Auswirkungen von Zeitgeberaufträgen für die Verwendungsberichterstellung auf die maximale RPS wurde in einer 1x1-Farm getestet. In der folgenden Tabelle sind die Ergebnisse beschrieben.

Auswirkungen der Verwendungsprotokollierung auf die Leistung (in RPS)

	Verwendungsdatenbank ein	Verwendungsdatenbank aus	Differenz
Ausgabecache ein	3.459	3.463	4
Ausgabecache aus	629	638	9

Die Ergebnisse zeigen, dass die Aktivierung der Verwendungsprotokollierung in einem schreibgeschützten Szenario keine signifikanten Auswirkungen auf RPS hat.

Informationen zu den Autoren

Joshua Stickler ist Program Manager für SharePoint Server 2010 bei Microsoft.

Joshua Stickler ist Program Manager für SharePoint Server 2010 bei Microsoft.

Zhi Liu ist Software Development Engineer in Test für SharePoint Server 2010 bei Microsoft.

Cheuk Dong ist Software Development Engineer in Test für SharePoint Server 2010 bei Microsoft.

Philippe Flamm ist Software Development Engineer in Test für SharePoint Server 2010 bei Microsoft.