Schätzen der Leistungs- und Kapazitätsanforderungen für die SharePoint Server 2010-Suche

 

Gilt für: SharePoint Server 2010

Letztes Änderungsdatum des Themas: 2016-11-30

Zusammenfassung: Dieser Artikel enthält Kapazitätsplanungsinformationen für unterschiedliche Bereitstellungen der Microsoft SharePoint Server 2010-Suche, einschließlich kleiner, mittlerer und großer SharePoint Server 2010-Farmen.

Dieser Artikel enthält Kapazitätsplanungsinformationen für Bereitstellungen in Umgebungen zur Zusammenarbeit der SharePoint Server 2010-Suche. Darin enthalten sind die folgenden Informationen für drei Beispiel-Suchfarmkonfigurationen:

• Spezifikationen für Testumgebungen, z. B. Hardware, Farmtopologie und Konfiguration.

• Arbeitslast, die für die Datengenerierung verwendet wird, z. B. Anzahl und Klasse der Benutzer sowie Farmnutzungsmuster.

• Testfarm-Dataset, einschließlich Datenbankinhalten und Größen

• Für die getestete Umgebung spezifische Integritäts- und Leistungsdaten

Dieser Artikel enthält auch allgemeine Testdaten und Empfehlungen für die Bestimmung der Hardware, Topologie und Konfiguration für die Bereitstellung einer vergleichbaren Umgebung sowie für die Optimierung der Umgebung für entsprechende Kapazitäts- und Leistungseigenschaften.

Die SharePoint Server 2010-Suche verfügt über mehr Features und ein flexibleres Topologiemodell als frühere Versionen. Bevor Sie Ihren Benutzern mit dieser Architektur leistungsfähigere Features und Funktionen bereitstellen, müssen Sie die Auswirkungen auf die Kapazität und Leistung der Farm sorgfältig überprüfen.

Nach der Lektüre dieses Dokuments sind Sie in der Lage, folgende Aufgaben auszuführen:

• Definieren von Leistungs- und Kapazitätszielen für die Umgebung.

• Planen der Hardware, die zur Unterstützung der Anzahl von Benutzern und den Benutzertyp sowie der Features, die bereitgestellt werden sollen, erforderlich ist.

• Entwerfen der physikalischen und logischen Topologie, um eine optimale Zuverlässigkeit und Effizienz sicherzustellen.

• Testen, Überprüfen und Skalieren der Umgebung, um Leistungs- und Kapazitätsziele zu erreichen.

• Überwachen der Umgebung auf Schlüsselindikatoren.

Vor der Lektüre dieses Artikels sollten Sie mit Folgendem vertraut sein:

• Capacity management and sizing for SharePoint Server 2010

• SharePoint Server 2010-Kapazitätsverwaltung: Softwarebeschränkungen und -grenzen

• Verfügbarkeit

• Redundanz

• Datenbankspezifischer Inhalt

Planung (Übersicht)

In den Szenarien in diesem Artikel werden kleine, mittlere und große Testfarmen beschrieben unter Verwendung von Annahmen, die Ihnen bei der Planung der richtigen Kapazität für die Farm behilflich sein können. Diese Farmgrößen sind Annäherungen, die auf den folgenden Annahmen basieren:

• Die durchforsteten Repositorys weisen in erster Linie SharePoint Server-Inhalte auf.

• Der wesentliche Anteil der Benutzerabfragen befindet sich in den gleichen 33 Prozent des Index. Das bedeutet, dass die meisten Benutzer dieselben Begriffe abfragen.

• Es werden die Standard-Metadateneinstellungen verwendet, wodurch sichergestellt wird, dass die Eigenschaftendatenbank nicht rasch an Größe gewinnt.

• In mittleren und großen Farmen sind dedizierte Durchforstungsziele (Front-End-Webserver) vorhanden, die den Durchforstungskomponenten dieser Suchfarmen Inhalte bereitstellen können.

• In diesen Farmen durchgeführte Messungen können aufgrund von Netzwerk- und Umgebungsbedingungen schwanken und weisen eine Fehlermarge von bis zu 10 Prozent auf.

Auswählen eines Szenarios

Bei der Auswahl des richtigen Szenarios hilft Ihnen die Beantwortung der folgenden Fragen:

• Korpusgröße   Wie viel Inhalt muss durchsucht werden können? Die Gesamtzahl der Elemente sollte alle Objekte umfassen, einschließlich Dokumenten, Webseiten, Listenelementen und Personen.

• Verfügbarkeit   Welche Anforderungen bestehen hinsichtlich der Verfügbarkeit? Benötigen Kunden eine Suchlösung, die den Ausfall eines bestimmten Servers überstehen kann?

• Aktualität des Inhalts   Wie aktuell sollen die Suchergebnisse sein? Wie lange soll nach dem Aktualisieren des Inhalts durch einen Benutzer der aktualisierte Inhalt in den Ergebnissen bei der Suche bereitgestellt werden? Wie häufig wird der Inhalt erwartungsgemäß geändert?

• Durchsatz   Wie viele Personen werden den Inhalt gleichzeitig durchsuchen? Dies schließt Benutzer ein, die in ein Abfragefeld eingeben, verdeckte Abfragen, wie Webparts, die automatisch nach Daten suchen, oder die Anwendung Microsoft Outlook 2010 Connector für soziale Netzwerke, die Aktivitätsfeeds mit URLs anfordert, die Sicherheitskürzungen von Suchsystem benötigen.

Wählen Sie eines der folgenden Szenarien anhand der Antworten zu diesen Fragen aus:

• Kleine Farm   Schließt eine kleine Suchdienstanwendung ein, die einige Ressourcen einer einzelnen SharePoint Server-Farm gemeinsam nutzt. In der Regel ist die Inhaltsmenge, die durchsucht werden soll, bei kleinen Bereitstellungen eingeschränkt (weniger als 10 Mio. Elemente). Abhängig von den gewünschten Aktualitätsvorgaben können inkrementelle Durchforstungen während den Geschäftszeiten stattfinden.

• Mittlere Farm   Schließt eine oder mehrere Suchdienstanwendungen in einer dedizierten Farm ein, die anderen Farmen Suchdienste bereitstellen. Die Inhaltsmenge, für die Suchfunktionen bereitgestellt werden sollen, ist beschränkt (bis zu 40 Mio. Elemente). Um die Aktualitätsvorgaben einzuhalten, werden inkrementelle Durchforstungen voraussichtlich während den Geschäftszeiten ausgeführt.

• Große Farm   Schließt eine oder mehrere Suchdienstanwendungen in einer dedizierten Farm ein, die anderen Farmen Suchdienste bereitstellen. Die Inhaltsmenge, für die Suchfunktionen bereitgestellt werden sollen, ist umfangreich (bis zu 100 Mio. Elemente). Um die Aktualitätsvorgaben einzuhalten, werden inkrementelle Durchforstungen voraussichtlich während den Geschäftszeiten ausgeführt.

Lebenszyklus der Suche

Anhand dieser drei Szenarien können Sie die Kapazität der Farm bereits zu einem frühen Zeitpunkt abschätzen. Farmen durchlaufen beim Durchforsten des Inhalts die folgenden Phasen des Lebenszyklus der Suche:

• Indexerfassung   Dies ist die erste Phase der Datenauffüllung. Die Dauer dieser Phase hängt von der Größe der Inhaltsquellen ab. Diese Phase ist durch folgende Merkmale gekennzeichnet:

  • Vollständige Durchforstungen (eventuell gleichzeitig) von Inhalten.

  • Enge Überwachung des Durchforstungssystems, um sicherzustellen, dass die durchforsteten Hosts keinen Engpass bei der Durchforstung darstellen.

  • Häufige Hauptzusammenführungen, die für jede Abfragekomponente dann ausgelöst werden, wenn sich eine bestimmte Menge des Index geändert hat.

• Indexverwaltung   Dies ist die gebräuchlichste Phase einer Farm. Diese Phase ist durch folgende Merkmale gekennzeichnet:

  • Es werden inkrementelle Durchforstungen des gesamten Inhalts durchgeführt.

  • Bei Durchforstungen des SharePoint Server-Inhalts bestehen die meisten Änderungen während der Durchforstung aus Sicherheitsänderungen.

  • Seltene Hauptzusammenführungen, die für jede Abfragekomponente dann ausgelöst werden, wenn sich eine bestimmte Menge des Index geändert hat.

• Indexbereinigung   Diese Phase beginnt, wenn die Phase der Indexverwaltung aufgrund einer Inhaltsänderung beendet wird, z. B. wenn eine Inhaltsdatenbank oder Website aus einer Suchdienstanwendung in eine andere verschoben wird. Diese Phase wird ausgelöst, wenn einer der folgenden Vorgänge stattfindet:

  • Ein Host, der Inhalte bereitstellt, wird über einen längeren Zeitraum hinweg vom Suchcrawler nicht gefunden.

  • Eine Inhaltsquelle oder Startadresse wird aus einer Suchdienstanwendung gelöscht.

Szenarien

In diesem Abschnitt werden die Konfigurationen für die Szenarien mit kleinen, mittleren und großen Farmen beschrieben. Darüber hinaus enthält dieser Abschnitt die Arbeitslasten, Datasets sowie Leistungs- und Testdaten für die einzelnen Umgebungen.

Kleine Farm

Da die Farm klein ist, müssen von einigen Servern mehrere Rollen übernommen werden. Es wird empfohlen, eine Abfragekomponente mit einem Front-End-Webserver zu kombinieren, da so die Unterbringung von Durchforstungs- und Abfragekomponenten auf demselben Server vermieden wird. In dieser Konfiguration werden drei Anwendungsserver und ein Datenbankserver wie folgt verwendet:

• Da für die Suche in Unternehmen im Allgemeinen redundante Abfrageserver vorgeschlagen werden, wurden zwei Anwendungsserver für Abfragekomponenten bei folgender Konfiguration verwendet:

  • Ein Anwendungsserver dient zugleich als Host für das Suchcenter. Diese Konfiguration kann weggelassen werden, wenn die kleine Farm als Dienstfarm verwendet wird und die Suchcenter in untergeordneten Inhaltsfarmen erstellt werden, die die Suchdienstanwendung der übergeordneten Dienstfarm verwenden.

  • Die bevorzugte Abfragekonfiguration bei weniger als 10 Mio. Elementen besteht in der Verwendung einer einzelnen Indexpartition. Jeder Server verfügt dann über eine primäre Abfragekomponente von der Indexpartition. Dieses Setup mit Aktiv/Aktiv-Abfragekomponenten lässt den Ausfall einer der Abfragekomponenten zu, während die Fähigkeit, Abfragen zu bedienen, über die verbleibende Abfragekomponente aufrecht erhalten wird. Beim Ausfall einer Abfragekomponente sendet die Suche Abfragen (Round-Robin) an die nächste verfügbare Abfragekomponente.

• Ein Anwendungsserver wird für das Durchforsten und die Verwaltung verwendet. Somit werden die Zentraladministration, die Komponente der Suchverwaltung und die Durchforstungskomponente auf diesem Server erstellt.

• Ein einzelner Datenbankserver zur Unterstützung der Farm. Der Datenbankserver sollte über eine dedizierte Anzahl von Ein-/Ausgabevorgängen pro Sekunde (IOPS) für Durchforstungs-, Eigenschaften- und Verwaltungsdatenbanken verfügen (verwenden Sie z. B. verschiedene Speicherarrays).

Spezifikationen

Dieser Abschnitt enthält ausführliche Informationen zur Hardware, Software, Topologie und Konfiguration der Testumgebung.

Topologie

Hardware

Webserver

Webserver	Front-End-Webserver/Abfrage (1)
Prozessor	1px4c@3 GHz
RAM	16 GB
Betriebssystem	Windows Server 2008 R2, 64-Bit-Version
Speicherkapazität	2 x 450 GB 15K SAS: RAID1: OS 2 x 450 GB 15K SAS: RAID1: DATA1 2 x 450 GB 15K SAS: RAID1: DATA2
Anzahl der Netzwerkschnittstellenkarten (NICs)	2
NIC-Geschwindigkeit	1 Gigabit
Authentifizierung	NTLM
Lastenausgleichstyp	n/v
Softwareversion	SharePoint Server 2010 (Vorabversion)
Lokal ausgeführte Dienste	Alle Dienste (einschließlich Suchabfrage und Websiteeinstellungsdienst)

Anwendungsserver

Server	Abfrage (1)	Durchforstung/Verwaltung (1)
Prozessor	1px4c @ 3 GHz	1px4c @ 3 GHz
RAM	16 GB	16 GB
Betriebssystem	Windows Server 2008 R2, 64-Bit-Version	Windows Server 2008 R2, 64-Bit-Version
Speicherkapazität	2 x 450 GB 15K SAS: RAID1: OS 2 x 450 GB 15K SAS: RAID1: DATA1 2 x 450 GB 15K SAS: RAID1: DATA2	2 x 450 GB 15K SAS: RAID1: OS 2 x 450 GB 15K SAS: RAID1: TEMP 2 x 450 GB 15K SAS: RAID0: DATA
Anzahl der Netzwerkschnittstellenkarten (NICs)	1	1
NIC-Geschwindigkeit	1 Gigabit	1 Gigabit
Authentifizierung	NTLM	NTLM
Lastenausgleichstyp	n/v	n/v
Softwareversion	SharePoint Server 2010 (Vorabversion)	SharePoint Server 2010 (Vorabversion)
Lokal ausgeführte Dienste	SharePoint Server-Suche, Suchabfrage und Websiteeinstellungsdienst	SharePoint Server-Suche

Datenbankserver

Datenbank	Gemeinsam genutzt (1)
Prozessor	2px4c @ 3 GHz
RAM	16 GB
Betriebssystem	Windows Server 2008 R2, 64-Bit-Version
Speicherkapazität	2 x 450 GB 15K SAS: RAID1: OS 2 x 450 GB 15K SAS: RAID0: DATA 2 x 450 GB 15K SAS: RAID0: LOGS Hinweis Aufgrund der reduzierten Anzahl von Treibern war die Anwendung der optimalen Methode, nämlich die Datenbanken auf verschiedenen E/A-Kanälen zu isolieren, nicht möglich.
Anzahl der Netzwerkschnittstellenkarten (NICs)	2
NIC-Geschwindigkeit	1 Gigabit
Authentifizierung	NTLM
Softwareversion	Microsoft SQL Server 2008 Enterprise

Arbeitsauslastung

In diesem Abschnitt werden die die Datengenerierung verwendeten Arbeitslasten beschrieben, einschließlich der Anzahl der Benutzer sowie der Farmnutzungsmuster.

Arbeitsauslastungsmerkmale	Wert
Allgemeine Beschreibung der Arbeitsauslastung	Suchfarmen
Abfragen pro Minute (Durchschnitt)	6
Anzahl gleichzeitiger Benutzer (Durchschnitt)	1
Gesamtanzahl der Abfragen pro Tag	8640

Dataset

In diesem Abschnitt wird das Testfarm-Dataset beschrieben, einschließlich Datenbankinhalten und Größen, Suchindizes und externen Datenquellen.

Objekt	Wert
Suchindexgröße (Anzahl der Elemente)	9 Mio.
Größe der Durchforstungsdatenbank	52 GB
Größe der Protokolldatei der Durchforstungsdatenbank	11 GB
Größe der Eigenschaftendatenbank	68 GB
Größe der Protokolldatei der Eigenschaftendatenbank	1 GB
Größe der Suchverwaltungsdatenbank	2 GB
Größe der aktiven Indexpartitionen	38,4 GB (76,8 GB gesamt, da der Index gespiegelt wird)
Gesamtanzahl der Suchdatenbanken	3
Sonstige Datenbanken	SharePoint_Config, SharePoint_AdminContent, State_Service, Bdc_Service_db, WSS_UsageApplication, WSS_Content

Integritäts- und Leistungsdaten

Dieser Abschnitt enthält Integritäts- und Leistungsdaten speziell für die Testumgebung.

Abfrageleistungsdaten

Die folgenden Messungen wurden bei einem Index mit 9 Mio. Elementen erstellt. Die Spalten enthalten die Messungen, die während des jeweiligen Tests durchgeführt wurden, während die Ergebnisse am Ende der folgenden Tabelle aufgeführt sind. Die Messungen setzen sich wie folgt zusammen:

• Abfragewartezeit   Diese Messungen wurden während eines Abfragewartezeittests durchgeführt, wobei mithilfe eines Testtools eine Reihe von Standardabfragen als ein Benutzer übermittelt und dann die sich ergebende Wartezeit gemessen wurde. Während des Tests fanden keine Durchforstungen statt.

