Einschätzen der Leistungs- und Kapazitätsanforderungen für Access Services in SharePoint Server 2010
Gilt für: SharePoint Server 2010 Enterprise
Letztes Änderungsdatum des Themas: 2016-11-30
Dieser Artikel enthält Informationen zum Speicherbedarf von Access Services in Microsoft SharePoint Server 2010 für Topologien mit Microsoft SharePoint Server 2010.
Inhalt dieses Artikels:
Testfarmmerkmale
Testergebnisse
Empfehlungen
Problembehandlung
Testfarmmerkmale
In diesem Abschnitt wird Folgendes beschrieben: Das für die Tests verwendete Dataset; die Arbeitsauslastung des Produkts beim Erfassen der Leistungswerte; die für die Tests verwendete Hardware; und die Topologie für die Bereitstellung dieser Hardware.
Dataset
Die Kapazität und Leistung von Access Services hängt wesentlich vom Aufbau der von dem Dienst gehosteten Anwendungen ab. Die Größe von Tabellen und die Komplexität von Abfragen haben oft die stärksten Auswirkungen auf Kapazität und Leistung. Bei den Tests wurden repräsentative Größen und Komplexitäten verwendet, aber jede Anwendung und jedes Dataset ist unterschiedlich. Kapazität und Leistung hängen ab von den verwendeten Anwendungen, deren spezifischer Komplexität und der Datengröße.
Zum Auswerten des Kapazitätsprofils wurden Access Services-Anwendungen in einer dedizierten Access Services-Farm simuliert (es wurden gleichzeitig keine andere SharePoint-Tests ausgeführt). Die Farm enthielt die folgenden repräsentativen Websites:
1.500 Access Services-Anwendungen mit einem kleinen Profil; maximal 100 Elemente pro Liste.
1.500 Access Services-Anwendungen mit einem Profil mittlerer Größe; maximal 2.000 Elemente pro Liste.
1.500 Access Services-Anwendungen mit einem großen Profil; maximal 10.000 Elemente pro Liste.
Jede Anwendung besteht aus mehreren Listen, und die Größe der anderen Listen wird anhand der größten Liste entsprechend festgelegt. Access Services kann mehr als 10.000 Elemente verarbeiten. Dieser Wert für das große Profil wurde gewählt, weil davon ausgegangen wurde, dass normalerweise keine größeren Anwendungen verwendet werden.
Die Anwendungen wurden gleichmäßig auf die folgenden Anwendungen verteilt:
Contacts Eine einfache Kontaktverwaltungsanwendung mit einer einzelnen Liste.
Projects Eine einfache Anwendung zum Nachverfolgen von Aufgaben und Projekten mit zwei Listen (die den einzelnen Projekten zugeordneten Projekte und Aufgaben).
Orders Ein einfaches Auftragserfassungssystem, ähnlich wie im Northwind Traders-Beispiel für Microsoft Access, jedoch weniger komplex, und mit vielen miteinander verknüpften Listen (Aufträge, Bestelldetails, Rechnungen, Rechnungsdetails, Bestellungen, Bestellungsdetails usw.).
Arbeitsauslastung
Zur Simulation der Anwendungsverwendung wurden Arbeitsauslastungen erstellt, um einen oder mehrere der folgenden Vorgänge auszuführen:
Öffnen von Formularen
Blättern in den Formularen
Filtern und Sortieren von Datenblättern
Aktualisieren, Löschen und Einfügen von Datensätzen
Veröffentlichen der Anwendung
Rendern von Berichten
Jede Arbeitsauslastung beinhaltet 5 bis 20 Sekunden "Reaktionszeit" zwischen Benutzeraktionen. Dies stellt einen Unterschied zu anderen SharePoint-Kapazitätsplanungsdokumenten dar. Access Services ist zustandsbehaftet; Arbeitsspeichercursor und Datensätze wurden zwischen Benutzerinteraktionen verwaltet. Es musste unbedingt eine vollständige Benutzersitzung simuliert werden, und nicht nur einzelne Anforderungen. Pro Benutzerarbeitsauslastung gibt es durchschnittlich zwei Anforderungen pro Sekunde.
In der folgenden Tabelle sind die Prozentsätze dargestellt, anhand derer bestimmt wird, welche Anwendung und welche Anwendungsgröße verwendet werden sollen.
| Klein | Mittel | Groß | |
|---|---|---|---|
Contacts |
16 % |
10 % |
9 % |
Projects |
18 % |
12 % |
10 % |
Orders |
11 % |
8 % |
6 % |
Definitionen für den grünen Bereich und den roten Bereich
Für jede Konfiguration wurden zwei Tests ausgeführt, um einen "grünen Bereichen" und einen "roten Bereich" zu bestimmen. Der grüne Bereich ist der empfohlene Durchsatz, der aufrechterhalten werden kann. Der rote Bereich ist der maximale Durchsatz, der für kurze Zeit toleriert werden kann, aber vermieden werden sollte.
Der grüne Bereich wurde als der Punkt definiert, an dem der ausgeführte Test maximal die Hälfte der Engpassressource verbraucht. In diesem Fall war die Engpassressource die prozentuale CPU-Auslastung auf einer der folgenden drei Ebenen: Front-End-Webserver, Anwendungsserver (Access Data Services) oder Datenbankserver (SQL Server). Zunächst wurde der Engpass für eine bestimmte Konfiguration identifiziert. Wenn die CPU für Access Data Services den Engpass darstellte, stellten wir sicher, dass der Test für den grünen Bereich auf den Computern mit Access Data Services die CPU zu 40 bis 50 % belegt.
Für den roten Bereich wurde ein Punkt ausgewählt, an dem der maximale Durchsatz erreicht wurde. Dies erwies sich als CPU-Bereich zwischen 80 und 90 %. Bei der Suche nach einem Engpass analysierten wir die prozentuale CPU-Auslastung, die Speicherauslastung (private Bytes), die Länge der Datenträgerwarteschlange, Netzwerk-E/A sowie andere Ressourcen, die zu einem Engpass führen könnten.
Die Tests für den grünen Bereich und den roten Bereich wurden eine Stunde lang mit einer festgelegten Benutzerauslastung ausgeführt.
Ihre Ergebnisse können abweichen
Die in diesem Artikel genannten spezifischen Kapazitäts- und Leistungsangaben weichen von den Werten in tatsächlichen Umgebungen ab. Diese Simulation ist lediglich eine Schätzung für die Aktionen realer Benutzer. Die hier dargestellten Werte sollen einen Ausgangspunkt für die Entwicklung einer ordnungsgemäß skalierten Umgebung bilden. Nachdem Sie den ersten Systementwurf erstellt haben, sollten Sie die Konfiguration testen, um zu ermitteln, ob sie die Faktoren in Ihrer Umgebung unterstützt.
Hardwareeinstellungen und -topologie
Laborhardware
Zum Erzielen eines hohen Maßes an detaillierten Testergebnissen wurden verschiedene Farmkonfigurationen für die Tests verwendet. Die Farmkonfigurationen reichten von einem bis zu vier Front-End-Webservern, einem bis vier Anwendungsservern (falls Access Services oder Access Data Services vorhanden ist) und einem einzelnen Datenbankserver, auf dem Microsoft SQL Server 2008 ausgeführt wird. Darüber hinaus wurden die Tests mithilfe von vier Clientcomputern ausgeführt. Auf allen Servercomputern wurde 64-Bit-Software ausgeführt. Auf allen Clientcomputern wurde 32-Bit-Software ausgeführt.
In der folgenden Tabelle ist die jeweilige Hardware für die Tests aufgelistet.
| Computerfunktion | CPU | Arbeitsspeicher | Netzwerk | Festplatte |
|---|---|---|---|---|
Front-End-Webserver |
2 Prozessoren, Quad-Core mit 2,33 GHz |
8 GB |
1 GB |
2 Spindles RAID 5 |
Anwendungsserver (Access Data Services) |
2 Prozessoren, Quad-Core mit 2,33 GHz |
8 GB |
1 GB |
2 Spindles RAID 5 |
Datenbankserver (SQL Server) |
4 Prozessoren, Quad-Core mit 2,6 GHz |
32 GB |
1 GB |
Direct Attached Storage (DAS) RAID 0 für jede logische Gerätnummer (Logical Unit Number, LUN) |
Topologie
Unserer Erfahrung nach ist CPU auf der Anwendungsserverebene, auf der Access Data Services ausgeführt wird, ein wichtiger Begrenzungsfaktor für den Durchsatz. Wir haben unsere Topologie durch Hinzufügen zusätzlicher Computer mit Access Data Services so lange variiert, bis dies keinen Engpass mehr darstellte, und anschließend haben wir einen Front-End-Webserver für sogar noch mehr Durchsatz hinzugefügt.
1x1: Ein Front-End-Webservercomputer und ein Computer mit Access Data Services
1x2: Ein Front-End-Webservercomputer und zwei Computer mit Access Data Services
1x3: Ein Front-End-Webservercomputer und drei Computer mit Access Data Services
1x4: Ein Front-End-Webservercomputer und vier Computer mit Access Data Services
2x1: Zwei Front-End-Webservercomputer und ein Computer mit Access Data Services
2x2: Zwei Front-End-Webservercomputer und zwei Computer mit Access Data Services
2x4: Zwei Front-End-Webservercomputer und vier Computer mit Access Data Services
Der Computer mit SQL Server ist ein relativ leistungsstarker Computer und stellte zu keinem Zeitpunkt einen Engpass dar (obwohl er sich bei unserem 2x4-Test der CPU-Überlastung annäherte), weshalb wir diesen Faktor bei unseren Topologien nicht variiert haben. In Abhängigkeit von den Abfragen, die Bestandteil des Anwendungsbestands in einer echten Umgebung sind, wird erwartet, dass die Datenbankserver (SQL Server) zu einem Engpass werden könnte.
Reporting Services wurde im verbundenen Modus für alle unsere Tests auf der Anwendungsserverebene (Access Data Services) ausgeführt.
Testergebnisse
Die folgenden Tabellen enthalten die Testergebnisse für Access Services. Bei jeder Testgruppe wurden nur bestimmte Variablen geändert, um die Auswirkungen auf die Farmleistung schrittweise darzulegen.
Alle in diesem Artikel beschriebenen Tests wurden mit Reaktionszeit bzw. Wartezeit durchgeführt. Dies stellt einen Unterschied zu den Kapazitätsplanungsergebnissen für andere SharePoint-Bereiche dar.
Weitere Information zu Engpässen bei Access Services finden Sie unter Häufige Engpässe und ihre Ursachen weiter unten in diesem Artikel.
Allgemeine Auswirkungen
In der folgenden Tabelle und im folgenden Diagramm finden Sie eine Übersicht, wie sich das Hinzufügen zusätzlicher Front-End-Webserver und dedizierter Computer mit Access Data Services zur Farm auswirkt. Diese Durchsatzwerte gelten speziell für die Computer mit Access Data Services. Die Auswirkungen auf die Farm insgesamt lassen sich daran nicht ablesen.
| Topologie | Basislösung – Maximale Anzahl von Anforderungen pro Sekunde | Basislösung – empfohlene Anzahl von Anforderungen pro Sekunde |
|---|---|---|
1x1 |
25 |
15 |
1x2 |
54 |
29 |
1x3 |
82 |
45 |
1x4 |
88 |
48 |
2x1 |
25 |
15 |
2x2 |
55 |
29 |
2x4 |
116 |
58 |
.gif "Maximale und empfohlene RPS")
Empfohlene Ergebnisse
Im folgenden Diagramm sind die Ergebnisse für den empfohlenen kontinuierlichen Durchsatz aufgeführt.
.gif "Durchsatz im Vergleich zu ADS")
Wie weiter oben in diesem Artikel beschrieben, wird durch das Hinzufügen des vierten Computers mit Access Data Services der Engpass auf den Front-End-Webserver verlagert, und durch das Hinzufügen eines zweiten Front-End-Webservers wird die Ressourceneinschränkung auf der Front-End-Webserverebene behoben. Dies würde bedeuten, dass 1x1, 1x2 und 1x3 vernünftige Konfigurationen sind. Wenn jedoch der vierte Computer mit Access Data Services hinzugefügt wird, sollte auch ein Front-End-Webserver hinzugefügt werden. Da die Skalierung linear erfolgt (linear von 1x1 bis 1x4), kann davon ausgegangen werden, dass durch das Hinzufügen eines siebten Computers mit Access Data Services auch ein dritter Front-End-Webserver hinzugefügt werden sollte, usw., um die Anforderungen der Farm zu erfüllen.
Beachten Sie, dass diese Ergebnisse lediglich auf einer simulierten Arbeitsauslastung basieren und dass eine tatsächliche Bereitstellung überwacht werden sollte, um nach dem Punkt zu suchen, an dem zusätzliche Front-End-Webserver zur Unterstützung zusätzlicher Computer mit Access Data Services erforderlich sind. Darüber hinaus werden die Front-End-Webserver ausschließlich für Access Services verwendet. In der Realität werden die Front-End-Webserver wahrscheinlich gemeinsam mit anderen SharePoint-Arbeitsauslastungen verwendet. Die Ergebnisse sind im folgenden Diagramm dargestellt.
.gif "Antwortzeit im Vergleich zu ADS")
Im folgenden Diagramm ist die Antwortzeit auf dieser Durchsatzebene dargestellt. Die Antwortzeit ist mit durchschnittlich ¼ Sekunde pro Anforderung sehr schnell.
.gif "SQL %CPU im Vergleich zu ADS")
Diese Ergebnisse zeigen, dass der Computer mit SQL Server keinen Engpass darstellte, da durch das Hinzufügen eines zweiten Front-End-Webservers der Ressourcenmangel behoben wurde, und der Wert der CPU für SQL Server CPU lag stets unter 50 %. Sie sollten jedoch beachten, dass die SQL Server-Instanz gemeinsam mit anderen SharePoint-Diensten und SharePoint selbst verwendet wird, sodass durch den kumulierten Effekt die Werte für die CPU oder die Länge der Datenträger-E/A-Warteschlange steigen und zu einem Engpass werden könnten.
Maximum
Im folgenden Diagramm sind die Ergebnisse dargestellt, bei denen der Durchsatz über den unterstützten Wert hinaus anstieg.
In diesem Diagramm ist ersichtlich, dass wiederum ein zweiter Front-End-Webserver erforderlich war, um den vierten Computer mit Access Data Services maximal zu nutzen. Ihre Ergebnisse können wiederum davon abweichen, da dies in starkem Maß von den Anwendungen und deren Verwendungsmustern abhängt.
.gif "Durchsatz im Vergleich zu ADS")
In diesem Fall nimmt die Antwortzeit zu, da das gesamte System stark ausgelastet ist. Diese Werte betragen jedoch etwa eine Sekunde und sind für die meisten Benutzer akzeptabel.
Es mag seltsam erscheinen, dass mit vier Computern mit Access Data Services zwei Front-End-Webserver ein längere Antwortzeit als ein Front-End-Webserver aufweisen. Dies ist darauf zurückzuführen, dass der Gesamtdurchsatz des Systems bei zwei Front-End-Webservern zunimmt.
SQL Server ist wiederum kein Begrenzungsfaktor, da durch das Hinzufügen des zweiten Front-End-Webservers wieder die lineare Skalierung ermöglicht wird. Allerdings werden für die SQL Server-Instanz fast 90 % CPU-Auslastung erreicht. Deshalb bleibt sehr wenig Toleranzbereich. Falls wir einen fünften Computer mit Access Data Services hinzufügen würden, würde der Computer mit SQL Server wahrscheinlich zu einem Engpass werden.
.gif "SQL %CPU im Vergleich zu ADS")
Ausführliche Ergebnisse
Die folgenden Tabellen enthalten ausführliche Ergebnisse für die empfohlenen Konfigurationen.
| Insgesamt | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
Anforderungen/Sek. |
14,96 |
28,76 |
45,22 |
48,01 |
14,85 |
28,77 |
58,02 |
Tests/Sek. |
2,00 |
3,81 |
6,11 |
6,42 |
1,99 |
3,81 |
7,80 |
Durchschnittliche Wartezeit |
235,80 |
241,21 |
247,21 |
244,87 |
240,70 |
242,26 |
250,94 |
| Durchschnittliche Front-End-Webserver-Ebene | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% CPU |
13,82 |
24,40 |
41,02 |
43,62 |
6,31 |
12,48 |
26,18 |
Maximale Anzahl privater w3wp-Bytes |
9.46E+08 |
2.31E+08 |
1.49E+09 |
1.55E+09 |
8.43E+08 |
9.84E+08 |
1.19E+09 |
| Durchschnittliche Anwendungsserverebene (Access Data Services) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% CPU |
46,30 |
42,83 |
43,74 |
34,51 |
46,56 |
43,45 |
42,13 |
% CPU w3wp |
33,61 |
31,15 |
30,71 |
24,29 |
33,48 |
31,64 |
29,72 |
% CPU RS |
8,62 |
7,94 |
9,17 |
6,84 |
9,03 |
8,02 |
8,71 |
Maximale Gesamtanzahl privater w3wp-Bytes |
4.80E+09 |
4.89E+09 |
4.91E+09 |
4.62E+09 |
5.32E+09 |
4.82E+09 |
5.07E+09 |
Maximale Anzahl privater w3wp-Bytes |
2.10E+09 |
1.97E+09 |
2.04E+09 |
1.86E+09 |
2.00E+09 |
2.00E+09 |
2.07E+09 |
Maximale Anzahl privater RS-Bytes |
1.78E+09 |
2.00E+09 |
1.97E+09 |
1.86E+09 |
2.30E+09 |
1.89E+09 |
2.02E+09 |
| Datenbankserverebene (SQL Server) (einzelner Computer) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% CPU |
12,07 |
18,64 |
32,53 |
36,05 |
9,89 |
21,42 |
47,46 |
Durchschnittliche Anzahl privater Bytes |
2.96E+10 |
3.22E+10 |
3.25E+10 |
3.25E+10 |
2.89E+10 |
3.22E+10 |
3.25E+10 |
Maximale Anzahl privater Bytes |
3.26E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
Durchschnittliche Gesamtwarteschlangenlänge des Datenträgers |
0,74 |
1,18 |
1,64 |
1,77 |
0,67 |
1,24 |
2,18 |
Die folgenden Tabellen enthalten ausführliche Ergebnisse für die maximalen Konfigurationen.
| Insgesamt | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
Anforderungen/Sek. |
14,96 |
28,76 |
45,22 |
48,01 |
14,85 |
28,77 |
58,02 |
Tests/Sek. |
2,00 |
3,81 |
6,11 |
6,42 |
1,99 |
3,81 |
7,80 |
Durchschnittliche Wartezeit |
235,80 |
241,21 |
247,21 |
244,87 |
240,70 |
242,26 |
250,94 |
| Durchschnittliche Front-End-Webserver-Ebene | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% CPU |
13,82 |
24,40 |
41,02 |
43,62 |
6,31 |
12,48 |
26,18 |
Maximale Anzahl privater w3wp-Bytes |
9.46E+08 |
2.31E+08 |
1.49E+09 |
1.55E+09 |
8.43E+08 |
9.84E+08 |
1.19E+09 |
| Durchschnittliche Anwendungsserverebene (Access Data Services) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% CPU |
46,30 |
42,83 |
43,74 |
34,51 |
46,56 |
43,45 |
42,13 |
% CPU w3wp |
33,61 |
31,15 |
30,71 |
24,29 |
33,48 |
31,64 |
29,72 |
% CPU RS |
8,62 |
7,94 |
9,17 |
6,84 |
9,03 |
8,02 |
8,71 |
Maximale Gesamtanzahl privater w3wp-Bytes |
4.80E+09 |
4.89E+09 |
4.91E+09 |
4.62E+09 |
5.32E+09 |
4.82E+09 |
5.07E+09 |
Maximale Anzahl privater w3wp-Bytes |
2.10E+09 |
1.97E+09 |
2.04E+09 |
1.86E+09 |
2.00E+09 |
2.00E+09 |
2.07E+09 |
Maximale Anzahl privater RS-Bytes |
1.78E+09 |
2.00E+09 |
1.97E+09 |
1.86E+09 |
2.30E+09 |
1.89E+09 |
2.02E+09 |
| Datenbankserverebene (SQL Server) (einzelner Computer) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% CPU |
12,07 |
18,64 |
32,53 |
36,05 |
9,89 |
21,42 |
47,46 |
Durchschnittliche Anzahl privater Bytes |
2.96E+10 |
3.22E+10 |
3.25E+10 |
3.25E+10 |
2.89E+10 |
3.22E+10 |
3.25E+10 |
Maximale Anzahl privater Bytes |
3.26E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
3.25E+10 |
Durchschnittliche Gesamtwarteschlangenlänge des Datenträgers |
0,74 |
1,18 |
1,64 |
1,77 |
0,67 |
1,24 |
2,18 |
Empfehlungen
In diesem Abschnitt finden Sie allgemeine Empfehlungen zu Leistung und Kapazität.
Die Kapazität und Leistung von Access Services hängt wesentlich vom Aufbau der von dem Dienst gehosteten Anwendungen ab. Die Größe von Tabellen und die Komplexität von Abfragen haben oft die stärksten Auswirkungen. Bei den Tests wurden repräsentative Größen und Komplexitäten verwendet, aber jede Anwendung und jedes Dataset ist unterschiedlich. Kapazität und Leistung hängen deshalb ab von den verwendeten Anwendungen, deren spezifischer Komplexität und der Datengröße.
Hardwareempfehlungen
Access Services verwendet Standardhardware sowohl für Front-End-Webserver als auch für Anwendungsserver. Es sind keine speziellen Anforderungen notwendig. Allgemeine SharePoint Server 2010-Richtlinien für CPU-Anzahl, Geschwindigkeit und Arbeitsspeicher gelten für Computer der Anwendungsserverebene (Access Data Services).
Vertikal und horizontal skalierte Topologien
Für die Steigerung von Kapazität und Leistung einer der Ausgangstopologien gibt es zwei Möglichkeiten. Sie können entweder vertikal skalieren, indem Sie die Kapazität der vorhandenen Server steigern, oder aber horizontal skalieren, indem Sie der Topologie zusätzliche Server hinzufügen. In diesem Abschnitt werden die allgemeinen Leistungsmerkmale mehrerer horizontal skalierter Topologien beschrieben.
Die Beispieltopologien veranschaulichen die folgenden gängigen Methoden, um eine Topologie für ein Access Services-Szenario horizontal zu skalieren:
Um eine höhere Benutzerauslastung zu ermöglichen, überprüfen Sie die CPU für die vorhandenen Anwendungsserver mit Access Services. Fügen Sie diesen Servern nach Möglichkeit zusätzliche CPUs und/oder Prozessorkerne hinzu. Fügen Sie bei Bedarf weitere Servercomputer mit Access Services hinzu. An dem Punkt, an dem der Front-End-Webserver einen Engpass darstellt, können Sie dann nach Bedarf Front-End-Webserver hinzufügen.
Bei unseren Tests stellte der Arbeitsspeicher auf der Front-End-Webserverebene und der Anwendungsserverebene (Access Data Services) keinen Engpass dar. In Abhängigkeit von der Größe der Resultsets könnte der Arbeitsspeicher zu einem Problem werden. Wir gehen jedoch davon aus, dass dies in der Regel nicht der Fall sein wird. Verfolgen Sie die privaten Bytes für den w3wp-Prozess von Access Data Services wie hier beschrieben nach.
Bei unseren Tests stellte SQL Server keinen Engpass dar. Allerdings wurden diese Tests isoliert von anderen SharePoint Server 2010-Diensten ausgeführt. CPU und Datenträger-E/A für SQL Server sollten überwacht und zusätzliche Server oder Spindles bei Bedarf hinzugefügt werden.
Leistungsbezogene Access Services-Einstellungen
Durch das Begrenzen der Größe und Komplexität von Abfragen, die ausgeführt werden können, können die Leistungsmerkmale von Access Services kontrolliert werden. In Access Services gibt es eine Reihe konfigurierbarer Steuerungsgrenzwerte zum Kontrollieren von Abfragen. Die folgenden Abfragen können über die SharePoint-Zentraladministration festgelegt werden. (Klicken Sie dazu im Abschnitt Anwendungsverwaltung auf Dienstanwendungen verwalten, und klicken Sie dann auf Access Services.)
Im Allgemeinen hat der Umfang der Daten, die von SharePoint zum Ausführen einer Abfrage abgerufen werden müssen, erhebliche Auswirkungen auf die Leistung. Es gibt mehrere Methoden, um dies zu kontrollieren. Zum einen können die Eingaben für eine Abfrage mithilfe der folgenden Optionen begrenzt werden:
Maximale Anzahl der Quellen pro Abfrage
Maximale Anzahl Datensätze pro Tabelle
Zum anderen kann die resultierende Größe einer Abfrage mithilfe der folgenden Optionen begrenzt werden:
Maximale Anzahl der Spalten pro Abfrage
Maximale Anzahl der Zeilen pro Abfrage
Äußere Verknüpfungen zulassen
Neben der Abfragegröße (ein- und ausgehende Datengröße) kann die Verarbeitungskomplexität der Daten mithilfe der folgenden Optionen gesteuert werden, um die CPU-Auslastung für die Anwendungsserverebene (Access Data Services) zu reduzieren:
Maximale Anzahl der berechneten Spalten pro Abfrage
Maximale Anzahl der ORDER BY-Klauseln pro Abfrage
Die vorherigen Einstellungen betreffen ganz offensichtlich die Anwendungen, die auf dem Server ausgeführt werden können. Wenn beispielsweise eine Anwendung mit 40 Ausgabespalten in einer Abfrage geschrieben wird und die Einstellungen einen niedrigeren Wert aufweisen, wird von der Anwendung ein Laufzeitfehler ausgelöst. Ein Gleichgewicht zwischen Benutzeranforderungen und akzeptabler Leistung muss erreicht werden und ist in hohem Maß abhängig von der Art der Access-Anwendungen, die voraussichtlich in der Farm ausgeführt werden.
Eine weitere, extremere Maßnahme ist möglich. SharePoint Server 2010 bietet die systemeigene Unterstützung einer Reihe von Abfragevorgängen, wodurch Access Services für ein breiteres Spektrum an Anwendungsszenarien verwendet werden kann. Um SharePoint-Abfragen für Access Services zu optimieren, kann es sein, dass große Datenmengen aus der SharePoint-Inhaltsdatenbank abgerufen werden müssen. Stattdessen kann Access Services auf Abfragevorgänge beschränkt werden, die von SharePoint systemeigen unterstützt werden. Dadurch wird mithilfe der folgenden Option das Abrufen von Daten für komplexere Vorgänge vermieden:
- Nicht remotefähige Abfragen zulassen
Optimierungen
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 Tabelle im Abschnitt Problembehandlung weiter unten sind einige häufige Engpässe und deren Ursachen sowie mögliche Lösungen aufgeführt.
Leistungsüberwachung
Verwenden Sie Leistungsindikatoren zur Überwachung der Integrität eines Systems, um den richtigen Zeitpunkt für eine vertikale oder horizontale Skalierung des Systems zu bestimmen. Nutzen Sie die Informationen in den folgenden Tabellen, um zusätzliche zu überwachende Leistungsindikatoren zu ermitteln und festzustellen, auf welchen Prozess die Leistungsindikatoren angewendet werden sollten.
Front-End-Webserver
Die folgende Tabelle enthält Leistungsindikatoren und Prozesse zum Überwachen von Webservern in einer Farm.
| Leistungsindikator | Betreffende Objekte | Hinweise |
|---|---|---|
Prozessorzeit (%) |
Processor(_Total) |
Zeigt den Prozentsatz der verstrichenen Zeit, den dieser Thread den Prozessor zum Ausführen von Anweisungen genutzt hat. |
Private Bytes |
Process(w3wp) |
Dieser Wert sollte sich nicht dem Wert von Maximale Anzahl privater Bytes annähern, der für w3wp-Prozesse festgelegt ist. Andernfalls sind zusätzliche Analysen erforderlich, von welcher Komponente der Arbeitsspeicher verwendet wird. |
Access Data Services
Die folgende Tabelle enthält Leistungsindikatoren und Prozesse zum Überwachen von Anwendungsservern, oder Access Data Services in diesem Fall, in einer Farm.
| Leistungsindikator | Betreffende Objekte | Hinweise |
|---|---|---|
Prozessorzeit (%) |
Processor(_Total) |
Zeigt den Prozentsatz der verstrichenen Zeit, den dieser Thread den Prozessor zum Ausführen von Anweisungen genutzt hat. |
Prozessorzeit (%) |
Process(w3wp) |
Access Data Services wird in einem eigenen w2wp-Prozess ausgeführt, und es ist erkenntlich, um welchen w2wp-Prozess es sich handelt, da ihm der Großteil der CPU-Zeit zugeteilt wird. |
Durchschnittl. Warteschlangenlänge des Datenträgers |
PhysicalDisk(_Total) |
Achten Sie auf dem Datenträger auf extrem viele Schreibvorgänge aufgrund der Protokollierung. |
Prozessorzeit (%) |
Process(ReportingServicesService) |
Berichte werden von SQL Server Reporting Services verarbeitet. Falls zu viele Berichte ausgeführt werden oder die Berichte sehr komplex sind, weisen die CPU und die privaten Bytes für diesen Prozess hohe Werte auf. |
Private Bytes |
Process(w3wp) |
Die Ergebnisse von Abfragen werden von Access Services im Arbeitsspeicher zwischengespeichert, bis die Benutzersitzung abgelaufen ist (der Timeout hierfür ist konfigurierbar). Falls große Datenmengen durch Access Data Services verarbeitet werden, nimmt die Arbeitsspeicherauslastung für den w3wp-Prozess von Access Data Services zu. |
Private Bytes |
Process(ReportingServicesService) |
Berichte werden von SQL Server Reporting Services verarbeitet. Falls zu viele Berichte ausgeführt werden oder die Berichte sehr komplex sind, weisen die CPU und die privaten Bytes für diesen Prozess hohe Werte auf. |
Datenbankserver
Die folgende Tabelle enthält Leistungsindikatoren und Prozesse zum Überwachen von Datenbankservern in einer Farm.
| Leistungsindikator | Betreffende Objekte | Hinweise |
|---|---|---|
Prozessorzeit (%) |
Processor(_Total) |
Zeigt den Prozentsatz der verstrichenen Zeit, den dieser Thread den Prozessor zum Ausführen von Anweisungen genutzt hat. |
Prozessorzeit (%) |
Process(sqlservr) |
Durchschnittswerte größer als 80 % bedeuten, dass die Prozessorkapazität des Datenbankservers unzureichend ist. |
Private Bytes |
Process(sqlservr) |
Zeigt an, wie viel Arbeitsspeicher durchschnittlich von SQL Server verbraucht wird. |
Durchschnittl. Warteschlangenlänge des Datenträgers |
PhysicalDisk(_Total) |
Zeigt die durchschnittliche Warteschlangenlänge des Datenträgers an, also die Datenbankanforderungen, die auf ein Commit warten. Dies ist oft ein guter Indikator dafür, dass die SQL Server-Instanz überlastet ist und dass durch zusätzliche Datenträger-Spindles die Auslastung möglicherweise verteilt werden könnte. |
Problembehandlung
In der folgenden Tabelle sind einige häufige Engpässe und ihre Ursachen sowie mögliche Lösungen aufgeführt.
| Engpass | Ursache | Lösung |
|---|---|---|
CPU für Access Data Services |
Access Services ist auf einen großen Umfang an Verarbeitungen auf der Anwendungsserverebene angewiesen. Falls eine 1x1-, 1x2- oder 1x3-Konfiguration verwendet wird, ist der erste auftretende Engpass wahrscheinlich die CPU auf den Servern mit Access Data Services. |
Erhöhen Sie die Anzahl von CPUs und/oder Prozessorkernen auf den vorhandenen Computern mit Access Data Services. Fügen Sie nach Möglichkeit zusätzliche Computer mit Access Data Services hinzu. |
Webserver-CPU-Auslastung |
Wenn ein Webserver mit Benutzeranforderungen überlastet ist, erreicht die durchschnittliche CPU-Auslastung nahezu 100 %. Dies hindert den Webserver an der schnellen Reaktion auf Anforderungen und kann auf Clientcomputern zu Timeouts und Fehlermeldungen führen. |
Es gibt zwei Möglichkeiten, dieses Problem zu beheben. Sie können zum Verteilen der Benutzerauslastung der Farm weitere Webserver hinzufügen oder den Webserver durch Hinzufügen schnellerer Prozessoren vertikal skalieren. |
Datenträger-E/A auf dem Datenbankserver |
Wenn die Anzahl der E/A-Anforderungen an die Festplatte deren Kapazität übersteigt, werden Anforderungen in Warteschlangen gestellt. Dadurch verlängert sich die Ausführung der einzelnen Anforderungen. |
Das Verteilen von Datendateien auf mehrere physische Laufwerke ermöglicht eine parallele E/A. Der englischsprachige Blog SharePoint Disk Allocation and Disk I/O (https://go.microsoft.com/fwlink/?linkid=129557&clcid=0x407) enthält nützliche Informationen zum Beheben von Problemen mit der Datenträger-E/A. |
CPU-Auslastung von Reporting Services |
Der Reporting Services-Prozess belegt einen Großteil der CPU-Ressourcen. |
Reservieren Sie einen Computer für Reporting Services, um die Auslastung auf der Anwendungsserverebene (Access Data Services) (verbundener Modus) oder auf der Front-End-Webserverebene (lokaler Modus) zu reduzieren. |