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

Gilt für: SharePoint Server 2010

Letztes Änderungsdatum des Themas: 2017-01-18

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

Inhalt dieses Artikels

• Testfarmmerkmale

• Testergebnisse

• Empfehlungen

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-Dienste 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.

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.

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

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-Dienste 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-Dienste 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.

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-Dienste-Kapazität.

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-Dienste 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

Zusammenfassung der Einzelbenutzerauthentifizierung

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

Einzelbenutzerauthentifizierung

Ergebnisse 3M-Farm (1x1x1)

Authentifizierung über das unbeaufsichtigte Dienstkonto

Einzelbenutzerauthentifizierung

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.

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-Dienste unterstützten Benutzer oder Anforderungen pro Sekunde.

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-Dienste verwendet werden. Für Webserver werden die empfohlenen SharePoint Server 2010-Hardwareanforderungen von PerformancePoint-Dienste verwendet. Die Hardwareanforderungen für Anwendungsserver müssen möglicherweise geändert werden, wenn PerformancePoint-Dienste 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-Dienste-Inhaltsdefinitionen wie Berichte, Scorecards und KPIs werden in SharePoint-Listen gespeichert und von PerformancePoint-Dienste im Arbeitsspeicher zwischengespeichert, wodurch die Auslastung des Datenbankservers sinkt.

Arbeitsspeicherbelegung

In bestimmten Konfigurationen kann PerformancePoint-Dienste sehr viel Arbeitsspeicher belegen, deshalb ist es wichtig, die Arbeitsspeichernutzung des PerformancePoint-Dienste-Anwendungspools zu überwachen. Verschiedene Elemente werden von PerformancePoint-Dienste 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-Dienste 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-Dienste 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-Dienste 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.

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-Dienste 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.

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 (https://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.

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-Dienste 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.

See Also

Concepts

Planen für PerformancePoint Services (SharePoint Server 2010)