• Abfragedurchsatz   Diese Messungen wurden während eines Abfragedurchsatztests durchgeführt, wobei mithilfe eines Testtools eine Reihe von Standardabfragen als steigende Anzahl gleichzeitiger Benutzer (bis zu 80) an die Farm übermittelt wurden. Während des Tests fanden keine Durchforstungen statt.

	Scorecardmetrik	Abfragewartezeit	Abfragedurchsatz
CPU-Metriken	SQL Server-CPU (Durchschnitt)	3,4%	12%
	Front-End-Webserver-CPU (Durchschnitt)	8%	51%
	Abfrageserver-CPU (Durchschnitt)	13,3%	95%
Zuverlässigkeit	Fehlerrate	0	0
	Front-End-Webserverabstürze	0	0
	Anwendungsserverabstürze	0	0
SQL Server	Cache-Trefferrate (SQL Server)	99,97%	100%
	SQL Server-Sperren: durchschnittl. Wartezeit (ms)	0,071	0,038
	SQL Server-Sperren: Sperrenwartezeit (ms)	0,035	0,019
	SQL Server-Sperren: Deadlocks/s	0	0
	SQL Server-Latches: durchschnittl. Wartezeit (ms)	31	0,017
	SQL Server-Kompilierungen/s	14,9	10,2
	SQL Server-Statistik: SQL Server-Neukompilierungen/s	0,087	0,05
	Durchschnittl. Länge der Datenträgerwarteschlange (SQL Server)	0,011	0,01
	Länge der Datenträgerwarteschlange: Schreibvorgänge (SQL Server)	0,01	0,008
	Lesevorgänge/s (SQL Server)	0,894	0,05
	Schreibvorgänge/s (SQL Server)	45	106
Anwendungsserver	Durchschnittl. Länge der Datenträgerwarteschlange (Abfrageserver)	0,013	0,001
	Länge der Datenträgerwarteschlange: Schreibvorgänge (Abfrageserver)	0	0,001
	Lesevorgänge/s (Abfrageserver)	11,75	0,06
	Schreibvorgänge/s (Abfrageserver)	4	5,714
	Durchschnittl. belegter Arbeitsspeicher (Abfrageserver)	8,73%	9%
	Maximal belegter Arbeitsspeicher (Abfrageserver)	8,75%	9%
Front-End-Webserver	ASP.NET-Anforderungen in Warteschlange (Durchschnitt aller Front-End-Webserver)	0	0
	Durchschnittl. belegter Arbeitsspeicher (Front-End-Webserver)	9,67%	95%
	Maximal belegter Arbeitsspeicher (Front-End-Webserver)	9,74%	100%
Testergebnisse	Anzahl der Erfolge	1757	13.608
	Anzahl der Fehler	0	0
	Abfragewartezeit (UI) (75. Perzentile)	0,331 s	3,68 s
	Abfragewartezeit (UI) (95. Perzentile)	0,424 s	3,93 s
	Abfragedurchsatz	3,29 Anforderungen/s	22,4 Anforderungen/s

Durchforstungsleistungsdaten

Die folgenden Messungen wurden bei sequenziellen, vollständigen Anfangsdurchforstungen der jeweiligen Inhaltsquelle erstellt. Die Größe der Inhaltsquelle ist in Millionen von Elementen angegeben. Die Spalten enthalten die Messungen, die während der jeweiligen Durchforstung durchgeführt wurden, während die Ergebnisse am Ende der Tabelle aufgeführt sind.

	Scorecardmetrik	SharePoint-Inhalt (4 Mio.)	Dateifreigabe (1 Mio.)	HTTP (Nicht-SharePoint) (1 Mio.)
CPU-Metriken	SQL Server-CPU (Durchschnitt)	5,4%	11,7%	23%
	Indexer-CPU (Durchschnitt)	41,6%	69%	71%
Zuverlässigkeit	Fehlerrate	0	0	0
	Front-End-Webserverabstürze	0	0	0
	Anwendungsserverabstürze	0	0	0
SQL Server	Cache-Trefferrate (SQL Server)	n/v	n/v	n/v
	SQL Server-Sperren: durchschnittl. Wartezeit (ms)	436	51,76	84,73
	SQL Server-Sperren: Sperrenwartezeit (ms)	n/v	n/v	n/v
	SQL Server-Sperren: Deadlocks/s	n/v	n/v	n/v
	SQL Server-Latches: durchschnittl. Wartezeit (ms)	1,05	1,64	3,53
	SQL Server-Kompilierungen/s	n/v	n/v	n/v
	SQL Server-Statistik: SQL Server-Neukompilierungen/s	n/v	n/v	n/v
	Durchschnittl. Länge der Datenträgerwarteschlange (SQL Server)	27,124	6,85	45
	Länge der Datenträgerwarteschlange: Schreibvorgänge (SQL Server)	17,6	6,7	21,57
Anwendungsserver	Durchschnittl. Länge der Datenträgerwarteschlange (Durchforstungsserver)	0,008	0,032	0,02
	Länge der Datenträgerwarteschlange: Schreibvorgänge (Durchforstungsserver)	0,006	0,025	0,012
	Durchschnittl. belegter Arbeitsspeicher (Durchforstungsserver)	14,16%	10,4%	11,5%
	Maximal belegter Arbeitsspeicher (Durchforstungsserver)	19,2%	11,13%	12,78%
Front-End-Webserver	ASP.NET-Anforderungen in Warteschlange (Durchschnitt aller Front-End-Webserver)	0	0	0
	Durchschnittl. belegter Arbeitsspeicher (Front-End-Webserver)	n/v	n/v	n/v
	Maximal belegter Arbeitsspeicher (Front-End-Webserver)	n/v	n/v	n/v
Testergebnisse	Anzahl der Erfolge	3.934.881	1.247.838	996.982
	Anzahl der Fehler	9645	302	2
	Portaldurchforstungsgeschwindigkeit (Elemente/s)	46,32	120,436	138,316
	Ankerdurchforstungsgeschwindigkeit (Elemente/s)	5197	3466,219	2192,982
	Gesamte Durchforstungsgeschwindigkeit (Elemente/s)	45,91	116,392	130,086

Testdaten

Dieser Abschnitt enthält Testdaten, die die Leistung der Farm veranschaulichen. Nachfolgend in diesem Artikel im Abschnitt Optimierungen erhalten Sie Informationen zur Leistungssteigerung.

Abfragewartezeit

Das folgende Diagramm zeigt die Abfragewartezeitperzentilen für diese Farm bei steigender Benutzerlast (erfasst während des Abfragedurchsatztests). Eine Abfrageperzentile von 95 Prozent bedeutet, dass 95 Prozent der gemessenen Abfragewartezeiten unter diesem Wert lagen.

Anhand dieses Diagramms wird deutlich, dass diese Farm bei einem kleineren Index eine Abfragewartezeit unter einer Sekunde halten kann, selbst wenn mehr gleichzeitige Benutzer (20) Abfragen in dieser Farm übermitteln.

Abfragedurchsatz

Das folgende Diagramm stellt den Abfragedurchsatz für diese Farm bei zunehmender Benutzerlast dar (erfasst während des Abfragedurchsatztests).

Unter Berücksichtigung der beiden vorhergehenden Diagramme wird deutlich, dass bei einer Benutzerlast über 20 Benutzer in dieser Farm kein zusätzlicher Abfragedurchsatz erzielt werden kann, und die Wartezeit steigt.

Durchforstungsrate

Im folgenden Diagramm wird die Durchforstungsrate für diese Farm während der Phase der Indexerfassung des Lebenszyklus der Suche dargestellt. Die Werte stellen eine vollständige Durchforstung in pro Sekunde durchforsteten Elementen dar.

Der zusätzliche Aufwand im Zusammenhang mit der effizienten Durchführung einer vollständigen Durchforstung in der Inhaltsquelle einer SharePoint-Website hat eine geringere Gesamtdurchforstungsrate in dieser Farm zur Folge.

Fazit

Diese Farm erreicht hinsichtlich des Arbeitsspeichers für die Abfrageserver beinahe ihre maximale Kapazität. Da die Front-End-Webserverprozesse (belegen ebenfalls RAM) auch auf einem der Abfrageserver ausgeführt werden, wirkt sich dies auf die Wartezeit bei Abfragen aus, die auf diesem Server ausgeführt werden.

Die nächsten Schritte zur Steigerung der Leistung für diese Farm sehen wie folgt aus:

• Verschieben Sie Front-End-Webserverprozesse auf ihren eigenen Front-End-Webserver (d. h. einen anderen Front-End-Webserver zum Zweck der Redundanz hinzufügen).

• Fügen Sie beiden Front-End-Webservern mehr RAM hinzu. Wir empfehlen ausreichend RAM auf dem Abfrageserver für 33% der Indexpartition der aktiven Abfragekomponente zuzüglich 3 GB für das Betriebssystem und andere Prozesse.

• Fügen Sie Speicherarrays hinzu, damit Sie die Datenbanken auf dem Datenbankserver isolieren können.

Mittlere Farm

Bei der Konfiguration für mittlere Farmen werden ein Webserver, sechs Anwendungsserver und zwei Datenbankserver wie folgt verwendet:

• In dieser Testkonfiguration wird ein Webserver als Host für das Suchcenter verwendet. Dieser Webserver kann weggelassen werden, falls Suchvorgänge immer von einer untergeordneten Farm unter Verwendung eines Suchdienst-Anwendungsproxys (in der untergeordneten Farm installiert) durchgeführt werden. Andernfalls empfiehlt es sich, dieser Serverfarm einen weiteren Webserver zu Redundanzzwecken hinzufügen.

• Zwei Anwendungsserver werden für das Durchforsten und die Verwaltung verwendet. Dies bedeutet Folgendes:

  • Die Zentraladministration und die Suchverwaltungskomponente werden auf einem der Anwendungsserver erstellt.

  • Jeder Server verfügt über zwei Durchforstungskomponenten. Jede Durchforstungskomponente ist an eine andere Durchforstungsdatenbank angefügt.

• Die verbleibenden vier Anwendungsserver werden für Abfragen verwendet. Für bis zu 40 Mio Elemente sieht die Standardkonfiguration vier Indexpartitionen vor. Redundante Abfragefunktionalität wird erreicht, indem Abfragekomponenten so angeordnet werden, dass jeder Server über eine aktive Abfragekomponente einer der Indexpartitionen und eine Failover-Abfragekomponente einer anderen Indexpartition verfügt. Diese Beispielfarm zeigt jedoch, wie Sie bei der Planung bei mehr als 40 Mio. Elementen vorgehen sollten. Beginnen Sie mit acht Indexpartitionen (jede mit einer eigenen aktiven und einer Failover-Abfragekomponente) auf den vier Anwendungsservern, wodurch das Neupartitionieren von Indexen minimiert wird. Es wird angenommen, dass jeder der Server die folgenden Richtlinien erfüllt, um vier Komponenten auf dem gleichen Anwendungsserver zu ermöglichen:

  • Ausreichend RAM und IOPS sind verfügbar.

  • Jeder Server verfügt über mehr als sechs CPU-Kerne, um die Verarbeitung wie folgt zu unterstützen:

    • Vier CPU-Kerne für die beiden aktiven Abfragekomponenten.

    • Zwei CPU-Kerne für die beiden Failover-Abfragekomponenten.

• Zwei Datenbankserver unterstützen die Serverfarm. Ein Datenbankserver wird für die beiden Durchforstungsdatenbanken verwendet. Der andere Server wird für die Eigenschaften- und die Suchverwaltungsdatenbanken verwendet sowie für die anderen SharePoint-Datenbanken. Die Datenbankserver sollten über eine dedizierte Anzahl an IOPS für jede Durchforstungs-, Eigenschaften- und Suchverwaltungsdatenbank verfügen (verwenden Sie z. B. verschiedene Speicherarrays).

Spezifikationen

Dieser Abschnitt enthält ausführliche Informationen zur Hardware, Software, Topologie und Konfiguration der Testumgebung.

Topologie

Hardware

Webserver

Webserver	Front-End-Webserver (1)
Prozessor	2px4c @ 2,33 GHz
RAM	8 GB
Betriebssystem	Windows Server 2008 R2, 64-Bit-Version
Speicherkapazität	2 x 148 GB 15K SAS: RAID1: OS
Anzahl der Netzwerkschnittstellenkarten (NICs)	2
NIC-Geschwindigkeit	1 Gigabit
Authentifizierung	NTLM
Lastenausgleichstyp	n/v
Softwareversion	Microsoft SharePoint Server (Vorabversion)
Lokal ausgeführte Dienste	Alle Dienste

Anwendungsserver

In der Farm sind sechs Anwendungsserver vorhanden. Vier Server werden für die Bearbeitung der Abfragen und zwei Server für das Durchforsten verwendet.

Server (Anzahl)	Abfrage (4)	Durchforstung (1), Durchforstung/Verwaltung (1)
Prozessor	2px4c @ 2,33 GHz	2px4c @ 2,33 GHz
RAM	32 GB	8 GB
Betriebssystem	Windows Server 2008 R2, 64-Bit-Version	Windows Server 2008 R2, 64-Bit-Version
Speicherkapazität	2 x 148 GB 15K SAS: RAID1: OS 4 x 300 GB 15K SAS: RAID10: DATA	2 x 148 GB 15K SAS: RAID1: OS/DATA
Anzahl der Netzwerkschnittstellenkarten (NICs)	2	2
NIC-Geschwindigkeit	1 Gigabit	1 Gigabit
Authentifizierung	NTLM	NTLM
Lastenausgleichstyp	n/v	n/v
Softwareversion	SharePoint Server 2010 (Vorabversion)	SharePoint Server 2010 (Vorabversion)
Lokal ausgeführte Dienste	SharePoint Server-Suche; Suchabfrage- und Websiteeinstellungsdienst	SharePoint Server-Suche

Datenbankserver

Zwei Datenbankserver. Der erste Server enthält die Suchverwaltungs-, Eigenschaften- und andere SharePoint Server-Datenbanken. Der zweite Server enthält die beiden Durchforstungsdatenbanken. Beachten Sie, dass die erstellten Speichermedien die vorhandene Hardware, die für den Test verfügbar war, optimierten.

Datenbankserver	Suchverwaltungs-, Eigenschaften-, SharePoint-Datenbanken	Durchforstungsdatenbanken
Prozessor	2px4c @ 3,2 GHz	4px2c @ 2,19 GHz
RAM	32 GB	16 GB
Betriebssystem	Windows Server 2008 R2, 64-Bit-Version	Windows Server 2008 R2, 64-Bit-Version
Speicherkapazität	2 x 148 GB 15K SAS: RAID1: OS 2 x 148 GB 15K SAS: RAID1: TEMP LOG 2 x 450 GB 15K SAS: RAID1: TEMP DB 6 x 450 GB 15K SAS: RAID10: Eigenschaften-DB 2 x 450 GB 15K SAS: RAID1: Suchverwaltungs-, SharePoint-Datenbanken 2 x 450 GB 15K SAS: RAID1: LOGS	2 x 148 GB 15K SAS: RAID1: OS 2 x 148 GB 15K SAS: RAID1: TEMP LOG 2 x 300 GB 15K SAS: RAID1: TEMP DB 6 x 146 GB 15K SAS: RAID10: Durchforstungs-DB1 6 x 146 GB 15K SAS: RAID10: Durchforstungs-DB2 2 x 300 GB 15K SAS: RAID1: Durchforstungs-DB LOG1 2 x 300 GB 15K SAS: RAID1: Durchforstungs-DB LOG2
Anzahl der Netzwerkschnittstellenkarten (NICs)	2	2
NIC-Geschwindigkeit	1 Gigabit	1 Gigabit
Authentifizierung	NTLM	NTLM
Softwareversion	SQL Server 2008 Enterprise	SQL Server 2008 Enterprise

Arbeitsauslastung

In diesem Abschnitt werden die für die Datengenerierung verwendeten Arbeitslasten beschrieben, einschließlich der Anzahl der Benutzer sowie der Farmnutzungsmuster.

Arbeitsauslastungsmerkmale	Wert
Allgemeine Beschreibung der Arbeitsauslastung	Suchfarmen
Abfragen pro Minute (Durchschnitt)	12
Anzahl gleichzeitiger Benutzer (Durchschnitt)	1
Gesamtanzahl der Abfragen pro Tag	17.280
Zeitgeberaufträge	Suchintegritätsüberwachung - Ablaufverfolgung der Ereignisse, Durchforstungsprotokollbericht, Integritätsanalyseauftrag, Suchen und Verarbeiten

Dataset

In diesem Abschnitt wird das Testfarm-Dataset beschrieben, einschließlich Datenbankinhalten und Größen, Suchindizes und externen Datenquellen.

Objekt	Wert
Suchindexgröße (Anzahl der Elemente)	46 Mio.
Größe der Durchforstungsdatenbank	356 GB
Größe der Protokolldatei der Durchforstungsdatenbank	85 GB
Größe der Eigenschaftendatenbank	304 GB
Größe der Protokolldatei der Eigenschaftendatenbank	9 GB
Größe der Suchverwaltungsdatenbank	5 GB
Größe der aktiven Indexpartitionen	316 GB (79 GB pro aktive Komponente).
Gesamtanzahl der Datenbanken	4
Sonstige Datenbanken	SharePoint_Config; SharePoint_AdminContent; State_Service; Bdc_Service_db; WSS_UsageApplication; WSS_Content

Integritäts- und Leistungsdaten

Dieser Abschnitt enthält Integritäts- und Leistungsdaten speziell für die Testumgebung.

Abfrageleistungsdaten

Die folgenden Messungen wurden bei einem Suchindex mit 46 Mio. Elementen erstellt. Die Spalten enthalten die Messungen, die während des jeweiligen Tests durchgeführt wurden, während die Ergebnisse am Ende der Tabelle aufgeführt sind. Die Messungen setzen sich wie folgt zusammen:

• Abfragewartezeit   Diese Messungen wurden während eines Abfragewartezeittests erstellt, bei dem mithilfe eines Testtools eine Standardfolge von Abfragen als ein Benutzer übermittelt und dann die sich ergebende Wartezeit gemessen wurde. Während des Tests fanden keine Durchforstungen statt.

• Abfragedurchsatz   Diese Messungen wurden während eines Abfragedurchsatztests durchgeführt, bei dem mithilfe eines Testtools eine Standardfolge von Abfragen als steigende Anzahl gleichzeitiger Benutzer (bis zu 80) an die Farm übermittelt wurde. Während des Tests fanden keine Durchforstungen statt.

	Scorecardmetrik	Abfragewartezeit	Abfragedurchsatz
CPU-Metriken	Durchschnittl. SQL Server-CPU (Eigenschaftendatenbankserver)	5%	98%
	Front-End-Webserver-CPU (Durchschnitt)	3%	33%
	Abfrageserver-CPU (Durchschnitt)	3%	47%
Zuverlässigkeit	Fehlerrate	0,07%	0%
	Front-End-Webserverabstürze	0	0
	Anwendungsserverabstürze	0	0
SQL Server (Eigenschaftendatenbankserver)	Cache-Trefferrate (SQL Server)	100%	99,9%
	SQL Server-Sperren: durchschnittl. Wartezeit (ms)	0,000	0,159
	SQL Server-Sperren: Sperrenwartezeit (ms)	0,000	0,080
	SQL Server-Sperren: Deadlocks/s	0	0
	SQL Server-Latches: durchschnittl. Wartezeit (ms)	0,041	1,626
	SQL Server-Kompilierungen/s	9,776	93,361
	SQL Server-Statistik: SQL Server-Neukompilierungen/s	0,059	0,071
	Verhältnis von Lese-/Schreibvorgängen (E/A pro Datenbank)	0,01	0,81
	Durchschnittl. Länge der Datenträgerwarteschlange (SQL Server)	0,001	0,037
	Länge der Datenträgerwarteschlange: Schreibvorgänge (SQL Server)	0,000	0,003
	Lesevorgänge/s (SQL Server)	0,057	14,139
	Schreibvorgänge/s (SQL Server)	4,554	17,515
Anwendungsserver	Durchschnittl. Länge der Datenträgerwarteschlange (Abfrageserver)	0,000	0,001
	Länge der Datenträgerwarteschlange: Schreibvorgänge (Abfrageserver)	0,000	0,001
	Lesevorgänge/s (Abfrageserver)	0,043	0,266
	Schreibvorgänge/s (Abfrageserver)	4,132	5,564
	Durchschnittl. belegter Arbeitsspeicher (Abfrageserver)	9%	10%
	Maximal belegter Arbeitsspeicher (Abfrageserver)	9%	10%
Front-End-Webserver	ASP.NET-Anforderungen in Warteschlange (Durchschnitt aller Front-End-Webserver)	0	0
	Durchschnittl. belegter Arbeitsspeicher (Front-End-Webserver)	47%	48%
	Maximal belegter Arbeitsspeicher (Front-End-Webserver)	47%	49%
Testergebnisse	Anzahl der Erfolge	1398	14.406
	Anzahl der Fehler	1	0
	Abfragewartezeit (UI) (75. Perzentile)	0,47 s	2,57 s
	Abfragewartezeit (UI) (95. Perzentile)	0,65 s	3,85 s
	Abfragedurchsatz	2,38 Anforderungen/s	27,05 Anforderungen/s

Durchforstungsleistungsdaten

Die folgenden Messungen wurden bei vollständigen Anfangsdurchforstungen der jeweiligen Inhaltsquelle durchgeführt. Die Größe der Inhaltsquelle ist in Millionen von Elementen angegeben. Die Spalten enthalten die Messungen, die während der jeweiligen Durchforstung erstellt wurden, während die Ergebnisse am Ende der Tabelle aufgeführt sind.

	Scorecardmetrik	SharePoint-Inhalt (3,5 Mio.)	Dateifreigabe (1 Mio.)	HTTP (Nicht-SharePoint) (1 Mio.)
CPU-Metriken	Durchschnittl. SQL Server-CPU (Durchforstungsdatenbankserver, Eigenschaftendatenbankserver)	11%, 19%	22%, 7%	23%, 5%
	Maximale SQL Server-CPU (Durchforstungsdatenbankserver, Eigenschaftendatenbankserver)	96%, 100%	86%, 45%	79%, 28%
	Indexer-CPU (Durchschnitt)	41,6%	69%	71%
Zuverlässigkeit	Fehlerrate	0,2%	0,02%	0%
	Front-End-Webserverabstürze	0	0	0
	Anwendungsserverabstürze	0	0	0
SQL Server (Durchforstungsdatenbankserver, Eigenschaftendatenbankserver)	Cache-Trefferrate (SQL Server)	99,5%, 99,8%	Nicht erfasst	99,9%, 99,3%
	SQL Server-Sperren: durchschnittl. Wartezeit [ms]	1881,749, 1106,314	1617,980, 2,882	983,137, 0,904
	SQL Server-Sperren: maximale Wartezeit [ms]	69.919,500, 1081,703	55.412,000, 304,500	24.000,500, 47
	SQL Server-Sperren: durchschnittl. Sperrenwartezeit [ms]	339,658, 10.147,012	Nicht erfasst	739,232, 0,136
	SQL Server-Sperren: maximale Sperrenwartezeit [ms]	598.106,544, 234.708.784	Nicht erfasst	52.711,592, 23,511
	SQL Server-Sperren: Deadlocks/s	0,001, 0	Nicht erfasst	0,008, 0
	SQL Server-Latches: durchschnittl. Wartezeit [ms]	2,288, 13,684	3,042, 13,516	2,469, 20,093
	SQL Server-Latches: maximale Wartezeit [ms]	2636, 1809	928, 858,5	242,929, 938,706
	SQL Server-Kompilierungen/s (Durchschnitt)	20,384, 5,449	Nicht erfasst	76,157, 6,510
	SQL Server-Kompilierungen/s (Maximum)	332,975, 88,992	Nicht erfasst	295,076, 42,999
	SQL Server-Statistik: SQL Server-Neukompilierungen/s (Durchschnitt)	0,560, 0,081	Nicht erfasst	0,229, 0,125
	SQL Server-Statistik: SQL Server-Neukompilierungen/s (Maximum)	22,999, 88,492	Nicht erfasst	17,999, 15,5
	Verhältnis von Lese-/Schreibvorgängen (E/A pro Datenbank) (Maximum)	2,15, 1,25	Nicht erfasst	1,45, 0,364
	Durchschnittl. Länge der Datenträgerwarteschlange (SQL Server)	66,765, 27,314	129,032, 20,665	182,110, 11,816
	Maximale Länge der Datenträgerwarteschlange (SQL Server)	4201,185, 5497,980	3050,015, 762,542	1833,765, 775,7
	Länge der Datenträgerwarteschlange: Schreibvorgänge (SQL Server) (Durchschnitt)	58,023, 13,532	114,197, 19,9	175,621, 10,417
	Länge der Datenträgerwarteschlange: Schreibvorgänge (SQL Server) (Maximum)	1005,691, 881,892	1551,437, 761,891	1018,642, 768,289
	Lesevorgänge/s (SQL Server) (Durchschnitt)	245,945, 94,131	Nicht erfasst	137,435, 154,103
	Lesevorgänge/s (SQL Server) (Maximum)	6420,412, 6450,870	Nicht erfasst	3863,283, 1494,805
	Schreibvorgänge/s (SQL Server) (Durchschnitt)	458,144, 286,884	Nicht erfasst	984,668, 278,175
	Schreibvorgänge/s (SQL Server) (Maximum)	2990,779, 5164,949	Nicht erfasst	2666,285, 4105,897
Anwendungsserver	Durchschnittl. Länge der Datenträgerwarteschlange (Durchforstungsserver)	0,052	0,043	0,030
	Länge der Datenträgerwarteschlange: Schreibvorgänge (Durchforstungsserver)	0,029	0,031	0,026
	Lesevorgänge/s (Durchforstungsserver)	5,405	Nicht erfasst	0,798
	Schreibvorgänge/s (Durchforstungsserver)	48,052	Nicht erfasst	102,235
	Durchschnittl. belegter Arbeitsspeicher (Durchforstungsserver)	68%	45%	52%
	Maximal belegter Arbeitsspeicher (Durchforstungsserver)	76%	47%	59%
Front-End-Webserver	ASP.NET-Anforderungen in Warteschlange (Durchschnitt aller Front-End-Webserver)	0	0	0
	Durchschnittl. belegter Arbeitsspeicher (Front-End-Webserver)	n/v	n/v	n/v
	Maximal belegter Arbeitsspeicher (Front-End-Webserver)	n/v	n/v	n/v
Testergebnisse	Anzahl der Erfolge	3.631.080	1.247.838	200.000
	Anzahl der Fehler	7930	304	0
	Portaldurchforstungsgeschwindigkeit (Elemente/s)	82	148	81
	Ankerdurchforstungsgeschwindigkeit (Elemente/s)	1573	1580	1149
	Gesamte Durchforstungsgeschwindigkeit (Elemente/s)	79	136	76

Testdaten

Dieser Abschnitt enthält Testdaten, die die Leistung der Farm bei Auslastung veranschaulichen.

Abfragewartezeit

Das folgende Diagramm zeigt die Abfragewartezeitperzentilen für diese Farm bei steigender Benutzerlast (erfasst während des Abfragedurchsatztests). Eine Abfrageperzentile von 95 Prozent bedeutet, dass 95 Prozent der gemessenen Abfragewartezeiten unter diesem Wert lagen.

Anhand dieses Diagramms wird deutlich, dass diese Farm bei einem kleineren Index eine Abfragewartezeit unter einer Sekunde auf der 95. Perzentile halten kann, selbst wenn mehr gleichzeitige Benutzer (22) Abfragen in dieser Farm übermitteln.

Abfragedurchsatz

Das folgende Diagramm stellt den Abfragedurchsatz für diese Farm bei zunehmender Benutzerlast dar (erfasst während des Abfragedurchsatztests).

In diesem und dem vorhergehenden Diagramm wird deutlich, dass bei 33 Mio. Elementen im Index eine Wartezeit in der Farm von unter einer Sekunde auf der 75. Perzentile bei ca. 30 gleichzeitigen Benutzern gehalten werden kann. Zusätzliche gleichzeitige Benutzerlast kann zwar verarbeitet werden, doch steigt die Abfragewartezeit auf über eine Sekunde.

Bei 46 Mio. Elementen im Index kann jedoch keine zusätzliche gleichzeitige Benutzerlast verarbeitet werden, und die Abfragewartezeit steigt.

Durchforstungsrate

Im folgenden Diagramm wird die Durchforstungsrate für diese Farm während der Phase der Indexerfassung des Lebenszyklus der Suche dargestellt. Die Werte stellen eine vollständige Durchforstung in pro Sekunde durchforsteten Elementen dar.

Der zusätzliche Aufwand im Zusammenhang mit der effizienten Durchführung einer Durchforstung in der Inhaltsquelle einer SharePoint-Website hat eine geringere Gesamtdurchforstungsrate in dieser Farm zur Folge.

Fazit

Diese Farm erreicht hinsichtlich des Arbeitsspeichers für die Abfrageserver beinahe ihre maximale Kapazität.

Die nächsten Schritte zur Steigerung der Leistung dieser Farm sehen wie folgt aus:

• Fügen Sie beiden Front-End-Webservern mehr RAM hinzu. Wir empfehlen ausreichend RAM auf dem Abfrageserver für 33% der Indexpartition der aktiven Abfragekomponente zuzüglich 3 GB für das Betriebssystem und andere Prozesse.

• Fügen Sie dem Datenbankserver, auf dem die Eigenschaftendatenbank gehostet wird, mehr RAM hinzu. In dieser Konfiguration hatten die Schlüsseltabellen eine Größe von ca. 92 GB (einschließlich Indizes), was 30 GB RAM voraussetzt. Dem Datenbankserver standen jedoch für die Eigenschaftendatenbank, Suchverwaltungsdatenbank und sonstige SharePoint Server-Datenbanken nur 32 GB RAM zur Verfügung.

• Fügen Sie Speicherarrays hinzu, damit Sie die Datenbanken auf dem Datenbankserver isolieren können.

• Skalieren Sie horizontal, um den Durchsatz zu steigern oder die Abfragewartezeit zu senken oder beides.

Obwohl die Durchforstungsgeschwindigkeit in dieser Farm mit zwei Durchforstungsdatenbanken und vier Durchforstungskomponenten hoch ist, kann ein wichtiges Ziel für die Farm darin liegen, dass bestimmte Teile des Index aktueller sind, d. h. dass bestimmte Inhalte sehr häufig durchforstet werden müssen. Durch Hinzufügen einer weiteren Durchforstungsdatenbank, dediziert für Hosts in der gewünschten Inhaltsquelle (mit Hostverteilungsregeln), und Zuordnen zweier zusätzlicher Durchforstungskomponenten zur Datenbank könnte die Vorgabe für die Indexaktualität umgesetzt werden.

Große Farm

Bei der erwarteten Konfiguration werden ein Webserver, sechs Anwendungsserver und drei Datenbankserver wie folgt verwendet:

• Ein Webserver wird als Host für ein Suchcenter verwendet. Dieser Webserver kann weggelassen werden, falls Suchvorgänge immer von einer Inhaltsfarm unter Verwendung eines Suchdienst-Anwendungsproxys (in der Inhaltsfarm installiert) durchgeführt werden.

• Drei Anwendungsserver werden für das Durchforsten und die Verwaltung verwendet. Dies bedeutet Folgendes:

  • Die Zentraladministration und die Suchverwaltungskomponente werden auf einem der Anwendungsserver erstellt.

  • Jeder Server verfügt über zwei Durchforstungskomponenten. Jede Durchforstungskomponente ist an eine gesonderte Durchforstungsdatenbank angefügt.

• Die verbleibenden zehn Anwendungsserver werden für Abfragen verwendet. Die bevorzugte Konfiguration besteht in der Verwendung von zehn Indexpartitionen. Jeder Server verfügt dann über eine primäre Abfragekomponente aus einer der Indexpartitionen, zusätzlich zu einer Failover-Abfragekomponente aus einer anderen Indexpartition.

• Vier Datenbankserver unterstützen die Serverfarm. Ein Server wird für die Eigenschaften- und Suchverwaltungsdatenbanken verwendet. Ein zweiter Server wird für eine Eigenschaftendatenbank verwendet. Ein dritter Server wird für zwei Durchforstungsdatenbanken verwendet. Der vierte Server wird für eine Durchforstungsdatenbank und die anderen SharePoint-Datenbanken verwendet. Die Datenbankserver sollten über eine dedizierte Anzahl an IOPS für jede Durchforstungs-, Eigenschaften- und Suchverwaltungsdatenbank verfügen (verwenden Sie z. B. verschiedene Speicherarrays).

Spezifikationen

Dieser Abschnitt enthält ausführliche Informationen zur Hardware, Software, Topologie und Konfiguration der Testumgebung.

Topologie

In diesem Abschnitt wird die Topologie der Testumgebung beschrieben.

Hardware

In diesem Abschnitt wird die Hardware beschrieben, die für die Tests verwendet wurde.

Webserver

Webserver	Front-End-Webserver (1)
Prozessor	2px4c @ 2,33 GHz
RAM	8 GB
Betriebssystem	Windows Server 2008 R2, 64-Bit-Version
Speicherkapazität	2 x 148 GB 15K SAS: RAID1: OS
Anzahl der Netzwerkschnittstellenkarten (NICs)	2
NIC-Geschwindigkeit	1 Gigabit
Authentifizierung	NTLM
Lastenausgleichstyp	n/v
Softwareversion	SharePoint Server 2010 (Vorabversion)
Lokal ausgeführte Dienste	Alle Dienste

Anwendungsserver

In der Farm sind 13 Anwendungsserver vorhanden. Zehn Server werden für das Bedienen von Abfragen und drei Server für das Durchforsten verwendet.

Server (Anzahl)	Abfrage (10)	Durchforstung (2), Durchforstung/Verwaltung (1)
Prozessor	2px4c @ 2,5 GHz	2px4c @ 2,5 GHz
RAM	32 GB	32 GB
Betriebssystem	Windows Server 2008 R2, 64-Bit-Version	Windows Server 2008 R2, 64-Bit-Version
Speicherkapazität	2 x 148 GB 15K SAS: RAID1: OS 4 x 300 GB 15K SAS: RAID10: DATA	2 x 148 GB 15K SAS: RAID1: OS/DATA
Anzahl der Netzwerkschnittstellenkarten (NICs)	2	2
NIC-Geschwindigkeit	1 Gigabit	1 Gigabit
Authentifizierung	NTLM	NTLM
Lastenausgleichstyp	n/v	n/v
Softwareversion	SharePoint Server 2010 (Vorabversion)	SharePoint Server 2010 (Vorabversion)
Lokal ausgeführte Dienste	SharePoint Server-Suche; Suchabfrage- und Websiteeinstellungsdienst	SharePoint Server-Suche

Datenbankserver

Vier Datenbankserver. Der erste Server enthält die Suchverwaltungs- und Eigenschaftendatenbanken, der zweite Server enthält eine Eigenschaftendatenbank, der dritte Server enthält zwei Durchforstungsdatenbanken und der vierte Server enthält eine Durchforstungsdatenbank und eine SharePoint-Datenbank. Beachten Sie, dass die erstellten Speichermedien die vorhandene Hardware, die für den Test verfügbar war, optimierten.

Datenbankserver	Suchverwaltungs-, Eigenschaften- und SharePoint-Datenbanken	Durchforstungsdatenbanken
Prozessor	2px4c @ 3,2 GHz	4px2c @ 2,19 GHz
RAM	32 GB	16 GB
Betriebssystem	Windows Server 2008 R2, 64-Bit-Version	Windows Server 2008 R2, 64-Bit-Version
Speicherkapazität	2 x 148 GB 15K SAS: RAID1: OS 2 x 148 GB 15K SAS: RAID1: TEMP LOG 2 x 450 GB 15K SAS: RAID1: TEMP DB 6 x 450 GB 15K SAS: RAID10: Eigenschaften-DB 2 x 450 GB 15K SAS: RAID1: Suchverwaltungs-, SharePoint-Datenbanken 2 x 450 GB 15K SAS: RAID1: LOGS	2 x 148 GB 15K SAS: RAID1: OS 2 x 148 GB 15K SAS: RAID1: TEMP LOG 2 x 300 GB 15K SAS: RAID1: TEMP DB 6 x 146 GB 15K SAS: RAID10: Durchforstungs-DB1 6 x 146 GB 15K SAS: RAID10: Durchforstungs-DB2 2 x 300 GB 15K SAS: RAID1: Durchforstungs-DB LOG1 2 x 300 GB 15K SAS: RAID1: Durchforstungs-DB LOG2
Anzahl der Netzwerkschnittstellenkarten (NICs)	2	2
NIC-Geschwindigkeit	1 Gigabit	1 Gigabit
Authentifizierung	NTLM	NTLM
Softwareversion	SQL Server 2008 Enterprise	SQL Server 2008 Enterprise

Abfrageleistungsdaten

Die folgenden Messungen wurden bei einem Index mit 103 Mio. Elementen erstellt. Die Spalten enthalten die Messungen, die während des jeweiligen Tests durchgeführt wurden, während die Ergebnisse am Ende der Tabelle aufgeführt sind. Die durchgeführten Messungen setzen sich wie folgt zusammen:

• Abfragewartezeit   Diese Messungen wurden während eines Abfragewartezeittests erstellt, bei dem mithilfe eines Testtools eine Standardfolge von Abfragen als ein Benutzer übermittelt und die sich ergebende Wartezeit gemessen wurde. Während des Tests wurden keine Durchforstungen ausgeführt.

• Abfragedurchsatz   Diese Messungen wurden während eines Abfragedurchsatztests erstellt, bei dem mithilfe eines Testtools eine Standardfolge von Abfragen als steigende Anzahl gleichzeitiger Benutzer (bis zu 120) an die Farm übermittelt wurde. Während des Tests wurden keine Durchforstungen ausgeführt.

	Scorecardmetrik	Abfragedurchsatz
CPU-Metriken	Durchschnittl. SQL Server-CPU (Eigenschaftendatenbankserver)	34%
	Front-End-Webserver-CPU (Durchschnitt)	45%
	Abfrageserver-CPU (Durchschnitt)	20%
Zuverlässigkeit	Fehlerrate	0%
	Front-End-Webserverabstürze	0
	Anwendungsserverabstürze	0
SQL Server (Eigenschaftendatenbankserver)	Cache-Trefferrate (SQL Server)	100%
	SQL Server-Sperren: durchschnittl. Wartezeit (ms)	0
	SQL Server-Sperren: Sperrenwartezeit (ms)	0
	SQL Server-Sperren: Deadlocks/s	0
	SQL Server-Latches: durchschnittl. Wartezeit (ms)	1,401
	SQL Server-Kompilierungen/s	73,349
	SQL Server-Statistik: SQL Server-Neukompilierungen/s	0,006
	Verhältnis von Lese-/Schreibvorgängen (E/A pro Datenbank)	0,81
	Durchschnittl. Länge der Datenträgerwarteschlange (SQL Server)	0,037
	Länge der Datenträgerwarteschlange: Schreibvorgänge (SQL Server)	0,003
	Lesevorgänge/s (SQL Server)	9,88
	Schreibvorgänge/s (SQL Server)	354,1
Anwendungsserver	Durchschnittl. Länge der Datenträgerwarteschlange (Abfrageserver)	0,002
	Länge der Datenträgerwarteschlange: Schreibvorgänge (Abfrageserver)	0,002
	Lesevorgänge/s (Abfrageserver)	0,035
	Schreibvorgänge/s (Abfrageserver)	6,575
	Durchschnittl. belegter Arbeitsspeicher (Abfrageserver)	6,548%
	Maximal belegter Arbeitsspeicher (Abfrageserver)	6,601%
Front-End-Webserver	ASP.NET-Anforderungen in Warteschlange (Durchschnitt aller Front-End-Webserver)	0
	Durchschnittl. belegter Arbeitsspeicher (Front-End-Webserver)	18,081%
	Maximal belegter Arbeitsspeicher (Front-End-Webserver)	19,983%
Testergebnisse	Anzahl der Erfolge	10.925
	Anzahl der Fehler	0
	Abfragewartezeit (UI) (75. Perzentile)	3,431 s
	Abfragewartezeit (UI) (95. Perzentile)	3,512 s
	Abfragedurchsatz	36,42 Anforderungen/s

Leistungsdaten für Durchforstungen

Die folgenden Messungen wurden bei sequenziellen, vollständigen Anfangsdurchforstungen des jeweiligen Inhalts erstellt. Die Größe der Inhaltsquelle ist in Millionen von Elementen angegeben. Die Spalten enthalten die Messungen, die während der jeweiligen Durchforstung durchgeführt wurden, während die Ergebnisse am Ende der Tabelle aufgeführt sind.

	Scorecardmetrik	SharePoint-Inhalt (3,5 Mio.)	Dateifreigabe (1 Mio.)
CPU-Metriken	Durchschnittl. SQL Server-CPU (Durchforstungsdatenbankserver, Eigenschaftendatenbankserver)	15,74%, n/v	24%, 6,6%
	Maximale SQL Server-CPU (Durchforstungsdatenbankserver, Eigenschaftendatenbankserver)	100%, n/v	100%, 45%
	Indexer-CPU (Durchschnitt)	44%	49%
Zuverlässigkeit	Fehlerrate	0,0%	0,00%
	Front-End-Webserverabstürze	0	0
	Anwendungsserverabstürze	0	0
SQL Server (Durchforstungsdatenbankserver, Eigenschaftendatenbankserver)	Cache-Trefferrate (SQL Server)	99,8%, n/v	99,797%, 99,49%
	SQL Server-Sperren: durchschnittl. Wartezeit [ms]	734,916, n/v	1165, 5,866
	SQL Server-Sperren: maximale Wartezeit [ms]	15.335, n/v	28.683, 210,5
	SQL Server-Sperren: durchschnittl. Sperrenwartezeit [ms]	108,98, n/v	847,72, 5,325
	SQL Server-Sperren: maximale Sperrenwartezeit [ms]	17.236,96, n/v	124.353, 12.920
	SQL Server-Sperren: Deadlocks/s	0, n/v	0,012, 0
	SQL Server-Latches: durchschnittl. Wartezeit [ms]	1,4, n/v	2,233, 40,6
	SQL Server-Latches: maximale Wartezeit [ms]	1606, n/v	917,8, 1895
	SQL Server-Kompilierungen/s (Durchschnitt)	24,28, n/v	72,7, 11,39
	SQL Server-Kompilierungen/s (Maximum)	416, n/v	460, 76,62
	SQL Server-Statistik: SQL Server-Neukompilierungen/s (Durchschnitt)	0,560, n/v	0,295, 0,099
	SQL Server-Statistik: SQL Server-Neukompilierungen/s (Maximum)	0,24, n/v	17,50, 17,393
	Verhältnis von Lese-/Schreibvorgängen (E/A pro Datenbank) (Maximum)	20,3, n/v	1,18/0,214
	Durchschnittl. Länge der Datenträgerwarteschlange (SQL Server)	90,113, n/v	138,64, 27,478
	Maximale Länge der Datenträgerwarteschlange (SQL Server)	3179, n/v	2783,543, 847,574
	Länge der Datenträgerwarteschlange: Schreibvorgänge (SQL Server) (Durchschnitt)	86,93, n/v	130.853, 26,086
	Länge der Datenträgerwarteschlange: Schreibvorgänge (SQL Server) (Maximum)	1882, n/v	2.781,197, 884,801
	Lesevorgänge/s (SQL Server) (Durchschnitt)	99, n/v	147,462, 159,159
	Lesevorgänge/s (SQL Server) (Maximum)	3772, n/v	2403,336, 896,462
	Schreibvorgänge/s (SQL Server) (Durchschnitt)	373, n/v	475,886, 539,497
	Schreibvorgänge/s (SQL Server) (Maximum)	18.522, n/v	2031,888, 4174,271
Anwendungsserver	Durchschnittl. Länge der Datenträgerwarteschlange (Durchforstungsserver)	0,075	0,063
	Länge der Datenträgerwarteschlange: Schreibvorgänge (Durchforstungsserver)	0,046	0,053
	Lesevorgänge/s (Durchforstungsserver)	1,958	1,693
	Schreibvorgänge/s (Durchforstungsserver)	62,33	101,093
	Durchschnittl. belegter Arbeitsspeicher (Durchforstungsserver)	59%	56,38%
	Maximal belegter Arbeitsspeicher (Durchforstungsserver)	70%	58,93%
Front-End-Webserver	ASP.NET-Anforderungen in Warteschlange (Durchschnitt aller Front-End-Webserver)	n/v	n/v
	Durchschnittl. belegter Arbeitsspeicher (Front-End-Webserver)	n/v	n/v
	Maximal belegter Arbeitsspeicher (Front-End-Webserver)	n/v	n/v
Testergebnisse	Anzahl der Erfolge	1.909.739	1.247.838
	Anzahl der Fehler	9361	331
	Portaldurchforstungsgeschwindigkeit (Elemente/s)	70,3	131,44
	Ankerdurchforstungsgeschwindigkeit (Elemente/s)	764	525,84
	Gesamte Durchforstungsgeschwindigkeit (Elemente/s)	64	105

Empfehlungen und Problembehandlung

Die folgenden Abschnitte enthalten Empfehlungen, um die von Ihnen benötigte Hardware, Topologie und Konfiguration für die Bereitstellung von zu diesen Szenarien ähnlichen Umgebungen zu bestimmen und um die Umgebungen für die entsprechenden Kapazitäts- und Leistungsmerkmale zu optimieren.

Empfehlungen

In diesem Abschnitt werden die jeweiligen Aktionen beschrieben, die Sie zur Optimierung der Umgebung für die entsprechenden Kapazitäts- und Leistungsmerkmale durchführen können.

Hardwareempfehlungen

Spezifische Informationen zu den Mindestanforderungen sowie empfohlenen Systemanforderungen finden Sie unter Hardware- und Softwareanforderungen (SharePoint Server 2010). Beachten Sie, dass die Anforderungen an Server, die für die Suche verwendet wurden, die allgemeinen Systemanforderungen ersetzen. Verwenden Sie die folgenden empfohlenen Richtlinien für RAM, Prozessor und IOPS, um die Leistungsziele zu erreichen.

Größenbestimmung für das Suchsystem

In diesem Abschnitt wird das Suchsystem erläutert, einschließlich der Anforderungen und Richtlinien hinsichtlich der Größenbestimmung der einzelnen Komponenten.

SharePoint Server 2010 kann auf vielfältige Weise bereitgestellt und konfiguriert werden. Deshalb ist es nicht einfach, abzuschätzen, wie viele Benutzer oder Elemente von einer bestimmten Anzahl von Servern unterstützt werden können. Führen Sie deshalb in Ihrer eigenen Umgebung Tests durch, ehe Sie SharePoint Server 2010 in einer Produktionsumgebung bereitstellen.

Suchabfragesystem

In diesem Abschnitt werden die Komponenten des Suchabfragesystems für eine bestimmte Suchdienstanwendung dargestellt. Die Anforderungen zur Größenbestimmung jeder Komponente werden in der Tabelle "Skalierungsdetails" nach dem folgenden Diagramm aufgeführt.

Objektbeschreibungen

Die folgende Liste definiert die Suchabfragesystemobjekte aus dem vorherigen Diagramm:

• Suchdienst   Hierbei handelt es sich um den Suchdienst-Anwendungsproxy, der in jeder Serverfarm installiert ist, die Suchvorgänge für diese Suchdienstanwendung ausführt. Er wird im Kontext der Webanwendungen ausgeführt, die dem Suchdienst-Anwendungsproxy zugeordnet sind.

• Suchabfrage- und Websiteeinstellungsdienst   Auch bekannt als der Abfrageprozessor. Als Empfänger der Abfrage einer Suchdienst-Anwendungsproxyverbindung führt ein Abfrageprozessor die folgenden Aufgaben aus:

  • Sendet die Abfrage an eine aktive Suchkomponente pro Indexpartition (oder, je nach Abfrage, an die Eigenschaftendatenbank oder beide)

  • Ruft beste Suchergebnisse ab und entfernt Duplikate, um die Ergebnisse festzulegen

  • Ein Security Trimmer kürzt die Ergebnisse auf der Grundlage von Sicherheitsdeskriptoren in der Suchverwaltungsdatenbank

  • Ruft die Metadaten des endgültigen Resultsets aus der Eigenschaftendatenbank ab

  • Sendet die Abfrageergebnisse zurück an den Proxy

• Indexpartition   Eine logische Gruppe von Abfragekomponenten, die eine Teilmenge des Volltextindex darstellt. Der Volltextindex setzt sich aus der Summe der Indexpartitionen zusammen. Beachten Sie jedoch, dass Abfragekomponenten die aktuelle Teilmenge des Index enthalten. Eine Indexpartition ist einer Eigenschaftendatenbank zugeordnet.

• Suchabfragekomponente   Eine Abfragekomponente enthält den gesamten Volltextindex oder Teile davon. Bei der Abfrage über einen Abfrageprozessor ermittelt die Abfragekomponente die besten Ergebnisse aus dem Index und gibt diese Elemente zurück. Einer Abfragekomponente kann beim Erstellen eine der folgenden Eigenschaften zugeordnet werden:

  • Aktiv, somit reagiert sie standardmäßig auf Abfragen. Durch Hinzufügen mehrerer aktiver Abfragekomponenten für dieselbe Indexpartition wird der Durchsatz gesteigert.

  • Failover; dabei reagiert sie nur dann auf Abfragen, wenn alle aktiven Komponenten für dieselbe Indexpartition nicht ausgeführt werden können.

• Suchverwaltungsdatenbank   Wird diese gleichzeitig mit der Suchdienstanwendung erstellt, enthält die Suchverwaltungsdatenbank die Daten, die die gesamte Suchdienstanwendung betreffen und für Abfragen, wie beste Suchergebnisse und Sicherheitsdeskriptoren, verwendet werden, zusätzlich zu Anwendungseinstellungen für die Verwaltung.

• Eigenschaftendatenbank   Eine Eigenschaftendatenbank enthält die Metadaten (Titel, Autor, verwandte Felder) der Elemente im Index. Die Eigenschaftendatenbank wird für eigenschaftenbasierte Abfragen zusätzlich zum Abrufen von Metadaten verwendet, die für die Anzeige der Endergebnisse erforderlich sind. Wenn mehrere Indexpartitionen vorhanden sind, können sie verschiedenen Eigenschaftendatenbanken zugeordnet werden.

Skalierungsdetails

Objekt	Skalierungsaspekte	RAM	IOPS (Lesen/Schreiben)
Suchdienst	Dieser wird mit den Front-End-Webservern skaliert, denen er zugeordnet ist.	n/v	n/v
Suchabfrage- und Websiteeinstellungsdienst	Dieser Dienst, der auf der Seite Dienste auf dem Server in der Zentraladministration installiert ist, sollte auf jedem Server mit einer Abfragekomponente gestartet werden. Er kann auch auf einen gesonderten Server (oder zur Steigerung der Verfügbarkeit auf ein Serverpaar) verschoben werden, damit kein RAM auf den Servern mit den Abfragekomponenten beansprucht wird. Darüber hinaus wird ein benutzerdefinierter Security Trimmer verwendet, der sich auf CPU- und RAM-Ressourcen auswirken kann.	Verwendet RAM (Prozesscache) für die Zwischenspeicherung von Sicherheitsdeskriptoren für den Index.	n/v
Indexpartition	Durch Erhöhen der Anzahl von Indexpartitionen sinkt die Anzahl der Elemente in der Indexpartition. Dadurch sinkt der erforderliche RAM und Festplattenspeicherplatz auf dem Abfrageserver, der die Abfragekomponente hostet, die der Indexpartition zugewiesen ist.	n/v	n/v
Abfragekomponente	Jede aktive Abfragekomponente auf einem Server belegt beim Bedienen von Abfragen Speicherplatz. Jede aktive Abfragekomponente wird als Teil der Topologie einer Suchdienstanwendung erstellt oder geändert. Sowohl aktive Komponenten als auch Failoverkomponenten belegen E/A während der Durchforstung. Server können für Abfragekomponenten reserviert werden (z. B. zwei aktive Komponenten und zwei Failoverkomponenten auf demselben Server), vorausgesetzt, dass die RAM- und E/A-Anforderungen erfüllt sind. Wenn möglich, reservieren Sie mindestens zwei CPU-Kerne pro aktive Komponente pro Server und mindestens einen CPU-Kern pro Failoverkomponente pro Server.	Für jede aktive Abfragekomponente auf einem Anwendungsserver sollten 33% des Index im RAM (Betriebssystemcache) vorhanden sein.	2 K erforderlich pro Abfragekomponentenpaar (aktiv/Failover) auf einem bestimmten Server. Die Abfragekomponente benötigte E/A für: Laden des Index in RAM für Abfragen Schreiben von Indexfragmenten, die von den einzelnen Durchforstungskomponenten stammen Zusammenführen von Indexfragmenten mit dem Index, wie bei einer Hauptzusammenführung
Suchverwaltungsdatenbank	Bei jeder Abfrage werden beste Suchergebnisse und Sicherheitsdeskriptoren aus der Suchverwaltungsdatenbank geladen. Stellen Sie sicher, dass der Datenbankserver über ausreichend RAM für den Ladevorgang aus dem Cache verfügt. Wenn möglich, sollte diese nicht auf einem Server mit einer Durchforstungsdatenbank platziert werden, da die Durchforstungsdatenbank dazu tendiert, den Cache des Datenbankservers zurückzusetzen.	Stellen Sie sicher, dass der Datenbankserver über ausreichend RAM verfügt, damit die kritische Tabelle (MSSSecurityDescriptors) im RAM verbleibt.	700
Eigenschaftendatenbank	Bei jeder Abfrage werden Metadaten aus der Eigenschaftendatenbank für die Dokumentergebnisse abgerufen, sodass Sie die Leistung durch Hinzufügen von RAM zum Datenbankserver verbessern können. Wenn mehrere Indexpartitionen vorliegen, können Sie die Eigenschaftendatenbank partitionieren und auf einen anderen Datenbankserver verschieben, um die RAM- und E/A-Anforderungen zu senken.	Stellen Sie sicher, dass der Datenbankserver über ausreichend RAM verfügt, damit 33% der kritischen Tabellen (MSSDocSDIDs, MSSDocProps, MSSDocresults) im Cache aufbewahrt werden können.	2 K 30% Lesen, 70% Schreiben

Suchdurchforstungssystem

In diesem Abschnitt werden die Komponenten des Suchdurchforstungssystems dargestellt. Die Anforderungen zur Größenbestimmung jeder Komponente werden in der Tabelle nach dem Diagramm aufgeführt.

Objektbeschreibungen

In diesem Abschnitt werden die Suchdurchforstungssystemobjekte im vorherigen Diagramm definiert:

• Verwaltungskomponente   Eine Verwaltungskomponente wird beim Starten einer Durchforstung verwendet, wenn zusätzlich eine Verwaltungsaufgabe im Durchforstungssystem durchgeführt wird.

• Durchforstungskomponente   Eine Durchforstungskomponente verarbeitet Durchforstungen, gibt die resultierenden Indexfragmentdateien an Abfragekomponenten weiter und fügt Informationen über den Speicherort und den Durchforstungszeitplan zur zugeordneten Durchforstungsdatenbank hinzu.

• Suchverwaltungsdatenbank   In der Suchverwaltungsdatenbank, die gleichzeitig mit der Suchdienstanwendung erstellt wird, werden die Sicherheitsdeskriptoren beschrieben, die während der Durchforstung ermittelt werden, zusätzlich zu den Anwendungseinstellungen für die Verwaltung.

• Durchforstungsdatenbank   Eine Durchforstungsdatenbank enthält Daten im Zusammenhang mit dem Speicherort von Inhaltsquellen, Durchforstungszeitpläne und sonstige, für Durchforstungsvorgänge spezifische Informationen. Sie können durch Erstellen von Hostverteilungsregeln für spezifische Hosts reserviert werden. In einer Durchforstungsdatenbank werden nur Daten gespeichert. Die Durchforstung wird von der Durchforstungskomponente ausgeführt, die der jeweiligen Durchforstungsdatenbank zugeordnet ist.

• Suchabfragesystem

Skalierungsdetails

Objekt	Skalierungsaspekte	RAM	IOPS (optional, % Lesen/Schreiben)
Verwaltungskomponente	Die einzelne Verwaltungskomponente ist nicht skalierbar. Standardmäßig befindet sie sich auf einem Server, der eine Durchforstungskomponente (sowie bei kleineren Farmen die Zentraladministration) hostet.	Minimal	Minimal
Durchforstungskomponente	Durchforstungskomponenten beanspruchen viel CPU-Bandbreite. Im Optimalfall sollte eine einzelne Durchforstungskomponente vier CPU-Kerne nutzen können. RAM spielt keine so wichtige Rolle. In größeren Farmen können die Auswirkungen von Crawlern durch die Verwendung von dedizierten Servern als Hosts für Durchforstungskomponenten minimiert werden (vor allem bei Verwendung von Durchforstungskomponenten, die verschiedenen Durchforstungsdatenbanken zugeordnet sind, sofern Redundanz gewünscht wird).	Moderat. Beim Durchforsten ostasiatischer Dokumente steigen die RAM-Anforderungen aufgrund von Wörtertrennungen.	300-400
Suchverwaltungsdatenbank	Siehe Suchabfragesystem oben. Wenn möglich, sollte diese nicht auf einem Server mit einer Durchforstungsdatenbank platziert werden, da die Durchforstungsdatenbank dazu tendiert, den Cache des Datenbankservers zurückzusetzen.	Siehe Suchabfragesystem oben.	700
Durchforstungsdatenbank	Durchforstungsdatenbanken beanspruchen viel E/A-Bandbreite. RAM spielt keine so wichtige Rolle. Eine Durchforstungsdatenbank benötigt 3,5 K IOPS für die Durchforstung von Aktivitäten; abhängig von der verfügbaren Bandbreite werden bis zu 6 K IOPS beansprucht.	Moderat	3,5-7 K 73% Lesen, 27% Schreiben

Berechnen von Speichergrößen

Berechnen Sie die folgenden Faktoren für die Schätzung der Speicheranforderungen. Die Faktoren für die Größenbestimmung basieren auf einem internen System vor der Bereitstellung mit einem Index, der in erster Linie SharePoint-Inhalt enthält (die Größe der Inhaltsdatenbanken beträgt 13,3 Terabyte). Im Allgemeinen wurden für die SharePoint-Suche ca. 20 Prozent des Speicherplatzes der Inhaltsdatenbanken benötigt. Wie bereits hingewiesen, sollten Sie in Ihrer eigenen Umgebung Tests durchführen, ehe Sie SharePoint Server 2010 in einer Produktionsumgebung bereitstellen.

Einschränkungen:

• Beim Korpus, der zum Ableiten dieser Zahlen verwendet wurde, handelte es sich vorrangig um (englischen) SharePoint-Inhalt. Wenn also der von Ihnen verwendete Inhalt abweicht (beispielsweise hauptsächlich aus Dateifreigaben oder aus Nicht-SharePoint-basierten HTTP-Websites besteht), müssen Sie eine stärkere Abweichung zulassen.

• Selbst wenn es sich vorrangig um SharePoint-Inhalt handelt, können die Koeffizienten dennoch unter den folgenden Umständen variieren:

  • Bei Verwendung von großen Dokumentrepositorys sind die Koeffizienten deutlich größer.

  • Wenn es sich beim Inhalt vorrangig um Bilder handelt, können Sie die Koeffizienten eventuell reduzieren.

  • Inhalt in einer anderen Sprache wirkt sich vermutlich auf die Koeffizienten aus.

1. Berechnen des Größenbestimmungsfaktor für Inhaltsdatenbanken (ContentDBSum)

Bestimmen Sie die Summe der SharePoint-Inhaltsdatenbanken, die durchforstet werden. Dies entspricht dem ContentDBSum-Wert, der als Korrelation in den nächsten Speicherberechnungen verwendet wird.

2. Berechnen indexbasierter Größen (TotalIndexSize und QueryComponentIndexSize)

Bestimmen Sie die Größe des Gesamtindex (befindet sich in den Abfragekomponenten und wird für Volltextabfragen verwendet):

Multiplizieren Sie ContentDBSum mit 0,035. Dies entspricht dem TotalIndexSize-Wert, ehe Sie Speicherplatz für Zusammenführungen und Neupartitionierungen partitionieren und reservieren.

Bestimmen Sie als Nächstes die Anzahl der gewünschten Indexpartitionen abhängig von Ihrem Szenario. Als allgemeine Regel gilt, dass eine Indexpartition über 5-10 Mio. Elemente verfügen sollte. Wenn Sie die Anzahl der Indexpartitionen bestimmt haben, können Sie die Größe des Speichers für Abfragekomponenten berechnen.

• Dividieren Sie TotalIndexSize durch (Anzahl der Indexpartitionen). Dies ist der QueryComponentIndexSize-Wert. Er wird zur Berechnung der folgenden Größen verwendet:

  • Für den RAM multiplizieren Sie QueryComponentIndexSize mit 0,33. Dies ist das Minimum an Arbeitsspeicher, das für diese Abfragekomponente benötigt wird, falls sie aktiv ist.

    • Wenn es sich bei der Komponente um eine Failoverkomponente handelt, wird der RAM erst benötigt, wenn die Komponente aktiv wird.

    • Für einen bestimmten Server bedeutet die Verwendung mehrerer aktiver Abfragekomponenten auf demselben Server, dass Sie den RAM aller aktiven Abfragekomponenten addieren müssen, um die RAM-Anforderungen für den Server zu bestimmen.

  • Für den Festplattenspeicher verwenden Sie QueryComponentIndexSize wie folgt für die Schätzung der Festplattenanforderungen, abhängig davon, ob Sie vorhaben, den Index jemals neu zu partitionieren (also davon ausgehen, dass der Index die Grenze von 10 Mio. pro Partition übersteigt):

    • Multiplizieren Sie QueryComponentIndexSize mit 3, um den Festplattenspeicher für eine einzelne Abfragekomponente zu berechnen, sodass ausreichend Platz für die Indexzusammenführung bereitsteht.

    • Multiplizieren Sie QueryComponentIndexSize mit 4, um den Festplattenspeicher für eine einzelne Abfragekomponente zu berechnen, sodass ausreichend Platz für die Indexneupartitionierung bereitsteht.

Für einen bestimmten Server bedeutet die Verwendung mehrerer Abfragekomponenten auf demselben Server, dass Sie für jede der Abfragekomponenten ausreichend Speicher einplanen und dabei die IOPS-Anforderungen im Abschnitt "Skalierungsdetails" unter "Suchabfragesystem" weiter oben in diesem Artikel berücksichtigen müssen.

3. Berechnen der Größe von Eigenschaftendatenbanken

Bestimmen Sie die Größe der Eigenschaftendatenbanken wie folgt:

• Multiplizieren Sie ContentDBSum mit 0,015. Dies ist der Wert von TotalPropertyDBSize vor dem Partitionieren.

• Multiplizieren Sie ContentDBSum mit 0,0031. Dies ist der Wert von TotalPropertyDBLogSize vor dem Partitionieren. Dies setzt voraus, dass Sie das einfache Wiederherstellungsmodell für SQL Server-Datenbanken verwenden.

• Multiplizieren Sie ContentDBSum mit 0,00034. Dies ist der Wert von TempDBSize für die Eigenschaftendatenbank. Da empfohlen wird, 33 Prozent der Schlüsseltabellen der Eigenschaftendatenbank im Arbeitsspeicher unterzubringen, ist die Verwendung der temporären Datenbank nicht hoch.

Bestimmen Sie als Nächstes die Anzahl der geplanten Eigenschaftendatenbanken für Ihr Szenario. Als allgemeine Regel gilt, dass eine Eigenschaftendatenbank bis zu 50 Mio. Elemente enthalten sollte, vorausgesetzt, dass keine Probleme mit der Abfrageleistung vorliegen und Sie über eine eingeschränkte Zahl von verwalteten Eigenschaften verfügen (Standardkonfiguration).

• Dividieren Sie TotalPropertyDBSize durch (Anzahl der Eigenschaftendatenbanken). Dies ist der Wert von PropertyDatabaseSize.

• Dividieren Sie TotalPropertyDBLogSize durch (Anzahl der Eigenschaftendatenbanken). Dies ist der Wert von PropertyDatabaseLogSize.

• Für den RAM multiplizieren Sie PropertyDatabaseSize mit 0,33. Dies ist die Mindestmenge an RAM, die für diese Eigenschaftendatenbank empfohlen wird.

Für einen bestimmten Datenbankserver bedeutet die Verwendung mehrerer Eigenschaftendatenbanken auf demselben Server, dass Sie für jede der Eigenschaftendatenbanken ausreichend Speicher und RAM einplanen und dabei die IOPS- und RAM-Anforderungen im Abschnitt "Skalierungsdetails" unter "Suchabfragesystem" weiter oben in diesem Artikel berücksichtigen müssen.

4. Berechnen der Größe von Durchforstungsdatenbanken

Legen Sie im nächsten Schritt die erforderliche Größe für die Durchforstungsdatenbank wie folgt fest:

• Multiplizieren Sie ContentDBSum mit 0,046. Dies ist der Wert von TotalCrawlDBSize vor dem Partitionieren.

• Multiplizieren Sie ContentDBSum mit 0,011. Dies ist der Wert von TotalCrawlDBLogSize vor dem Partitionieren. Dies setzt voraus, dass Sie das einfache Wiederherstellungsmodell für SQL Server-Datenbanken verwenden.

• Multiplizieren Sie ContentDBSum mit 0,0011. Dies ist der Wert von TempDBSize für die Durchforstungsdatenbank. Da sich das Suchdurchforstungssystem auf die Leistung der temporären Datenbank auswirkt, wird nicht empfohlen, andere Datenbanken auf Servern zu platzieren, die die Durchforstungsdatenbank oder sonstige Datenbanken hosten, auf die sich diese Nutzung auswirken könnte.

Bestimmen Sie als Nächstes die Anzahl der für Ihr Szenario geplanten Durchforstungsdatenbanken. Als allgemeine Regel gilt, dass eine Durchforstungsdatenbank bis zu 25 Mio. Elemente enthalten sollte, vorausgesetzt, dass keine Probleme mit der Durchforstungsleistung vorliegen.

• Dividieren Sie TotalCrawlDBSize durch (Anzahl der Durchforstungsdatenbanken). Dies ist der Wert von CrawlDatabaseSize.

• Dividieren Sie TotalCrawlDBLogSize durch (Anzahl der Durchforstungsdatenbanken). Dies ist der Wert von CrawlDatabaseLogSize.

Für einen bestimmten Datenbankserver bedeutet die Verwendung mehrerer Durchforstungsdatenbanken auf demselben Server, dass Sie für jede der Durchforstungsdatenbanken ausreichend Speicher einplanen und dabei die IOPS-Anforderungen im Abschnitt "Skalierungsdetails" unter "Suchdurchforstungssystem" weiter oben in diesem Artikel berücksichtigen müssen. Für den Arbeitsspeicher wird mindestens 16 GB auf Datenbankservern empfohlen, die für Durchforstungsdatenbanken reserviert sind.

5. Berechnen der Größe der Suchverwaltungsdatenbank

Bestimmen Sie die Größe der Suchverwaltungsdatenbank wie folgt (Windows-Authentifizierung wird vorausgesetzt):

• Multiplizieren Sie die Anzahl der Elemente im Index (in Mio.) mit 0,3. Dies ist der Wert von SearchAdminDBSize.

• Für den Arbeitsspeicher multiplizieren Sie SearchAdminDBSize mit 0,33. Dies ist die Mindestmenge an RAM, die für diese Suchverwaltungsdatenbank empfohlen wird.

Für einen bestimmten Datenbankserver bedeutet die Verwendung mehrerer Datenbanken auf demselben Server, dass Sie für jede der Datenbanken ausreichend Speicher und RAM einplanen und dabei die IOPS- und RAM-Anforderungen im Abschnitt "Skalierungsdetails" unter "Suchabfragesystem" weiter oben in diesem Artikel berücksichtigen müssen.

Optional: Berechnen der Sicherungsgröße

Zum Bestimmen des Festplattenspeichers, der für die Sicherung einer Suchdienstanwendung erforderlich ist, führen Sie die folgende Berechnung aus:

• TotalCrawlDBSize + TotalPropertyDBSize + TotalIndexSize + SearchAdminDBSize = Basissicherungsgröße.

Diese Basissicherungsgröße stellt einen Ausgangspunkt dar, der u. a. von Folgendem beeinflusst wird:

• Zusätzliche Indexgröße, die in TotalIndexSize für etwaige Durchforstungen seit der letzten Hauptzusammenführung aufgenommen wird.

• Wachstum im Laufe der Zeit aufgrund von zusätzlichen Elementen, Abfragen und Sicherheitsdeskriptoren.

Zusätzlich möchten Sie vermutlich mehrere Sicherungen von verschiedenen Zeiten aufbewahren und Speicherplatz für die nächste Sicherung freihalten.

Übung zur Größenbestimmung

Mithilfe der oben aufgeführten Faktoren zur Größenbestimmung führen Sie hier eine Übung zur Größenbestimmung einer Serverfarm mit 100 Mio. Elementen durch, die Abfragen in erster Linie über SharePoint-Inhalte bereitstellt. Bei Verwendung des Szenarios für große Farmen wird von Folgendem ausgegangen:

• Zehn logische Indexpartitionen sind für die 100 Mio. Elemente erforderlich.

• Zum Bedienen von Abfragen benötigen Sie 10 aktive Abfragekomponenten, jeweils eine pro Indexpartition.

• Abfrageredundanz ist wichtig, deshalb werden 10 Failover-Abfragekomponenten benötigt, eine pro Indexpartition (nicht auf demselben Server wie die aktive Komponente).

Führen Sie die folgenden Schritte aus, um die Speicher- und RAM-Anforderungen zu bestimmen:

1. Addieren Sie in einer SharePoint-Inhaltsfarm mit mehreren Inhaltsdatenbanken die Inhaltsdatenbanken, die durchforstet werden sollen, sodass sich 20 Terabyte ergeben.

2. Multiplizieren Sie mithilfe des Indexkoeffizienten oben 20 Terabyte mit 0,035 (Indexkoeffizient), um 716,8 GB zu erhalten. Dies ist der Wert von TotalIndexSize. Bei nur einer Partition ist dies die Größe des Index im Ruhezustand.

3. Dividieren Sie TotalIndexSize durch die Anzahl der Partitionen: 716,8 GB/71,68 GB. Dies ist die Indexgröße, die pro Abfragekomponente erforderlich ist (QueryComponentIndexSize), bei einer Indexpartition. Die Größe ist bei aktiven oder Failover-Abfragekomponenten identisch.

4. Multiplizieren Sie TotalIndexSize mit 4, wenn Neupartionierungen geplant sind, andernfalls mit 3, um Hauptzusammenführungen zu unterstützen. 71,68 GB * 4 = 286,72 GB. Auf dem Datenträger des Abfrageservers sollten 286,72 GB zur Verfügung stehen, um eine Abfragekomponente zu unterstützen. Bei zwei Abfragekomponenten auf demselben Anwendungsserver (wie in der aktiven/Failover-Topologie, die für das Szenario mit großen Farmen empfohlen wird) würde das Layout des Datenträgerlaufwerks wie folgt aussehen:

   1. Laufwerk mit dem Betriebssystem (Standardgröße).

   2. Zusatzspeichersystem 1: Abfragekomponente1_Freigabe (Größe = mind. 300 GB), verwendet für die aktive Abfragekomponente von Indexpartition 1.

   3. Zusatzspeichersystem 2: Abfragekomponente2_Freigabe (Größe = mind. 300 GB), verwendet für die Failover (Spiegel)-Abfragekomponente von Indexpartition 2.

Softwaregrenzwerte

In der folgenden Tabelle sind Softwarebeschränkungen aufgeführt, die festgelegt wurden, um ein akzeptables Suchverhalten sicherzustellen.

Objekt	Grenze	Zusätzliche Hinweise
SharePoint-Suchdienstanwendung	Empfohlenes Maximum von 20 pro Farm. Absolutes Maximum von 256 Dienstanwendungen insgesamt.	Sie können mehrere Suchdienstanwendungen in derselben Serverfarm bereitstellen, da sie Suchkomponenten und Datenbanken verschiedenen Servern zuweisen können.
Indizierte Dokumente	Empfohlenes Gesamtmaximum von 10 Mio. Elementen pro Indexpartition und 100 Mio. Elementen pro Suchdienstanwendung.	Die SharePoint-Suche unterstützt Indexpartitionen, die jeweils einen Teil des gesamten Suchindex enthalten. Das empfohlene Maximum liegt bei 10 Mio. Elementen für eine bestimmte Partition. Die insgesamt empfohlene maximale Anzahl von Elementen, einschließlich Personen, Listenelementen, Dokumenten und Webseiten liegt bei 100 Millionen.
Indexpartitionen	Empfohlenes Maximum von 20 pro Suchdienstanwendung	Diese Indexpartition ist eine logische Teilmenge des Index der Suchdienstanwendung. Die empfohlene Grenze liegt bei 20. Durch Erhöhen der Anzahl von Indexpartitionen sinkt die Anzahl der Elemente in der Indexpartition. Dadurch sinkt der erforderliche RAM und Festplattenspeicherplatz auf dem Abfrageserver, der die Abfragekomponente hostet, die der Indexpartition zugewiesen wurde. Dies kann sich jedoch auf die Relevanz auswirken, da die Anzahl der Elemente in der Indexpartition reduziert wird. Die harte Grenze für Indexpartitionen liegt bei 128.
Eigenschaftendatenbank	Die empfohlene Grenze liegt bei 10 pro Suchdienstanwendung	In der Eigenschaftendatenbank werden die Metadaten für Elemente in jeder zugeordneten Indexpartition gespeichert. Eine Indexpartition kann nur einem Eigenschaftenspeicher zugeordnet sein. Die empfohlene Grenze liegt bei 10 pro Suchdienstanwendung mit einer harten Grenze von 255 (identisch mit Indexpartitionen).
Durchforstungsdatenbanken	Die Grenze liegt bei 32 Durchforstungsdatenbanken pro Anwendung	In der Durchforstungsdatenbank werden die Durchforstungsdaten zu allen Elementen gespeichert, die durchforstet wurden. Die empfohlene Grenze liegt bei 25 Mio. Elementen pro Durchforstungsdatenbank oder vier Datenbanken insgesamt pro Suchdienstanwendung.
Durchforstungskomponenten	Die empfohlene Grenze pro Anwendung liegt bei 16 Durchforstungskomponenten insgesamt, mit jeweils zwei pro Durchforstungsdatenbank und zwei pro Server, vorausgesetzt, dass der Server mindestens acht Prozessoren (Kerne) besitzt.	Die Gesamtzahl von Durchforstungskomponenten pro Server muss niedriger sein als 128/(Abfragekomponenten insgesamt), um die Verschlechterung der Verteilungs-E/A zu minimieren. Das Überschreiten der empfohlenen Grenze muss die Durchforstungsleistung nicht erhöhen. Tatsächlich kann die Durchforstungsleistung in Abhängigkeit von den verfügbaren Ressourcen des Durchforstungsservers, der Datenbank und des Inhaltshosts abnehmen.
Abfragekomponenten	Die empfohlene Grenze pro Anwendung liegt bei 128, mit 64/(Durchforstungskomponenten insgesamt) pro Server.	Die Gesamtzahl der Abfragekomponenten wird durch die Fähigkeit der Durchforstungskomponenten zum Kopieren von Dateien beschränkt. Die maximale Anzahl von Abfragekomponenten pro Server wird durch die Fähigkeit der Abfragekomponenten zur Aufnahme der von den Durchforstungskomponenten verteilten Dateien begrenzt.
Gleichzeitige Durchforstungen	Die empfohlene Grenze liegt bei 20 Durchforstungen pro Suchdienstanwendung	Hierbei handelt es sich um die Anzahl der Durchforstungen, die gleichzeitig stattfinden. Durchforstungen sind äußerst aufwändige Suchaufgaben, die sich zusätzlich zu anderen Anwendungslasten auf die Datenbanklast auswirken können. Wenn der Wert von 20 gleichzeitigen Durchforstungen überschritten wird, kann dies negative Folgen auf die Gesamtdurchforstungsrate haben.
Inhaltsquellen	Die empfohlene Grenze liegt bei 50 Inhaltsquellen pro Suchdienstanwendung.	Die empfohlene Grenze kann bis zur harten Grenze von 500 pro Suchdienstanwendung überschritten werden. Es sollten jedoch weniger Startadressen verwendet werden. Außerdem muss die Grenze für gleichzeitige Durchforstungen eingehalten werden.
Startadressen	Empfohlene Grenze von 100 Startadressen pro Inhaltsquelle.	Die empfohlene Grenze kann bis zur harten Grenze von 500 pro Inhaltsquelle überschritten werden. Es sollten jedoch weniger Inhaltsquellen verwendet werden. Ein besserer Ansatz bei vielen Startadressen besteht darin, sie als Verknüpfungen auf eine HTML-Seite zu platzieren und den HTTP-Crawler die Seite durchforsten zu lassen, wobei er den Verknüpfungen folgt.
Durchforstungsregeln	Empfohlene Grenze von 100 pro Suchdienstanwendung	Diese Empfehlung kann überschritten werden; allerdings verschlechtert sich die Anzeige von Durchforstungsregeln für die Suchverwaltung.
Durchforstungsprotokolle	Empfohlene Grenze von 100 Mio. pro Anwendung	Dies ist die Anzahl einzelner Protokolleinträge im Durchforstungsprotokoll. Sie richtet sich nach der Grenze für indizierte Dokumente.
Pro Element erkannte Metadateneigenschaften	Die harte Grenze liegt bei 10.000.	Hierbei handelt es sich um die Anzahl von Metadateneigenschaften, die beim Durchforsten eines Elements bestimmt (und potenziell zugeordnet oder für Abfragen verwendet) werden können.
Durchforstete Eigenschaften	500.000 pro Suchdienstanwendung	Hierbei handelt es sich um die bei einer Durchforstung ermittelten Eigenschaften.
Verwaltete Eigenschaften	100.000 pro Suchdienstanwendung	Hierbei handelt es sich um Eigenschaften, die vom Suchsystem in Abfragen verwendet werden. Durchforstete Eigenschaften werden verwalteten Eigenschaften zugeordnet. Es wird ein Maximum von 100 Zuordnungen pro verwalteter Eigenschaft empfohlen. Das Überschreiten dieser Grenze kann zu einer Verschlechterung der Durchforstungsgeschwindigkeit und Abfrageleistung führen.
Bereiche	Empfohlene Grenze von 200 pro Website.	Hierbei handelt es sich um eine empfohlene Grenze pro Website. Das Überschreiten dieser Grenze kann dazu führen, dass die Durchforstungseffizienz abnimmt, und sich auf die Browserwartezeit für Endbenutzer auswirken, falls die Bereiche zur Anzeigegruppe hinzugefügt werden. Außerdem verschlechtert sich die Anzeige der Bereiche in der Suchverwaltung, wenn die Anzahl der Bereiche die empfohlene Grenze übersteigt.
Anzeigegruppen	25 pro Website	Diese Gruppen werden für eine gruppierte Anzeige von Bereichen über die Benutzeroberfläche verwendet. Mit dem Überschreiten dieser Grenze verschlechtert sich die Bereichsfunktionalität in der Suchverwaltung.
Bereichsregeln	Empfohlene Grenze liegt bei 100 Bereichsregeln pro Bereich und 600 insgesamt pro Suchdienstanwendung.	Bei Überschreiten dieser Grenze nimmt die Aktualität ab, und mögliche Ergebnisse von Abfragen mit zugewiesenen Bereichen werden verzögert.
Schlüsselwörter	Empfohlene Grenze von 200 pro Websitesammlung.	Die empfohlene Grenze kann bis zur (durch ASP.NET bestimmten) Maximalgrenze von 5000 pro Websitesammlung bei fünf besten Suchergebnissen pro Schlüsselwort überschritten werden. Die Anzeige von Schlüsselwörtern auf der Benutzeroberfläche der Websiteverwaltung verschlechtert sich. Die durch ASP.NET bestimmte Grenze kann durch das Bearbeiten der Dateien Web.config und Client.config(MaxItemsInObjectGraph) geändert werden.
Autorisierende Seiten	Die empfohlene Grenze ist eine autorisierende Seite auf höchster Ebene und möglichst wenige Seiten auf zweiter und dritter Ebene, um die gewünschte Relevanz zu erreichen.	Die harte Grenze liegt bei 200 pro Relevanzebene pro Suchanwendung, doch wird bei Hinzufügen von Seiten möglicherweise nicht die gewünschte Relevanz erzielt. Fügen Sie die Schlüsselwebsite zur ersten Relevanzebene hinzu. Fügen Sie weitere Schlüsselwebsites der zweiten oder dritten Relevanzebene jeweils einzeln hinzu, und bewerten Sie nach jedem Hinzufügen die Relevanz, um sicherzustellen, dass der gewünschte Relevanzeffekt erreicht wird.
Warnungen	Empfohlene Grenze von 1.000.000 pro Suchdienstanwendung	Hierbei handelt es sich um den getesteten Grenzwert.
Entfernen von Ergebnissen	100 URLs in einem Vorgang	Hierbei handelt es sich um die empfohlene Maximalzahl an URLs, die in einem einzigen Vorgang aus dem System entfernt werden sollten.

Optimierungen

In den folgenden Abschnitten werden Methoden zur Steigerung der Leistung von Farmen erläutert.

Viele Faktoren können sich auf die Leistung auswirken. Dazu zählen die Anzahl der Benutzer sowie Typ, Komplexität und Häufigkeit von Benutzervorgängen, die Anzahl von Postbacks in einem Vorgang sowie die Leistung von Datenverbindungen. Jeder dieser Faktoren kann sich stark auf den Farmdurchsatz auswirken. Bei der Planung der Bereitstellung sollten Sie jeden dieser Faktoren sorgfältig prüfen.

Die Kapazität und Leistung eines Suchsystems hängt in starkem Maß von seiner Topologie ab. Sie können entweder durch Steigern der Kapazität der vorhandenen Servercomputer vertikal skalieren oder durch Hinzufügen von Servern zur Topologie horizontal skalieren.

Optimierungen des Suchabfragesystems

Im Allgemeinen folgen die Suchabfrageoptimierungen einem der folgenden Szenarien:

• Benutzer beklagen sich über die Abfragewartezeit, also muss ich die Abfragewartezeit senken.

• Es werden deutlich mehr Suchanforderungen ausgeführt als geplant, und die Leistung beginnt zu sinken, deshalb muss ich den Abfragedurchsatz steigern.

Die vertikale oder horizontale Skalierung des Abfrageteilsystems schließt immer das Erstellen zusätzlicher Abfragekomponenten ein. Wenn Sie über Überkapazitäten (RAM, E/A und CPU) auf einem vorhandenen Abfrageserver verfügen, können Sie sich für die vertikale Skalierung durch Erstellen zusätzlicher Abfragekomponenten auf diesem Server entscheiden, und RAM, CPU oder E/A im Falle eines Engpasses erhöhen. Andernfalls haben Sie die Möglichkeit, weitere Abfragekomponenten zu erstellen oder die vorhandenen Komponenten für die vertikale Skalierung auf einen neuen Server zu verschieben.

Im folgenden Abschnitt werden verschiedene Wege dargestellt, um dem Suchabfragesystem Abfrageressourcen hinzuzufügen.

Senken der Abfragewartezeit

Hinzufügen von Abfragekomponenten zur Senkung der Wartezeit

Im folgenden Diagramm werden die Auswirkungen dargestellt, die sich durch Hinzufügen aktiver Abfragekomponenten auf verschiedenen Servern ohne Ändern der Indexgröße ergeben.

Fügen Sie zusätzliche aktive Abfragekomponenten hinzu, um die Abfragewartezeit unter einer Sekunde zu halten, während die Benutzerlast auf das System steigt (gemessen in gleichzeitigen Benutzerabfragen).

Hinzufügen von Abfrageprozessoren (Suchabfrage- und Websiteeinstellungsdienst) zur Senkung der Wartezeit

Im folgenden Diagramm werden die Auswirkungen dargestellt, die sich durch Hinzufügen aktiver Abfrageprozessordienste auf verschiedenen Servern ergeben, ohne andere Teile des Abfragesystems zu ändern.

Starten Sie andere aktive Instanzen des Suchabfrage- und Websiteeinstellungsdienstes auf verschiedenen Servern, um die Abfragewartezeit auf unter einer Sekunde zu halten, während die Benutzerlast auf das System steigt (gemessen in gleichzeitigen Benutzerabfragen).

Vertikales Skalieren zur Steigerung des Abfragedurchsatzes

Hinzufügen von Abfragekomponenten zur Steigerung des Abfragedurchsatzes

Im folgenden Diagramm werden die Auswirkungen dargestellt, die sich durch Hinzufügen aktiver Abfragekomponenten auf verschiedenen Servern ohne Ändern der Indexgröße ergeben.

Fügen Sie zusätzliche Abfragekomponenten hinzu, um den Abfragedurchsatz zu steigern, während die Benutzerlast auf das System steigt (gemessen in gleichzeitigen Benutzerabfragen).

Hinzufügen von Abfrageprozessoren (Suchabfrage- und Websiteeinstellungsdienst) zur Steigerung des Abfragedurchsatzes

Im folgenden Diagramm werden die Auswirkungen dargestellt, die sich durch Hinzufügen aktiver Abfrageprozessordienste auf verschiedenen Servern ergeben, ohne andere Teile des Abfragesystems zu ändern.

Fazit: Starten Sie andere aktive Instanzen des Suchabfrage- und Websiteeinstellungsdienstes auf verschiedenen Servern, um den Durchsatz zu steigern, während die Benutzerlast auf dem System steigt (gemessen in gleichzeitigen Benutzerabfragen).

Optimierungen des Suchdurchforstungssystems

Im Allgemeinen führen Sie Optimierungen des Suchdurchforstungssystems durch. wenn sich Benutzer über Ergebnisse beklagen, die vorhanden sein sollten, es jedoch nicht sind bzw. zwar vorhanden, aber veraltet sind.

Wenn Sie versuchen, die Startadresse von Inhaltsquellen innerhalb der Aktualitätsvorgaben zu durchforsten, können die folgenden Probleme mit der Durchforstungsleistung auftreten:

• Die Durchforstungsrate ist niedrig aufgrund von IOPS-Engpässen im Teilsystem für die Suchdurchforstung.

• Die Durchforstungsrate ist niedrig aufgrund fehlender CPU-Threads im Teilsystem der Suchdurchforstung.

• Die Durchforstungsrate ist niedrig aufgrund einer geringen Repositoryreaktion.

Bei jedem dieser Probleme ist die Durchforstungsrate niedrig. Lesen Sie unter Verwenden von Suchverwaltungsberichten (SharePoint Server 2010) nach (unter Berücksichtigung der Lebenszyklusphasen der Software), um eine Basislinie für die Standarddurchforstungsrate für das System im Laufe der Zeit einzurichten. Wenn diese Basislinie zurückgeht, finden Sie in den folgenden Teilabschnitten Möglichkeiten, diese Probleme mit der Durchforstungsleistung zu beheben.

IOPS-Engpass der Durchforstungsdatenbank

Nachdem Sie festgestellt haben, dass eine Durchforstungs- oder Eigenschaftendatenbank einen Engpass darstellt, müssen Sie das Durchforstungssystem horizontal oder vertikal skalieren, um den Engpass mithilfe geeigneter Lösungen zu beseitigen. In der folgenden Tabelle wird gezeigt, wie durch Hinzufügen von IOPS (einer weiteren Durchforstungsdatenbank) eine gesteigerte Durchforstungsrate erzielt werden kann (bis durch Hinzufügen von Komponenten erneut ein Engpass auftritt).

Fazit: Überprüfen Sie die Durchforstungsdatenbank stets, um sicherzustellen, dass sie keinen Engpass darstellt. Wenn die IOPS der Durchforstungsdatenbank bereits einen Engpass darstellen, bringt das Hinzufügen von Durchforstungskomponenten oder Steigern der Threadanzahl keine Abhilfe.

Topologie (Durchforstungskomponente/ Durchforstungsdatenbank)	CPU-Prozentsatz	RAM: Puffercache-Trefferquote %	Lesewartezeit	Schreibwartezeit	Durchforstungsgeschwindigkeit (Dok/s)
2/1	19,5	99,6	142 ms	73 ms	50
4/2	8502	99,55	45 ms	75 ms	~75
6/2	22	99,92	55 ms	1050 ms	~75

CPU-Thread-Durchforstungsengpass

Wenn Sie über eine hohe Anzahl von Hosts verfügen und keine anderen Durchforstungsengpässe vorliegen, müssen Sie mithilfe geeigneter Lösungen das Durchforstungssystem horizontal oder vertikal skalieren. Der Crawler kann maximal 256 Threads pro Suchdienstanwendung verarbeiten. Es wird die Verwendung eines Quad-Core-Prozessors empfohlen, um in den Genuss aller Vorteile durch die maximale Anzahl an Threads zu gelangen. Wenn schließlich festgestellt wird, dass Daten ausreichend schnell vom Repository bereitgestellt werden (siehe Abschnitt "Durchforstungsengpass im Repository" nachfolgend in diesem Artikel), kann der Durchforstungsdurchsatz gesteigert werden, indem Daten schneller durch eine erhöhte Anzahl von Crawlerthreads aus dem Repository angefordert werden. Dies ist auf drei unterschiedliche Arten wie folgt möglich:

1. Ändern Sie die Leistungsebene zur Indexerstellung zu Teilweise verringert oder Maximum mithilfe des folgenden Windows PowerShell-Cmdlets:

   • Get-SPEnterpriseSearchService | Set-SPEnterpriseSearchService –PerformanceLevel “Maximum”

     Der Wert Maximum wird bei Verwendung eines Prozessors mit weniger als vier Kernen verwendet.

2. Steigern Sie mithilfe von Regeln für Crawlerauswirkungen die Anzahl der Threads pro Host. Dabei sollte berücksichtigt werden, dass maximal 256 Threads unterstützt werden und dass die Zuweisung von vielen Threads an wenige Hosts zu einer langsameren Datenabfrage aus anderen Repositorys führen kann.

3. Bei zahlreichen Hosts besteht die optimale Lösung darin, eine andere Durchforstungskomponente auf einem gesonderten Indexer hinzuzufügen, um die Hosts zu durchforsten, die schneller indiziert werden müssen.

Der ideale Ansatz für die nahtlose Steigerung des Durchforstungsdurchsatzes besteht darin, einen weiteren Indexer hinzuzufügen, wenn kein IOPS-Engpass im Suchteilsystem vorliegt und Inhalte rasch vom Repository bedient werden.

Durchforstungsengpass im Repository

Wenn eine SharePoint-Webanwendung mit zahlreichen geschachtelten Websitesammlungen oder Remotedateifreigaben durchforstet wird, kann es zu einem Engpass des Suchcrawlers im Repository kommen. Ein Repositoryengpass liegt dann vor, wenn die folgenden zwei Bedingungen zutreffen:

• Auf den Durchforstungsservern ist die CPU-Auslastung niedrig (weniger als 20 Prozent).

• Die Anzahl der wartenden Threads im Netzwerk ist hoch (im schlimmsten Falle beinahe alle).

  Der Engpass kann mithilfe des Leistungsindikators Office Server Search-Gatherer/Auf das Netzwerk zugreifende Threads identifiziert werden.

In dieser Situation werden die Threads blockiert, während sie auf Daten aus dem Repository warten. In einer Umgebung mit mehreren Inhaltsquellen kann es hilfreich sein, den Host zu identifizieren, dessen Reaktion langsam ist, indem alle anderen Durchforstungen angehalten werden, und dann eine Durchforstung mithilfe der Inhaltsquelle durchzuführen, die den vermuteten Host als eine ihrer Startadressen besitzt.

Wenn ein problematischer Host identifiziert werden kann, müssen Sie die Ursache für die langsame Reaktionszeit untersuchen. Speziell für SharePoint-Inhalte finden Sie Informationen hierzu im Artikel Capacity management and sizing for SharePoint Server 2010.

Der Durchforstungsdurchsatz kann deutlich durch Optimieren der Leistung der durchforsteten Datenrepositorys gesteigert werden.

Problembehandlung von Leistungs- und Skalierungsproblemen

Vor der Problembehandlung der Leistung ist es wichtig, die Lasten für die Farm zu kennen. Im folgenden Abschnitt werden Daten aus einer Livefarm mit 60 Mio. Elementen verwendet, um verschiedene Systemmetriken in unterschiedlichen Phasen im Lebenszyklus der Suche darzustellen.

Leistungsbeispiele während des Lebenszyklus der Suche

Metrik	Indexerfassung	Indexverwaltung	Indexbereinigung
SQL Server-CPU (in %) Eigenschaftendatenbank/Durchforstungsdatenbank	14,8/19,13	35/55	11/63
Lebenserwartung für SQL Server-Seite Eigenschaftendatenbank/Durchforstungsdatenbank	60.548/5913	83.366/5373	33.927/2806
SQL Server: Mittlere Sek./Schreibvorgänge Eigenschaftendatenbank/Durchforstungsdatenbank	9 ms/48 ms MAX: 466 ms/1277 ms	12 ms/28 ms	20 ms/49 ms MAX: 253 ms/1156 ms
SQL Server: Mittlere Sek./Lesevorgänge Eigenschaftendatenbank/Durchforstungsdatenbank	8 ms/43 ms MAX: 1362 ms/2688 ms	11 ms/24 ms	24 ms/29 ms MAX: 2039 ms/2142 ms
Crawler-CPU (in %) Indexserver 1 (2 Durchforstungskomponenten)/Indexserver 2 (2 Durchforstungskomponenten)	18/11	25,76/21,62	8,34/7,49 Maximale Spitzen bis 99%
Schreibvorgänge/s Indexserver 1 (2 Durchforstungskomponenten)/Indexserver 2 (2 Durchforstungskomponenten)	64,32/42,35	93,31/92,45	99,81/110,98
Lesevorgänge/s Indexserver 1 (2 Durchforstungskomponenten)/Indexserver 2 (2 Durchforstungskomponenten)	0,23/0,20	4,92/2,03	1,38/1,97
Mittlere Sek./Schreibvorgänge Indexserver 1 (2 Durchforstungskomponenten)/Indexserver 2 (2 Durchforstungskomponenten)	11 ms/11 ms	1 ms/2 ms	5 ms/4 ms MAX: 1962 ms/3235 ms
Mittlere Sek./Lesevorgänge Indexserver 1 (2 Durchforstungskomponenten)/Indexserver 2 (2 Durchforstungskomponenten)	1 ms/2 ms	12 ms/11 ms	10 ms/16 ms MAX: 2366 ms/5206 ms

Problembehandlung von Abfrageleistungsproblemen

Die SharePoint-Suche verfügt über eine instrumentierte Abfragepipeline und zugeordnete Verwaltungsberichte, die Sie bei der Problembehandlung von Abfrageleistungsproblemen unterstützen können. Weitere Informationen finden Sie unter Verwenden von Suchverwaltungsberichten (SharePoint Server 2010). Dieser Abschnitt enthält Berichte, die dann verwendet werden, um bei der Problembehandlung von Serverproblemen zu helfen. Darüber hinaus enthält dieser Abschnitt auch Tools und Hinweise, die bei der Lösung von Leistungsproblemen (des Browsers) helfen sollen.

Serverbasierte Abfrageprobleme

Serverbasierte Probleme mit der Abfrageleistung können in die folgenden zwei Gruppen unterteilt werden:

• Leistungsprobleme des Such-Front-Ends

• Leistungsprobleme des Such-Back-Ends

Die folgenden zwei Teilabschnitte enthalten Details zur Problembehandlung beider Bereiche. Es handelt sich hierbei um allgemeine Richtlinien.

Front-End-Leistungsprobleme

Im ersten Schritt zur Problembehandlung der Front-End-Leistung sollten Sie sich den Suchverwaltungsbericht zur Gesamtabfragewartezeit genauer ansehen. Es folgt ein Beispiel für einen solchen Bericht.

In diesem Bericht wird die Front-End-Leistung durch die folgenden Datenreihen dargestellt:

• Serverrendering: Dieser Wert gibt für die jeweilige Minute die durchschnittliche Zeit an, die pro Abfrage in den verschiedenen Suchwebparts auf dem Front-End-Webserver aufgewendet wurde.

• Objektmodell: Dieser Wert gibt für die jeweilige Minute die durchschnittliche Zeit an, die für die Kommunikation zwischen dem Front-End-Webserver und dem Such-Back-End aufgewendet wurde.

Problembehandlung von Serverrenderingproblemen

Probleme mit dem Serverrendering können mit allen Aktionen auf dem Front-End-Webserver zusammenhängen, bei denen die Suchergebnisseite bereitgestellt wird. Im Allgemeinen sollten Sie wissen, wie viel Zeit für das Abrufen der verschiedenen Webparts erforderlich ist, um zu erkennen, an welcher Stelle zusätzliche Wartezeit entsteht. Ausführliche Berichte zur Wartezeit erhalten Sie, indem Sie das Entwicklerdashboard auf der Suchergebnisseite aktiveren. Häufige Probleme, die sich als übermäßige Wartezeit beim Serverrendering äußern, sind u. a. die folgenden:

• Plattformprobleme, wie etwa die folgenden:

  • Langsame Active Directory-Lookups

  • Langsame SQL Server-Zeiten

  • Langsame Anforderungen an den Benutzerprofildienst in Personenabfragen in SharePoint Server 2010 oder in allen Abfragen in FAST Search Server 2010 for SharePoint

  • Langsame Anforderungen beim Abrufen der Benutzervoreinstellungen

  • Langsame Aufrufe des Benutzertokens aus dem Sicherheitstokendienst (Secure Token Service, STS)

• CodeBehind-Probleme, wie z. B. geänderte Suchergebnisseiten (beispielsweise results.aspx und peopleresults.aspx), die eingecheckt, jedoch nicht veröffentlicht werden.

Problembehandlung von Objektmodellproblemen

Objektmodellprobleme können von folgenden Faktoren beeinflusst werden:

• Probleme mit der WCF-Ebene (Windows Communication Foundation) wie etwa die folgenden:

  • Timeouts und threadabortexception in WCF-Aufrufen bei der Bereitstellung.

  • Langsame Kommunikation zwischen dem Front-End-Webserver und dem Anwendungsserver. Dies kann mit IPsec-Problemen oder langsamen Netzwerkverbindungen zusammenhängen.

• Probleme bei der Kommunikation zwischen Inhalts- und Dienstfarmen (sofern konfiguriert).

Back-End-Leistungsprobleme

Im ersten Schritt zur Problembehandlung der Back-End-Abfrageleistung sollten Sie sich den Suchverwaltungsbericht zur SharePoint-Back-End-Abfragewartezeit genauer ansehen. Es folgt ein Beispiel für einen solchen Bericht.

In diesem Bericht wird die Back-End-Leistung durch die folgenden Datenreihen dargestellt (jede gibt die Durchschnittszeit pro Abfrage in der jeweiligen Minute an), gruppiert nach funktionaler Komponente:

• Abfragekomponente

  • Volltextabfrage: Der durchschnittliche Zeitaufwand für die Abfrage des Volltextindex für Ergebnisse.

• Eigenschaftendatenbank:

  • Abruf mehrerer Ergebnisse: Der durchschnittliche Zeitaufwand für das Abrufen von Dokumentmetadaten, z. B. Titel oder Autor, für Abfrageergebnisse.

  • Eigenschaftenspeicherabfrage: Der durchschnittliche Zeitaufwand für die Abfrage der Eigenschaftendatenbanken für auf Eigenschaften basierende Abfragen.

• Suchverwaltungsdatenbank:

  • Beste Suchergebnisse: Der durchschnittliche Zeitaufwand für das Ermitteln der Tatsache, ob für die Abfrageausdrücke beste Suchergebnisse verfügbar sind.

  • Vertrauenswürdige Ergebnisse: Der durchschnittliche Zeitaufwand für das Abrufen von vertrauenswürdigen Ergebnissen von Abfragen.

• Abfrageprozessor:

  • Sicherheitskürzung: Der durchschnittliche Zeitaufwand für das Entfernen von Elementen, auf die der Benutzer nicht zugreifen darf.

  • Duplikatentfernung: Der durchschnittliche Zeitaufwand für das Entfernen von Duplikaten.

  • Ergebnisdaten: Durchschnittlicher Zeitaufwand für das Erstellen der an das Objektmodell zurückgegebenen Tabelle im Arbeitsspeicher.

Problembehandlung von Leistungsproblemen bei Abfragekomponenten

Abfragekomponenten sind ressourcenintensiv, vor allem wenn die Komponente aktiv ist, also auf Abfrageanforderungen reagiert. Die Problembehandlung der Leistung von Abfragekomponenten stellt einen der kompliziertesten Suchbereiche dar. Es folgen allgemeine Bereiche, die in Erwägung gezogen werden sollten:

• Das ressourcenintensivste Ereignis für Abfragekomponenten ist die Hauptzusammenführung, bei der Ergänzungsindizes mit dem Hauptindex zusammengeführt werden. Dieses Ereignis wird unabhängig für jede Abfragekomponente ausgeführt. Ein Beispiel für die Auswirkungen können Sie dem weiter oben in diesem Artikel genannten Bericht zur SharePoint-Back-End-Abfragewartezeit im Zeitraum vor 13.30 Uhr entnehmen. Wenn sich dieses Ereignis auf die Abfragewartezeit auswirkt, können Sperrzeiten definiert werden, während denen eine Hauptzusammenführung vermieden wird, sofern der Prozentwert der Änderungen nicht den definierten Grenzwert überschreitet.

• Anhaltend hohe Werte für die Umgebung bedeuten, dass Sie vermutlich folgende Aktionen ausführen sollten:

  • Überprüfen Sie die Indexgröße jeder Komponente auf dem Server. Stellen Sie sicher, dass ausreichend RAM auf dem Server vorhanden ist, damit ca. 33 Prozent der Summe der Indexgrößen zwischengespeichert werden kann.

  • Überprüfen Sie den E/A-Kanal für Abfragekomponenten auf dem Server. Stellen Sie sicher, dass kein E/A-Engpass vorliegt.

  • Wenn weder E/A noch RAM die Ursache des Leistungsproblems ist, sollten Sie die Abfragekomponenten neu partitionieren (und Indexpartitionen hinzufügen) und dabei die zusätzlichen Abfragekomponenten auf neue Server horizontal skalieren.

Problembehandlung von Problemen mit der Eigenschaftendatenbank

Überprüfen Sie die SQL Server-Integrität unter Verwendung der Konzepte in Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010). Wenn Sie benutzerdefinierte Abfragen ausführen, sollten Sie den Hinweisen zur Optimierung des Abfrageplans nachgehen.

Problembehandlung von Problemen mit der Suchverwaltungsdatenbank

Überprüfen Sie die SQL Server-Integrität unter Verwendung der Konzepte in Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010).

Problembehandlung von Abfrageprozessorproblemen

Die Problembehandlung von Abfrageprozessorproblemen hängt davon ab, welche der folgenden Bereiche des Abfrageprozessors Auswirkungen auf die Abfragewartezeit haben:

• Einschränkung aus Sicherheitsgründen:

  • Überprüfen Sie für Windows-Forderungen die Active Directory-Verbindung vom Server, der den Abfrageprozessor hostet.

  • Generell kann die Cachegröße, die vom Abfrageprozessor verwendet wird, erhöht werden, wenn es einen Zusammenhang mit der hohen Anzahl an SQL Server-Roundtrips gibt (ermittelt von SQL Server Profiler). Bei mehr als 25 Prozent der Abfragen sollte ein SQL Server-Aufruf zum Abrufen von Sicherheitsdeskriptoren aus der Suchverwaltungsdatenbank nicht erforderlich sein. Passen Sie andernfalls die Größe des Abfrageprozessorcaches an.

• Duplikatentfernung:

  • Überprüfen Sie, ob derselbe Inhalt an mehreren Stellen durchforstet wird. Deaktivieren Sie die Duplikaterkennung im Suchcenter.

• Abruf mehrerer Ergebnisse:

  • Überprüfen Sie die SQL Server-Integrität unter Verwendung der Konzepte in Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010).

Browserbasierte Abfrageprobleme

Benutzer können von der Geschwindigkeit von Suchergebnissen entweder begeistert oder verärgert sein. Die Seitenladezeit ist einer der wichtigsten Faktoren für die Zufriedenheit von Benutzern im Hinblick auf das Suchverhalten. Der Hauptschwerpunkt bei der Seitenladezeit liegt auf der Serverseite, vor allem auf der Zeit, die der Server für die Rückgabe der Ergebnisse benötigt. Das clientseitige Rendering stellt jedoch einen wesentlichen Anteil der Seitenladezeit dar und muss berücksichtigt werden.

Das Suchverhalten wurde für Benutzer so konzipiert, dass die Gesamtseitenladezeit unter einer Sekunde liegt. Von dieser Zeitdauer nimmt das Clientrendering in der Regel weniger als 280 Millisekunden in Anspruch, abhängig vom Browser und der Renderingmaßgabe. So kommen Benutzer in den Genuss sehr schneller Ergebnisse.

Anpassungen des Ergebnisverhaltens können leicht zu einer geminderten Leistung beim Rendering führen. Suchadministratoren und Entwickler müssen die Renderingzeit nach jeder Änderung sorgfältig messen, um sicherzustellen, dass die Leistung nicht deutlich zurückgegangen ist. Jede Ergänzung der Seite, von einem neuen Webpart bis zu einem neuen Cascading Stylesheet-Format, steigert die Renderingzeit und verzögert die Ergebnisse für die Benutzer. Die Länge der Verzögerung kann jedoch stark variieren, abhängig davon, ob Sie die optimalen Methoden bei der Anpassung der Seite einhalten.

Es folgen einige allgemeine Richtlinien:

• Durch einfache Branding- und Formatanpassungen der Seite sollten nicht mehr als ca. 25 ms zur Seitenladezeit hinzukommen. Messen Sie die Seitenladezeit vor und nach dem Implementieren von Anpassungen, um die Änderung im Auge zu behalten.

• Benutzer bemerken in der Regel eine Änderung (schneller oder langsamer) bei einer Abweichung von 20 Prozent, daran sollten Sie denken, wenn Sie Änderungen vornehmen. 20 Prozent der Standardrenderingzeit sind nur 50 ms. (Quelle: Designing and Engineering Time)

• Cascading Stylesheets und JScript sind die häufigsten und umfassendsten Ursachen für hohe Anforderungen an das Rendering. Wenn Sie benutzerdefinierte Cascading Stylesheets und JScript verwenden müssen, sollten Sie sicherstellen, dass sie jeweils auf eine Datei beschränkt sind.

• JScript kann bei Bedarf nach dem Rendern der Seite geladen werden, um dem Benutzer schneller sichtbare Ergebnisse bereitzustellen. Details hierzu werden im Artikel mit den Überlegungen zur Leistung erläutert.

• Je mehr Anpassungen zur Seite hinzugefügt werden, desto langsamer wird die Seite geladen. Wägen Sie ab, ob zusätzliche Funktionen und Format die höhere Verzögerung bei der Anzeige der Ergebnisse für die Benutzer Wert sind.

Zusätzlich zu diesen Richtlinien stehen zahlreiche Informationen im Internet zur Senkung der Seitenladezeit und den Auswirkungen von langsamen Seiten auf die Benutzerfreundlichkeit zur Verfügung.

Problembehandlung von Durchforstungsleistungsproblemen

Bei der SharePoint-Suche können Engpässe im Durchforstungsteilsystem auftreten, während das System die Phasen der Indexerfassung, Indexverwaltung und Indexlöschung durchläuft. Für eine erfolgreiche Problembehandlung von Durchforstungsleistungsproblemen sollten die Berichte zur Suchintegritätsüberwachung mit dem Abschnitt "Häufige Engpässe und ihre Ursachen" nachfolgend in diesem Artikel verwendet werden, um Durchforstungsprobleme einzugrenzen.

Problembehandlung während der Phase der Indexerfassung

Der Integritätsbericht zur Durchforstungsrate pro Inhaltsquelle ist die beste Stelle, um Durchforstungsprobleme zu identifizieren. Wie nachfolgend in diesem Artikel dargestellt, enthält dieser Artikel einen Überblick über die Durchforstungsrate jeder einzelnen Inhaltsquelle im System. Im Allgemeinen sollte die Durchforstungsrate mehr als 15 Dokumente/s für Personeninhaltsquellen und mehr als 35 Dokumente/s für alle anderen Typen von Inhaltsquellen betragen.

Wenn eine Inhaltsquelle mit suboptimaler Durchforstungsrate identifiziert wird, werden die folgenden Schritte empfohlen:

1. Halten Sie alle anderen Durchforstungen an mit Ausnahme der Inhaltsquelle, die untersucht wird. Verbessert sich die Durchforstungsrate über das genannte Ziel von 15 bis 35 Dokumenten/s hinaus?

2. Wenn der vorherige Schritt keine Verbesserung bringt, stellen Sie sicher, dass das durchforstete Repository ausreichend reagiert und nicht die Ursache für die langsame Durchforstung ist. Lesen Sie den Abschnitt "Durchforstungsengpass im Repository" weiter oben in diesem Artikel.

3. Wenn das Repository nicht der Engpass ist, identifizieren Sie den Engpass beim Durchforstungsserver oder Datenbankserver, und nehmen Sie Optimierungen in ihrem Kontext vor. Hinweise hierzu können Sie den Abschnitten "IOPS-Engpass der Durchforstungsdatenbank" und "CPU-Thread-Durchforstungsengpass" weiter oben in diesem Artikel entnehmen.

Problembehandlung während der Phase der Indexverwaltung

Das Hauptziel während der Phase der Indexverwaltung liegt darin, den Index so aktuell wie möglich zu erhalten. Zwei der Schlüsselindikatoren hierfür sind folgende:

• Indexaktualität: Werden die Durchforstungen in ihren vorgesehenen Zeiten und in Übereinstimmung mit den IT-Richtlinien für die Indexaktualität beendet?

• Inkrementelle Durchforstungsgeschwindigkeit: Wenn das Ziel der Indexaktualität nicht erreicht wird, untersuchen Sie, ob die inkrementellen Durchforstungsgeschwindigkeiten bei 10 Dokumenten/s für Personeninhaltsquellen und 35 Dokumenten/s für alle sonstigen Inhaltsquellen liegen. Wenn die inkrementellen Durchforstungsgeschwindigkeiten suboptimal sind, sollte eine Engpassanalyse wie oben beschrieben in dem durchforsteten Repository und im Durchforstungsteilsystem durchgeführt werden.

Häufige Engpässe und ihre Ursachen

Während der Leistungstests traten verschiedene Engpässe häufig auf. Ein Engpass ist ein Zustand, bei dem die maximale Kapazität eines bestimmten Bestandteils einer Farm erreicht wird. Dies hat ein Plateau oder eine Abnahme des Durchsatzes der Farm zur Folge.

In der folgenden Tabelle sind einige häufige Engpässe und ihre Ursachen sowie mögliche Lösungen aufgeführt.

Engpass	Symptom (Leistungsindikator)	Lösung
Datenbank-RAM	Eigenschaftendatenbank und Suchverwaltungsdatenbank zeigen Folgendes: SQL Server-Puffer-Manager/Lebenserwartung für Seite < 300(s) (sollte > 1000 (s) betragen) SQL Server-Puffer-Manager/Puffercache-Trefferquote < 96% (sollte > 98% betragen)	Fügen Sie dem Datenbankserver mehr Speicher hinzu. Defragmentieren Sie die Eigenschaftendatenbank, wenn die Regel zur wöchentlichen Defragmentierung deaktiviert wurde. Stellen Sie sicher, dass Sie SQL Server 2008 Enterprise Edition verwenden, und aktivieren Sie die Seitenkomprimierung. Verschieben Sie die Datenbank auf einen getrennten Server, und fügen Sie mehrere Eigenschaftendatenbanken hinzu, falls sie erforderlich sind.
IOPS des Datenbankservers	Eine Eigenschaften- oder Durchforstungsdatenbank zeigt Folgendes: Mittlere Sek./Lesevorgänge und Mittlere Sek./Schreibvorgänge ~50 ms oder > 50 ms	Stellen Sie sicher, dass der Datenbankserver über ausreichend RAM verfügt, damit 33 Prozent der kritischen Tabellen (MSSDocSDIDs, MSSDocProps, MSSDocresults) im Cache aufbewahrt werden können. Erhöhen Sie die dedizierte Zahl der IOPS für die Datenbank durch folgende Aktionen: Verwenden Sie verschiedene Speicherarrays Optimieren Sie die Speicherkonfiguration, beispielsweise durch Hinzufügen von Spindles (Datenträgerlaufwerke) zum Speicherarray. Führen Sie die SharePoint-Integritätsanalyse aus. Mindestens eine Eigenschaftendatenbank weist fragmentierte Indizes auf, wenn sie deaktiviert wurde. Führen Sie die SharePoint-Integritätsanalyse aus. Mindestens eine Durchforstungsdatenbank weist fragmentierte Indizes auf. Stellen Sie sicher, dass Sie SQL Server 2008 Enterprise Edition verwenden, und aktivieren Sie die Seitenkomprimierung. Verschieben Sie die Datenbank auf einen getrennten Server, und fügen Sie, falls erforderlich, mehrere Eigenschaftendatenbanken, Durchforstungsdatenbanken oder beides auf einem getrennten Server hinzu.
IOPS der Abfragekomponente	Der für den Index einer Abfragekomponente verwendete logische Datenträger zeigt Folgendes: Mittlere Sek./Lesevorgänge und Mittlere Sek./Schreibvorgänge ~30 ms oder > 30 ms über einen längeren Zeitraum (d. h. den größten Teil des Tages, nicht nur während einer Indexzusammenführung).	Stellen Sie sicher, dass jeder Anwendungsserver über ausreichend RAM verfügt, damit 33 Prozent des Index jeder aktiven Abfragekomponente (auf diesem Server) im Cache (Betriebssystemcache) verbleiben. Erhöhen Sie die dedizierte Zahl der IOPS für das Laufwerk, das für den Index der Abfragekomponente verwendet wird, wie folgt: Verwenden Sie verschiedene Speicherarrays für verschiedene Komponenten. Optimieren Sie die Speicherkonfiguration, beispielsweise durch Hinzufügen von Spindles (Datenträgerlaufwerke) zum Speicherarray.

Informationen zum Autor

Brion Stone ist Senior Program Manager für die SharePoint Server-Suche bei Microsoft.