(0) exportieren Drucken
Alle erweitern

Schätzen der Leistungs- und Kapazitätsanforderungen für PerformancePoint-Dienste

SharePoint 2010

Veröffentlicht: 09. September 2010

In diesem Artikel werden die Auswirkungen durch die Verwendung von PerformancePoint Services auf Topologien beschrieben, auf denen Microsoft SharePoint Server 2010 ausgeführt wird.

Ff955652.note(de-de,office.14).gifHinweis:

Dabei sollten Sie beachten, dass die in diesem Artikel genannten spezifischen Kapazitäts- und Leistungsangaben von den Werten in tatsächlichen Umgebungen abweichen. Die hier dargestellten Werte sollen einen Ausgangspunkt für die Entwicklung einer korrekt skalierten Umgebung bilden. Nachdem Sie Ihren ersten Systementwurf erstellt haben, testen Sie die Konfiguration, um zu ermitteln, ob das System die Faktoren in Ihrer Umgebung unterstützt.

Inhalt dieses Artikels

Allgemeine Informationen zur Durchführung der Kapazitätsplanung für SharePoint Server 2010 finden Sie unter Capacity management and sizing for SharePoint Server 2010.

Testfarmmerkmale

Dataset

Das Dataset setzte sich aus einem Firmenportal zusammen, das mithilfe von SharePoint Server 2010 und PerformancePoint Services mit einem einzelnen Dashboard mittlerer Größe erstellt wurde. Das Dashboard enthielt zwei Filter, die mit einer Scorecard, zwei Diagrammen und einem Raster verbunden waren. Das Dashboard basierte auf einer einzelnen Microsoft SQL Server 2008 Analysis Services (SSAS)-Datenquelle, die die AdventureWorks-Beispieldatenbanken als SQL Server 2008 Analysis Services-Cube verwendeten.

In der nachfolgenden Tabelle werden der Typ und die Größe der einzelnen Elemente des Dashboards beschrieben.

Name Beschreibung Größe

Filter 1

Elementauswahlfilter

7 Dimensionselemente

Filter 2

Elementauswahlfilter

20 Dimensionselemente

Scorecard

Scorecard

15 Dimensionselementzeilen x 4 Spalten (2 KPIs)

Diagramm 1

Liniendiagramm

3 Datenreihen x 12 Spalten

Diagramm 2

Gestapeltes Balkendiagramm

37 Datenreihen x 3 Spalten

Raster

Analyseraster

5 Zeilen x 3 Spalten

Für das Dashboard mittlerer Größe wurde die Vorlage Kopfzeile und zwei Spalten verwendet. Die Dashboardelementgrößen wurden entweder automatisch festgelegt oder als bestimmter Prozentwert des Dashboards. Jedes Element auf dem Dashboard wurde mit einer Zufallshöhe und -breite zwischen 400 und 500 Pixel dargestellt, um die unterschiedlichen Größen von Webbrowserfenstern zu simulieren. Die Änderung der Höhe und Breite der einzelnen Dashboardelemente ist wichtig, da Diagramme auf der Grundlage der Größe der Webbrowserfenster dargestellt werden.

Testszenarien und Prozesse

In diesem Abschnitt werden die Testszenarien definiert und der jeweilige Testprozess für jedes Szenario erläutert. Ausführliche Informationen wie Testergebnisse und spezifische Parameter sind nachfolgend in diesem Artikel in den Abschnitten Testergebnisse aufgeführt.

Testname Testbeschreibung

Rendern eines Dashboards und fünfmaliges zufälliges Ändern eines der beiden Filter mit einer Pause von 15 Sekunden zwischen Interaktionen.

  1. Rendern des Dashboards.

  2. Auswählen eines der beiden Filter und zufälliges Auswählen eines Filterwerts sowie Warten, bis das Dashboard erneut gerendert wird.

  3. Vier weitere Wiederholungen bei zufälliger Auswahl eines der beiden Filter und eines zufälligen Filterwerts.

Rendern eines Dashboards, Auswählen eines Diagramms und fünfmaliges Erweitern und Reduzieren mit einer Pause von 15 Sekunden zwischen Interaktionen.

  1. Rendern des Dashboards.

  2. Auswählen eines zufälligen Elements in einem Diagramm und dieses erweitern.

  3. Auswählen eines anderen zufälligen Elements im Diagramm und dieses reduzieren.

  4. Auswählen eines anderen zufälligen Elements im Diagramm und dieses erweitern.

  5. Auswählen eines anderen zufälligen Elements im Diagramm und dieses reduzieren.

Rendern eines Dashboards, Auswählen eines Rasters und fünfmaliges Erweitern und Reduzieren mit einer Pause von 15 Sekunden zwischen Interaktionen.

  1. Rendern des Dashboards. Auswählen eines zufälligen Elements in einem Raster und Erweitern des Elements.

  2. Auswählen eines anderen zufälligen Elements im Raster und dieses erweitern.

  3. Auswählen eines anderen zufälligen Elements im Raster und dieses reduzieren.

  4. Auswählen eines anderen zufälligen Elements im Raster und dieses erweitern.

Es wurde eine einzelne Testmischung bestehend aus den folgenden Prozentwerten gestarteter Tests angewendet.

Testname Testmischung

Rendern eines Dashboards und fünfmaliges zufälliges Ändern eines der beiden Filter.

80%

Rendern eines Dashboards, Auswählen eines Diagramms und fünfmaliges Erweitern sowie Reduzieren.

10%

Rendern eines Dashboards, Auswählen eines Rasters und fünfmaliges Erweitern sowie Reduzieren.

10%

Die Microsoft Visual Studio 2008 Load Testing-Tools wurden zum Erstellen einer Reihe von Webtests und Auslastungstests verwendet, bei denen Benutzer simuliert wurden, die Filter zufällig ändern und in Rastern und Diagrammen navigieren. Bei den in diesem Artikel verwendeten Tests wurde eine normale Verteilung von 15 sekündigen Pausen, so genannten "Reaktionszeiten" zwischen Interaktionen sowie eine Reaktionszeit zwischen Testiterationen von 15 Sekunden eingefügt. Durch Anwenden einer Last wurde eine durchschnittliche Antwortzeit von zwei Sekunden für das Rendern einer Scorecard oder eines Berichts erzielt. Die durchschnittliche Antwortzeit wurde über einen Zeitraum von 15 Minuten nach einer ersten Aufwärmphase von 10 Minuten gemessen.

Bei jeder neuen Testiteration wurde ein anderes Benutzerkonto aus einem Pool von fünf Tausend Konten und eine zufällige IP-Adresse (mithilfe von IP-Wechsel in Visual Studio) aus einem Pool von ca. 2.200 Adressen ausgewählt.

Die Testmischung wurde zweimal auf demselben Dashboard mittlerer Größe ausgeführt. Beim ersten Durchgang wurde die Authentifizierung der Datenquellen so konfiguriert, dass das unbeaufsichtigte Dienstkonto verwendet wurde, welches ein allgemeines Konto zur Anforderung der Daten einsetzt. Die Datenergebnisse sind für mehrere Benutzer identisch, und Caching kann von PerformancePoint Services zur Steigerung der Leistung verwendet werden. Beim zweiten Durchgang wurde die Authentifizierung von Datenquellen so konfiguriert, dass die Einzelbenutzeridentität verwendet wird; der SQL Server Analysis Services-Cube wurde so konfiguriert, dass die dynamische Sicherheit angewendet wird. In dieser Konfiguration wird die Identität des Benutzers von PerformancePoint Services verwendet, um die Daten anzufordern. Da die Datenergebnisse unterschiedlich sein könnten, kann kein Caching für Benutzer verwendet werden. In bestimmten Fällen ist Caching für die Einzelbenutzeridentität möglich, wenn die dynamische Sicherheit von Analysis Services nicht konfiguriert ist und die Analysis Services-Rollen, denen Microsoft Windows-Benutzer und -Gruppen zugeordnet sind, identisch sind.

Hardwareeinstellungen und -topologie

Laborhardware

Um ein hohes Maß an Details bei den Testergebnissen zu erzielen, wurden verschiedene Farmkonfigurationen für die Tests verwendet. Die Farmkonfigurationen reichten von einem bis zu drei Webservern, einem bis vier Anwendungsservern und einem einzelnen Datenbankserver, auf dem Microsoft SQL Server 2008 ausgeführt wurde. Es wurde eine Standard-Unternehmensinstallation von SharePoint Server 2010 durchgeführt.

In der folgenden Tabelle ist die jeweilige Hardware für die Tests aufgelistet.

Webserver Anwendungsserver Computer, auf dem SQL Server ausgeführt wird Computer, auf dem Analysis Services ausgeführt wird

Prozessor(en)

2px4c @ 2,66 GHz

2px4c @ 2,66 GHz

2px4c @ 2,66 GHz

4px6c @ 2,4 GHz

RAM

16 GB

32 GB

16 GB

64 GB

Betriebssystem

Windows Server 2008 R2 Enterprise

Windows Server 2008 R2 Enterprise

Windows Server 2008 R2 Enterprise

Windows Server 2008 R2 Enterprise

NIC

1x1 Gigabit

1x1 Gigabit

1x1 Gigabit

1x1 Gigabit

Authentifizierung

NTLM und Kerberos

NTLM und Kerberos

NTLM und Kerberos

NTLM und Kerberos

Nach dem Skalieren der Farm auf mehrere Webserver wurde ein Hardware-Lastenausgleichsmodul zur Verteilung der Benutzerlast auf mehrere Webserver mithilfe der Quelladressaffinität verwendet. Bei der Quelladressaffinität wird die IP-Quelladresse eingehender Anforderungen und der Diensthost, an den diese als Lastenausgleich verteilt wurden, aufgezeichnet und alle kommenden Transaktionen an denselben Host geleitet.

Topologie

Die Ausgangstopologie setzte sich aus zwei physikalischen Servern zusammen, wobei ein Server als Web- und Anwendungsserver und der zweite als Datenbankserver diente. Diese Ausgangstopologie wird als Topologie mit zwei Rechnern (2M) oder als "1x0x1"-Topologie bezeichnet, wobei die Anzahl der dedizierten Webserver zuerst aufgeführt ist, gefolgt von den dedizierten Anwendungsservern und schließlich den Datenbankservern.

Webserver werden nachfolgend in diesem Dokument auch als Web-Front-Ends (WFE) bezeichnet. Die Last wurde so lange angewendet, bis Einschränkungen auftraten. In der Regel stellte die CPU des Web- oder des Anwendungsservers eine Einschränkung dar; es wurden dann Ressourcen hinzugefügt, um diese Einschränkung zu überwinden. Die Einschränkungen und Topologien wichen abhängig von der Konfiguration der Datenquellenauthentifizierung entweder für das unbeaufsichtigte Dienstkonto oder die Einzelbenutzeridentität mit dynamischer Cubesicherheit stark voneinander ab.

Testergebnisse

Die Testergebnisse enthalten drei wichtige Measures für die Definition der PerformancePoint Services-Kapazität.

Measure Beschreibung

Benutzeranzahl

Gesamtanzahl der von Visual Studio gemeldeten Benutzer.

Anforderungen pro Sekunde (RPS)

Gesamtanzahl der von Visual Studio gemeldeten RPS, einschließlich aller Anforderungen und Anforderungen statischer Dateien wie Bilder und Stylesheets.

Ansichten pro Sekunde (VPS)

Gesamtanzahl der Ansichten, die PerformancePoint Services rendern kann. Eine Ansicht ist ein beliebiger von PerformancePoint Services gerenderter Filter, eine Scorecard, ein Raster oder ein Diagramm oder eine beliebige Webanforderung der Renderingdienst-URL, die RenderWebPartContent oder CreateReportHtml enthält. Weitere Informationen zu CreateReportHtml und RenderWebPartContent finden Sie in der Protokollspezifikation für den Rendering-Dienst der PerformancePoint-Dienste (http://go.microsoft.com/fwlink/?linkid=200609&clcid=0x407).

IIS-Protokolle können nach diesen Anforderungen analysiert werden, um die Kapazität von PerformancePoint Services besser zu planen. Darüber hinaus kann mithilfe dieses Measures eine Zahl bereitgestellt werden, die deutlich weniger abhängig von der Dashboardzusammensetzung ist. Ein Dashboard mit zwei Ansichten kann mit einem Dashboard mit 10 Ansichten verglichen werden.

Ff955652.Tip(de-de,office.14).gifTipp:

Bei Verwendung einer Datenquelle, die so konfiguriert ist, dass die Authentifizierung des unbeaufsichtigten Dienstkontos verwendet wird, gilt für das Verhältnis zwischen dedizierten Servern die Regel von einem Webserver zu jeweils zwei Anwendungsservern mit PerformancePoint Services.

Ff955652.Tip(de-de,office.14).gifTipp:

Bei Verwendung einer Datenquelle, die so konfiguriert ist, dass die Einzelbenutzerauthentifizierung verwendet wird, gilt für das Verhältnis zwischen dedizierten Servern die Regel von einem Webserver zu jeweils vier oder mehr Anwendungsservern mit PerformancePoint Services.

Bei Topologien mit mehr als vier Anwendungsservern ist davon auszugehen, dass der Analysis Services-Server den Engpass darstellt. Sie sollten die CPU-Auslastung und die Abfragezeit des Analysis Services-Servers überwachen, um bestimmen zu können, ob Analysis Services auf mehrere Server skaliert werden sollte. Durch Verzögerungen bei der Abfragezeit auf dem Analysis Services-Server steigt die durchschnittliche Antwortzeit von PerformancePoint Services deutlich über den gewünschten Schwellenwert von zwei Sekunden.

Die nachfolgenden Tabellen enthalten eine Zusammenfassung der Testergebnisse sowohl für die Authentifizierung über das unbeaufsichtigte Dienstkonto als auch die Einzelbenutzerauthentifizierung bei einer horizontalen Skalierung von zwei auf sieben Server. Ausführliche Ergebnisse, die zusätzliche Leistungsindikatoren umfassen, sind nachfolgend in diesem Dokument aufgeführt.

Zusammenfassung der Authentifizierung über das unbeaufsichtigte Dienstkonto

Topologie (WFExAPPxSQL) Benutzer Anforderungen pro Sekunde (RPS) Ansichten pro Sekunde (VPS)

2M (1x0x1)

360

83

50

3M (1x1x1)

540

127

75

4M (1x2x1)

840

196

117

5M (1x3x1)

950

215

129

6M (2x3x1)

1.250

292

175

7M (2x4x1)

1.500

346

205

Zusammenfassung der Einzelbenutzerauthentifizierung

Topologie (WFExAPPxSQL) Benutzer Anforderungen pro Sekunde (RPS) Ansichten pro Sekunde (VPS)

2M (1x0x1)

200

47

27

3M (1x1x1)

240

56

33

4M (1x2x1)

300

67

40

5M (1x3x1)

325

74

44

Topologien mit 2M und 3M

Zur einfacheren Erläuterung der Hardwarekosten pro Transaktion und der Antwortzeitkurve wurden die Auslastungstests mit vier steigenden Benutzerauslastungen bis zur maximalen Benutzerauslastung für die 2M- und 3M-Topologien durchgeführt.

Authentifizierung über das unbeaufsichtigte Dienstkonto

Benutzeranzahl 50 150 250 360

Durchschnittl. WFE/APP-CPU

19,20%

57,70%

94,00%

96,70%

Anforderungen pro Sekunde

18

53

83

83

Ansichten pro Sekunde

10,73

31,72

49,27

49,67

Durchschnittl. Antwortzeit (s)

0,12

0,15

0,38

2

PPS_CapicityChart1

Einzelbenutzerauthentifizierung

Benutzeranzahl 50 100 150 200

Durchschnittl. WFE/APP-CPU

30,80%

61,30%

86,50%

93,30%

Anforderungen pro Sekunde

17

32

43

47

Ansichten pro Sekunde

10,3

19,32

26,04

27,75

Durchschnittl. Antwortzeit (s)

0,28

0,45

0,81

2

PPS_CapicityChart2

Ergebnisse 3M-Farm (1x1x1)

Authentifizierung über das unbeaufsichtigte Dienstkonto

Benutzeranzahl 100 250 400 540

Anforderungen pro Sekunde

36

87

124

127

Ansichten pro Sekunde

21

52

74

75

Durchschnittl. Antwortzeit (s)

0,12

0,18

0,65

2

Durchschnittl. WFE-CPU

11%

28%

43%

46%

Max. private Bytes des WFE vom SharePoint Server-W3WP-Arbeitsprozess mit Internetinformationsdiensten (Internet Information Services, IIS).

0,7 GB

1,4 GB

2,0 GB

2,4 GB

Durchschnittl. APP-CPU

25%

62%

94%

95%

Max. private Bytes des APP vom PerformancePoint Services-W3WP-Arbeitsprozess

5,9 GB10,8 GB

10,8 GB

14,1 GB

14,6 GB

PPS_CapicityChart3

Einzelbenutzerauthentifizierung

Benutzeranzahl 50 120 180 240

Anforderungen pro Sekunde

17

39

52

56

Ansichten pro Sekunde

10

23

31

33

Durchschnittl. Antwortzeit (s)

0,28

0,48

0,91

2

Durchschnittl. WFE-CPU

5%

12%

17%

19%

Max. private Bytes des WFE vom SharePoint Server-W3WP-Arbeitsprozess

0,78 GB

1,3 GB

1,6 GB

1,9 GB

Durchschnittl. APP-CPU

25%

57%

81%

81%

Max. private Bytes des APP vom PerformancePoint Services-W3WP-Arbeitsprozess

19 GB

20,1 GB

20,5 GB

20,9 GB

PPS_CapicityChart4

Ergebnisse von 4M+ für die Authentifizierung über das unbeaufsichtigte Dienstkonto

Beginnend mit einer 4M-Topologie wurde die Last angewendet, um eine durchschnittliche Antwortzeit von zwei Sekunden für das Rendern einer Scorecard oder eines Berichts zu erzielen. Im nächsten Schritt wurde ein zusätzlicher Server hinzugefügt, um die Einschränkung (durch die CPU auf dem Web- oder Anwendungsserver) zu umgehen; anschließend wurde die Testmischung erneut ausgeführt. Diese Logik wurde so lange wiederholt, bis insgesamt sieben Server erreicht waren.

4M (1x2x1) 5M (1x3x1) 6M (2x3x1) 7M (2x4x1)

Benutzeranzahl

840

950

1.250

1.500

Anforderungen pro Sekunde

196

216

292

346

Ansichten pro Sekunde

117

131

175

206

Durchschnittl. WFE-CPU

77%

63%

54%

73%

Max. private Bytes des WFE vom SharePoint Server-W3WP-Arbeitsprozess

2,1 GB

1,7 GB

2,1 GB

2,0 GB

Durchschnittl. APP-CPU

83%

94%

88%

80%

Max. private Bytes des APP vom PerformancePoint Services-W3WP-Arbeitsprozess

16 GB

12 GB

15 GB

15 GB

Ergebnisse von 4M+ für die Einzelbenutzerauthentifizierung

Die gleichen Tests wurden für eine für die Einzelbenutzerauthentifizierung konfigurierte Datenquelle wiederholt. Durch Hinzufügen eines Anwendungsservers, um eine Topologie mit vier Anwendungsservern zu erstellen, kam es aufgrund der Abfrageverzögerungen von Analysis Services nicht zu einem Anstieg der von PerformancePoint Services unterstützten Benutzer oder Anforderungen pro Sekunde.

3M (1x1x1) 4M (1x2x1) 5M (1x3x1) 6M (1x4x1)

Benutzeranzahl

240

300

325

325

Anforderungen pro Sekunde

56

67

74

74

Ansichten pro Sekunde

33

40

44

45

Durchschnittl. WFE-CPU

19%

24%

26%

12%

Max. private Bytes des WFE vom SharePoint Server-W3WP-Arbeitsprozess

2,1 GB

1,9 GB

1,9 GB

1,5 GB

Durchschnittl. APP-CPU

89%

68%

53%

53%

Max. private Bytes des APP vom PerformancePoint Services-W3WP-Arbeitsprozess

20 GB

20 GB

20 GB

20 GB

Analysis Services-CPU

17%

44%

57%

68%

PPS_CapicityChart5

Empfehlungen

Hardwareempfehlungen

Die Leistungsindikatoren für Arbeitsspeicher und Prozessoren in den Testtabellen sollten für die Bestimmung der Hardwareanforderungen für eine Installation von PerformancePoint Services verwendet werden. Für Webserver werden die empfohlenen SharePoint Server 2010-Hardwareanforderungen von PerformancePoint Services verwendet. Die Hardwareanforderungen für Anwendungsserver müssen möglicherweise geändert werden, wenn PerformancePoint Services sehr viel Arbeitsspeicher benötigt. Dies ist dann der Fall, wenn Datenquellen für die Einzelbenutzerauthentifizierung konfiguriert werden oder wenn zu viele Dashboards mit langen Datenquellentimeouts vom Anwendungsserver ausgeführt werden.

Der Datenbankserver stellte in den Tests keinen Engpass dar und erreichte einen Höchstwert bei einer maximalen CPU-Auslastung von 31% unter dem über das unbeaufsichtigte Dienstkonto authentifizierten 7M-Dashboard. Die PerformancePoint Services-Inhaltsdefinitionen wie Berichte, Scorecards und KPIs werden in SharePoint-Listen gespeichert und von PerformancePoint Services im Arbeitsspeicher zwischengespeichert, wodurch die Auslastung des Datenbankservers sinkt.

Arbeitsspeicherbelegung

In bestimmten Konfigurationen kann PerformancePoint Services sehr viel Arbeitsspeicher belegen, deshalb ist es wichtig, die Arbeitsspeichernutzung des PerformancePoint Services-Anwendungspools zu überwachen. Verschiedene Elemente werden von PerformancePoint Services im Arbeitsspeicher zwischengespeichert, einschließlich Analysis Services und anderer Abfrageergebnisse der Datenquelle zur Cachelebensdauer der Datenquelle (Standardeinstellung beträgt 10 Minuten). Wenn Sie eine Datenquelle verwenden, die für die Authentifizierung über das unbeaufsichtigte Dienstkonto konfiguriert wurde, werden diese Abfrageergebnisse nur einmal zwischengespeichert und für mehrere Benutzer gemeinsam genutzt. Wenn Sie hingegen eine Datenquelle verwenden, die für die Einzelbenutzerauthentifizierung und die dynamische Cubesicherheit von Analysis Services konfiguriert wurde, werden die Abfrageergebnisse einmal pro Benutzer pro Ansicht (also eine "pro Filter"-Kombination) gespeichert.

Das ASP.NET-Cache-API ist das zugrundliegende Cache-API, das von PerformancePoint Services verwendet wird. Der klare Vorteil, der sich aus der Verwendung dieses APIs ergibt, liegt darin, dass der Cache von ASP.NET verwaltet wird und auf der Grundlage von Arbeitsspeicherbegrenzungen Elemente entfernt (so genanntes Kürzen), um Fehler aufgrund von unzureichendem Arbeitsspeicher zu vermeiden. Die Standardbegrenzung für den Arbeitsspeicher liegt bei 60 Prozent des physikalischen Arbeitsspeichers. Nach Erreichen diese Grenzwerts wurden Ansichten von PerformancePoint Services zwar noch gerendert, doch stiegen die Antwortzeiten während des kurzen Zeitraums deutlich an, während dem zwischengespeicherte Einträge von ASP.NET entfernt wurden.

Der Leistungsindikator "ASP.NET-Anwendungen \ Cache-API-Kürzungen" des Anwendungspools, der PerformancePoint Services hostet, kann zur Überwachung der ASP.NET-Cachekürzungen verwendet werden, die aufgrund von hoher Arbeitsspeicherauslastung stattfinden. Ist dieser Leistungsindikator größer als Null, sollten Sie in der folgenden Tabelle nach möglichen Lösungen suchen.

Problem Lösung

Nutzung des Anwendungsserverprozessors ist niedrig; andere Dienste werden auf dem Anwendungsserver ausgeführt.

Hinzufügen von zusätzlichem physikalischen Arbeitsspeicher oder Begrenzen des Arbeitsspeichers des ASP.NET-Caches.

Nutzung des Anwendungsserverprozessors ist niedrig; nur PerformancePoint Services wird auf dem Anwendungsserver ausgeführt.

Konfigurieren der ASP.NET-Cacheeinstellungen, sodass mehr Arbeitsspeicher vom Cache genutzt wird (falls akzeptabel), oder Hinzufügen von zusätzlichem Arbeitsspeicher.

Nutzung des Anwendungsserverprozessors ist hoch.

Hinzufügen eines anderen Anwendungsservers.

Abfrageergebnisse und Cacheeinträge können von einer Datenquelle, die für die Einzelbenutzerauthentifizierung konfiguriert wurde, freigegeben werden, wenn die Analysis Services-Rollenmitgliedschaften der Benutzer identisch sind und die dynamische Cubesicherheit nicht konfiguriert wurde. Dies ist ein neues Feature von PerformancePoint Services in Microsoft SharePoint Server 2010. Wenn beispielsweise Benutzer A der Rolle 1 und 2 angehört, Benutzer B der Rolle 1 und 2 angehört und Benutzer C der Rolle 1, 2 und 3 angehört, können nur für Benutzer A und Benutzer B Cacheeinträge gemeinsam genutzt werden. Wenn die dynamische Cubesicherheit verwendet wird, können weder für Benutzer A und B noch für Benutzer C Cacheeinträge gemeinsam genutzt werden.

Analysis Services

Beim Testen von PerformancePoint Services unter Verwendung der Einzelbenutzerauthentifizierung wurden zwei Eigenschaften von Analysis Services geändert, um die Durchsatzleistung bei mehreren Benutzern zu verbessern. In der folgenden Tabelle werden die geänderten Eigenschaften und ihre neuen Werte dargestellt.

Analysis Services-Eigenschaft Wert

Arbeitsspeicher \ HeapTypeForObjects

0

Arbeitsspeicher \ MemoryHeapType

2

Durch diese beiden Speichereinstellungen wird Analysis Services für die Verwendung des Windows-Heaps anstelle des Analysis Services-Heaps konfiguriert. Vor der Änderung dieser Eigenschaften und bei zunehmender Benutzerauslastung stiegen die Antwortzeiten deutlich von 0,2 Sekunden auf über 30 Sekunden an, während die CPU-Auslastung der Web-, Anwendungs- und Analysis Services-Server niedrig blieb. Zur Problembehandlung wurde die Abfragezeit mithilfe von dynamischen Analysis Services-Verwaltungssichten erfasst, die einen Anstieg der einzelnen Abfragezeiten von 10 Millisekunden auf 5000 Millisekunden zeigten. Die oben genannten Speichereinstellungen wurden aufgrund dieser Ergebnisse geändert.

Die Änderung dieser Einstellungen führt zu einer deutlichen Verbesserung des Durchsatzes, bringt nach Angaben des Analysis Services-Teams jedoch nur geringe, messbare Kosten für Einzelbenutzerabfragen mit sich.

Vor dem Ändern von Analysis Services-Eigenschaften sollten Sie das Dokument SQL Server 2008-Whitepaper: Handbuch zur Leistungsoptimierung in Analysis Services (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x407) lesen. Sie erhalten hier einen Einblick in optimale Methoden für die Verbesserung der Durchsatzleistung mit mehreren Benutzern.

Häufige Engpässe und ihre Ursachen

Während der Leistungstests traten bestimmte 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. Wenn eine hohe Prozessornutzung als Engpass auftrat, wurden zusätzliche Server hinzugefügt, um den Engpass zu beseitigen. In der folgenden Tabelle sind einige häufige Engpässe und mögliche Lösungen aufgeführt. Dabei wurde angenommen, dass die Prozessornutzung niedrig war und keinen Engpass darstellte.

Möglicher Engpass Ursache und was überwacht werden sollte Lösung

Leistung des Analysis Services-Speicherheaps

Standardmäßig wird der eigene Speicherheap von Analysis Services anstelle des Windows-Heaps verwendet, der nur eine niedrige Durchsatzleistung für mehrere Benutzer bietet. Überprüfen Sie die Analysis Services-Abfragezeiten mithilfe dynamischer Verwaltungssichten, um festzustellen, ob Abfragezeiten mit der Benutzerauslastung steigen und die Analysis Services-Prozessornutzung niedrig ist.

Ändern Sie Analysis Services so, dass der Windows-Heap verwendet wird. Anleitungen entnehmen Sie dem Abschnitt "Analysis Services" weiter oben in diesem Artikel sowie dem SQL Server 2008-Whitepaper: Handbuch zur Leistungsoptimierung in Analysis Services (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x407).

Analysis Services-Abfrage- und Verarbeitungsthreads

Standardmäßig wird die Anzahl der Abfrage- und Verarbeitungsthreads für Abfragen von Analysis Services begrenzt. Bei lang andauernden Abfragen und hohen Benutzerauslastungen werden möglicherweise alle verfügbaren Threads verwendet. Überwachen Sie die Leistungsindikatoren der Threads im Leerlauf und der Auftragswarteschlange unter der Kategorie "MSAS 2008:Threads".

Erhöhen Sie die Anzahl der für Abfragen und Prozesse verfügbaren Threads. Anleitungen entnehmen Sie dem Abschnitt "Analysis Services" des SQL Server 2008-Whitepapers: Handbuch zur Leistungsoptimierung in Analysis Services (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x407).

Arbeitsspeicher von Anwendungsservern

In PerformancePoint Services werden die Abfrageergebnisse von Analysis Services und anderen Datenquellen während der Lebensdauer des Caches der Datenquelle zwischengespeichert. Diese Elemente können sehr viel Arbeitsspeicher beanspruchen. Überwachen Sie den Leistungsindikator "ASP.NET-Anwendungen \ Cache-API-Kürzungen" des PerformancePoint Services-Anwendungspools, um festzustellen, ob Cachekürzungen aufgrund von niedrigem Arbeitsspeicher von ASP.NET erzwungen werden.

Fügen Sie Arbeitsspeicher hinzu, oder erhöhen Sie die Standard-Cachespeicherbegrenzungen von ASP.NET. Weitere Hinweise entnehmen Sie dem Abschnitt "Arbeitsspeicherbelegung" weiter oben in diesem Dokument. Weitere Informationen finden Sie auch im Dokument Einstellungen des ASP.NET-Cacheelements (http://go.microsoft.com/fwlink/?linkid=200610&clcid=0x407) sowie in Thomas Marquardts Blogbeitrag über Hintergrundinfos zu den Arbeitsspeicherbegrenzungen des ASP.NET-Caches (http://go.microsoft.com/fwlink/?linkid=200611&clcid=0x407).

Einstellungen der WCF-Drosselung

PerformancePoint Services ist als WCF-Dienst implementiert. Durch WCF wird die maximale Anzahl gleichzeitiger Aufrufe als Dienstdrosselungsverhalten eingeschränkt. Obwohl lang andauernde Abfragen zu diesem Engpass führen könnten, tritt dieser Engpass nicht häufig auf. Überwachen Sie Aufrufe der Leistungsindikatoren des WCF-/Dienst-Modells, die für PerformancePoint Services ausstehen und vergleichen Sie sie mit der maximalen Anzahl gleichzeitiger Aufrufe.

Falls erforderlich, ändern Sie das WCF-Drosselungsverhalten (Windows Communication Foundation). Informationen finden Sie unter Drosselungsverhalten des WCF-Diensts (http://go.microsoft.com/fwlink/?linkid=200612&clcid=0x407) und in Wenlong Dongs Blogbeitrag über die WCF-Anforderungsdrosselung und Serverskalierbarkeit (http://go.microsoft.com/fwlink/?linkid=200613&clcid=0x407).

Leistungsüberwachung

Um den richtigen Zeitpunkt für eine vertikale oder horizontale Skalierung des Systems zu bestimmen, verwenden Sie Leistungsindikatoren zur Überwachung der Integrität des Systems. PerformancePoint Services ist ein ASP.NET-WCF-Dienst und kann mithilfe derselben Leistungsindikatoren wie zur Überwachung sonstiger ASP.NET-WCF-Dienste überwacht werden. Verwenden Sie darüber hinaus die Informationen in den folgenden Tabellen, um zusätzliche zu überwachende Leistungsindikatoren zu ermitteln und um festzustellen, auf welchen Prozess die Leistungsindikatoren angewendet werden sollten.

Leistungsindikator Indikatorinstanz Hinweise

ASP.NET-Anwendungen / Cache-API-Kürzungen

PerformancePoint Services-Anwendungspool

Wenn der Wert größer als Null ist, lesen Sie den Abschnitt "Arbeitsspeicherbelegung" durch.

MSAS 2008:Threads / Abfragepoolthreads im Leerlauf

n/v

Wenn der Wert gleich Null ist, lesen Sie die Informationen im Abschnitt "Analysis Services" des SQL Server 2008-Whitepapers: Handbuch zur Leistungsoptimierung in Analysis Services (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x407).

MSAS 2008:Threads / Abfragepool-Auftragswarteschlangenlänge

n/v

Wenn der Wert größer als Null ist, lesen Sie die Informationen im Abschnitt "Analysis Services" des SQL Server 2008-Whitepapers: Handbuch zur Leistungsoptimierung in Analysis Services (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x407).

MSAS 2008:Threads / Verarbeitungspoolthreads im Leerlauf

n/v

Wenn der Wert größer als Null ist, lesen Sie die Informationen im Abschnitt "Analysis Services" des SQL Server 2008-Whitepapers: Handbuch zur Leistungsoptimierung in Analysis Services (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x407).

MSAS 2008:Threads / Verarbeitungspool-Auftragswarteschlangenlänge

n/v

Wenn der Wert größer als Null ist, lesen Sie die Informationen im Abschnitt "Analysis Services" in Handbuch zur Leistungsoptimierung in Analysis Services (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x407).

WCF CountersServiceModelService 3.0.0.0(*)\Ausstehende Aufrufe

PerformancePoint-Dienstinstanz

Wenn der Wert größer als Null ist, lesen Sie die Informationen in WCF-Anforderungsdrosselung und Serverskalierbarkeit (http://go.microsoft.com/fwlink/?linkid=200613&clcid=0x407).

Änderungsverlauf

Datum Beschreibung

09. September 2010

Erstveröffentlichung

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft