2. Agenda
Einführung
Setup- und Serviceaccounts (Least
Privileged)
SQL Server Installation
Farm Setup (Varianten, Authentifizierung)
Datenbankdesign und Erstellung
Farm Konfiguration
Fine Tuning (Crawling, Icons, Filehandling
etc.)
Q&A
3. Speaker
Samuel Zürcher
Senior Consultant / Evangelist
SharePoint und SQL Server
MCTS, MCITP, MCT, MVP
Kontakt und Webauftritte
szu@expertsinside.com
Samuel.Zuercher@sharepointcommunity.ch
Blog: http://sharepointszu.com
Community: http://www.sharepointcommunity.ch
Konferenz: http://www.collaborationdays.ch
XING: https://www.xing.com/profile/Samuel_Zuercher3
Facebook: http://www.facebook.com/sharepointszu
Twitter: @sharepointszu
Samuel Zürcher [MVP] hat Langjährige Erfahrung mit SharePoint seit der Version 2.0, breites Technologie
Know-how und ist seit 15 Jahren in der IT tätig. Er ist im Projektmanagement in verschiedenen
Projektgrössen und Komplexitätsstufen daheim, kennt sich aber auch mit dem innersten Kern von SharePoint
aus. Verschiedene Zertifizierungen für SharePoint und der Microsoft Certified Trainer runden sein Profil ab
(MCT, MCTS, MCIPT). Er ist der Initiant und zusammen mit Stefan Heinz Begründer der
www.sharepointcommunity.ch und Co-Organisator der Collaboration Days.
4. Einführung
SharePoint Komponenten (Rollen)
Web Frontend
Applikationsserver
Datenbankserver
Mail Server (Verbindung zu Exchange)
Vor der Installation
Technische Voraussetzungen
Mengengerüst
Farm- und Storage Sizing (HP Sizing Tool, Capacity Planning, Farm
Design beim Anmeldefenster auf Abbrechen)
Hardware
Abgestimmt auf das Mengengerüst
Security- bzw. Policy Anforderungen? (DMZ, Verfügbarkeit etc.)
5. Hardware Voraussetzungen
Nur x64 fähige Hardware wird unterstützt
Frontend- und Applikationsserver
4 Kern Prozessor
8GB RAM
80GB Systemfestplatte
Anzahl wächst mit dem Mengengerüst
SQL Server (Clustered, Mirrored oder Standallone)
2 x 4 Kern Prozessor
16GB RAM
80GB Systemfestplatte
RAID 10 Disksubsystem oder Attached Storage
In der Regel 1 DB Server, in grossen Farmen 1-n DB
Server
Datenbankserver langsam = SharePoint langsam
6. Software Voraussetzungen
Windows Server (ausschliesslich x64)
Ab Version 2008 SP2
Installieren der Prerequisites (Für Serverprodukte
automatisch mit dem Prerequisites Installer)
SQL Server (ausschliesslich x64)
SQL Server 2005 SP3 CU3
SQL Server 2008 SP1 CU2 (oder >= CU5)
Active Directory
AD DS von Windows Server 2003 SP2 (Auch
Functional Level)
Wichtig für die Profilsynchronisation, nicht wichtig
für Foundation
7. Merkmale erfolgreicher Projekte
Erfolgreiche Intranet-Projekte mit SharePoint 2010 sind…
…mit einem dedizierten Projektleiter ausgestattet
…Management driven
…auf die (grössten) Bedürfnisse der Mitarbeitenden
fokussiert
…sorgfältig geplant und gut vorbereitet
…mit genügend Ressourcen unterwegs
…auf scale out und scale up Szenarien vorbereitet
…nicht dazu da, die User endlich auf interne Prozesse zu
zwingen
…new Technology, new way of work aware
…klein gestartet und mit weiteren Iterationen gewachsen
8. Setup- und Serviceaccounts
Admin Account (Optional)
Setup Account (dbcreator, securityadmin Rolle in
SQL)
SQL Account (SQL Instanz Principal)
SharePoint Farm Account (Farm Principal)
Services Account (Service Applications)
1-n Webapplikations-Accounts (1 pro
Webapplikation)
Webapplikations-Account für MySite
Import Account für Profile (Replicate Directory
Changes auf Active Directory)
Crawling Account (Indexer)
9. Vorbereitungen für Kerberos
Wann Kerberos und wann NTLM?
Kernfrage: Muss ich später auf weitere Daten ausserhalb
SharePoint zugreifen? Wenn ja, dann Kerberos zwingend
Zusammensetzung eines SPN
Dienstname/Server:Port
z.B. SQLSvc/MyServer:1433 und
SQLSvc/MyServer.MyDomain.ch:1433
Für welche Accounts?
SQL Service Account
Alle Webapplication Service Accounts
Farm Account
ACHTUNG: Beim Crawling mit Kerberos sind nur Ports 80
und 443 zulässig, also zwingend mit Host Headers arbeiten
(ausser CA)
10. SQL Server Installation
Genug starke Hardware
Grundsatz: SQL langsam => SharePoint langsam
Testumgebung 8GB RAM, Live Umgebung 16GB
Sollte ein SQL virtualisiert werden? Wenn immer
möglich, Nein
Vorsicht, Verwirrung bei Collations
Supportmeldung:
http://support.microsoft.com/kb/2008668
Technet Anweisung: http://technet.microsoft.com/en-
us/library/cc262869.aspx (dient auch für’s Aufsetzen)
Richtig ist Latin1_General_CI_AS_KS_WS
11. Parametrisierung
Fill Factor 70%
T-Log Backup alle 15min bis max. 24h
Disable Boost SQL Server Priority
Max Degree of Parallelism 1 (für SharePoint only Instanzen)
Min und Max Memory konfigurieren
Temp DB auf 10GB und 4 Files verteilen, Autogrowth 1GB
Lock Pages in Memory (für SQL Std. –T845) und Perform
Volume Maintennance Tasks für SQL Account setzen
Traceflag 1117 (-T1117) für gleichmässigen Filegrowth
Backupcompression einschalten
Index Maintennance <=30% Reorganisation, sonst Rebuild
Update Statistics täglich, DBCC Checkdb vor Fullbackup
12. Best Practice auf dem SQL
Transaction Log Datenbanken Temp DB
SQL Instanz für Search
L1 L2 L3
SQL Instanz für Daten und Konfiguration
L4 L5 L6
13. Farm Setup
Verschiedene Varianten
Vollständig per vom DBA erstellten Datenbanken
Nur Content Datenbanken vom DBA erstellt
Setup Wizzardd Ja / Nein
Power Shell (z.B. Codeplex)
Grösse der Farm ist ausschlaggebend
Kleine Farm Von Hand, nur Content DB vom DBA
erstellt
Mittlere Farm Grossteil von Hand, DBs wenn
möglich vom DBA erstellt
Grosse Farm Je nach Deployment von Hand oder
per Script und alle DBs vom DBA erstellt
17. Skalierung «Big Farm»
WFE WFE WFE
Application
SQL Server Cluster 1 SQL Server Cluster 2
18. Datenbankdesign und Erstellung
Vom DBA erstellte DBs per Script erstellen
Datenfiles auf mehrere Dateien verteilen
Faustregel: 0.25 bis 0.5 mal Prozessorkerne, in
der Regel 4-8 Files
1. File 128 MB und Nogrowth für System Tables
Restliche Files auf gesamte DB Grösse aufteilen
Log Initial 1GB (wenn es grösser sein muss 8GB)
Nie Shrinkfile auf DBs ausführen
Achtung, Script muss im SQLCMD Mode
ausgeführt werden
21. Farm Konfiguration
My Site (je nach Variante des Aufsetzens)
Search Setup und Konfiguration
PDF Crawling iFilter (Foxit oder Adobe für x64 Systeme)
User Profil Import aus dem AD
Achtung bei NetBios Verwendung
Timeouts und Probleme (BlogPost)
Blocked Filetypes anpassen (lnk, url, pdf)
Analytics und Diagnostic Logging
DisableLoopBackCheck damit auf dem Server selbst lokale
IIS Sites aufgerufen werden können (KB896861)
Login Prompt für Explorerview vermeiden (BlogPost)
22. Fine Tuning
Icons für pdf, url und lnk Dateien
Browserfilehandling (BlogPost, wenn das nicht hilft)
OpenControl Anpassung (BlogPost)
SharePoint Governance nicht vergessen (Blog Serie)
Social Timer Jobs aktivieren
Die Krux mit dem Search Center
Für Publishing infrastruktur (Event ID 7362 BlogPost)
Cash Reader
Cash Super User
Probleme nach August 11 CU (Event ID 3 BlogPost)
SAN Zertifikate und Binding auf mehreren IIS Seiten
appcmd set site /site.name:"<IISSiteName>" /+bindings.[protocol='https',bindingInformation='*:443:<hostHeaderValue>']
24. Glauben ist gut, wissen ist besser!
Ist meine Farm performant?
Passt meine Topologie?
Reicht meine Hardware?
Wie viele Benutzer können auf meiner
Farm maximal parallel arbeiten?
Hat meine custom SharePoint Solution ein
Memory Leak?
25. Vorgehen
Erstellen eines Testplans
Erstellen der Testumgebung
Erstellen von Tests, Tools & Testdaten
Lasttest ausführen
Optimieren der Architektur
Bereitstellung in der
Produktionsumgebung
26. SharePoint Load Test Kit (LTK)
Enthalten im SharePoint 2010
Administration Toolkit
Generiert VS 2008 Load Test Projekt
basierend auf IIS logs
VS 2008 Team System und SharePoint
müssen lokal installiert sein
Gutes Muster, schlechte Doku
28. Komplexe Testumgebung
Azure Test Agents
Domain Controller
SP WFE
Test Controller SQL Server
SP APP
29. Questions & Answers
….noch Fragen?!
Kontakt:
szu@expertsinside.com
Mehr zum Thema:
http://sharepointszu.com/category/die-serie-best-practice/
Editor's Notes
http://technet.microsoft.com/en-us/library/ff758659.aspxErstellen eines TestplansIhr Plan sollte Folgendes enthalten:Hardware, die für die Ausführung bei erwarteten Produktionsleistungszielen konzipiert ist. Sie sollten die Leistung von Testsystemen immer konservativ messen.Bei Verwendung von benutzerdefiniertem Code oder benutzerdefinierten Komponenten ist es wichtig, diese Komponenten zuerst isoliert zu testen, um ihre Leistung und Stabilität zu überprüfen. Wenn sie stabil sind, sollten Sie das System mit den installierten Komponenten testen und die Leistung mit der Farm ohne die installierten Komponenten vergleichen. Häufig stellen benutzerdefinierte Komponenten die Hauptverursacher von Problemen im Zusammenhang mit der Leistung und Zuverlässigkeit in Produktionssystemen dar.Die Zielsetzung der Tests sollte bekannt sein. Sie sollten im Voraus wissen, welche Ziele im Rahmen der Tests erreicht werden sollten. Soll die Leistung neuer benutzerdefinierter Komponenten, die für die Farm entwickelt wurden, beurteilt werden? Soll die Zeitdauer für das Durchforsten und Indizieren einer Reihe von Inhalten erfasst werden? Soll festgestellt werden, wie viele Anforderungen pro Sekunde von der Farm unterstützt werden können? Für einen Test kann es viele verschiedene Zielsetzungen geben; bei der Ausarbeitung eines guten Testplans sollten Sie als erstes die Ziele festlegen, die verfolgt werden sollen.Wissen, wie das Testziel gemessen werden kann. Wenn Sie beispielsweise die Durchsatzkapazität Ihrer Farm messen möchten, müssen Sie die Anforderungen pro Sekunde (RPS) sowie die Seitenwartezeit erfassen. Wenn Sie die Suchleistung messen möchten, müssen Sie die Durchforstungszeit und die Dokumentindizierungsraten bestimmen. Wenn Sie sich über die Zielsetzung Ihrer Tests im Klaren sind, ist es einfacher, die Schlüsselleistungsindikatoren zu definieren, die im Rahmen der Tests bewertet werden müssen.Erstellen der TestumgebungNachdem Sie die Ziele für die Tests festgelegt, die Messungen definiert und die Kapazitätsanforderungen für Ihre Farm (aus den Schritten 1 und 2 dieses Prozesses) bestimmt haben, besteht die nächste Aufgabe darin, die Testumgebung zu entwerfen und zu erstellen. Der Aufwand, der mit dem Erstellen einer Testumgebung verbunden ist, wird häufig unterschätzt. Die Testumgebung sollte die Produktionsumgebung so nah wie möglich duplizieren. Zu den Features und Funktionen, die beim Entwurf der Testumgebung berücksichtigt werden sollten, gehören die folgenden:Authentifizierung - Legen Sie fest, ob die Active Directory-Domänendienste (Active Directory Domain Services, AD DS), die formularbasierte Authentifizierung (und wenn ja, mit welchem Verzeichnis) und die anspruchsbasierte Authentifizierung usw. in der Farm verwendet werden sollen. Unabhängig vom verwendeten Verzeichnis werden wie viele Benutzer in der Umgebung benötigt und wie sollen diese erstellt werden? Wie viele Gruppen oder Rollen werden benötigt und wie erstellen Sie sie und füllen sie auf? Sie müssen auch sicherstellen, dass Sie den Authentifizierungsdiensten ausreichend Ressourcen zugewiesen haben, damit keine Engpässe während der Tests auftreten.DNS - Bestimmen Sie, welche Namespaces bei Ihren Tests benötigt werden. Identifizieren Sie die Server, die auf diese Anforderungen reagieren, und stellen Sie sicher, dass in Ihrem Plan die IP-Adressen berücksichtigt werden, die von den jeweiligen Servern verwendet werden sowie die DNS-Einträge, die erstellt werden müssen.Lastenausgleich - Vorausgesetzt, Sie verwenden mehr als einen Server (was normalerweise der Fall ist, da Sie sonst nicht ausreichend Auslastung für die Durchführung von Auslastungstests haben), benötigen Sie eine Art von Lastenausgleichslösung. Dabei kann es sich um ein Hardwarelastenausgleichsmodul oder um Softwarelastenausgleich wie den Windows-Netzwerklastenausgleich (Network LoadBalancing, NLB) handeln. Legen Sie fest, was verwendet werden soll, und schreiben Sie alle Konfigurationsinformationen auf, die Sie für das schnelle und effiziente Setup benötigen. Darüber hinaus sollten Sie bedenken, dass Auslastungstest-Agents in der Regel die Adresse zur einer URL nur alle 30 Minuten versuchen aufzulösen. Sie sollten also keine Datei für lokale Hosts oder Roundrobin-DNS für den Lastenausgleich verwenden, da sich die Test-Agents voraussichtlich bei jeder einzelnen Anforderung an denselben Server wenden, anstatt die Last auf alle verfügbaren Server zu verteilen.Testserver - Bei der Planung der Testumgebung müssen Sie nicht nur die Server für die SharePoint Server 2010-Farm einplanen, sondern auch die für die Tests erforderlichen Computer. Dazu gehören in der Regel mindestens 3 Server, ggf. sind mehr erforderlich. Wenn Sie Visual Studio Team System (Team Test Load Agent) für die Tests verwenden, wird ein Computer als Auslastungstestcontroller verwendet. Im Allgemeinen werden mindestens 2 Computer als Auslastungstest-Agents eingesetzt. Die Agents sind die Computer, die die Anweisungen vom Testcontroller darüber, was getestet werden soll, entgegen nehmen und die Anforderungen an die SharePoint Server 2010-Farm herausgeben. Die Testergebnisse werden auf einem SQL Server-basierten Computer gespeichert. Sie sollten nicht denselben SQL Server-basierten Computer verwenden, der für die SharePoint Server 2010-Farm verwendet wird, da durch das Schreiben der Testdaten die verfügbaren SQL Server-Ressourcen für die SharePoint Server 2010-Farm beeinträchtigt werden. Beim Ausführen der Tests müssen auch die Testserver überwacht werden, genauso wie die Server in der SharePoint Server 2010-Farm oder Domänencontroller usw., um sicherzustellen, dass die Testergebnisse der Farm repräsentativ für die geplante Farm sind. Gelegentlich kann es vorkommen, dass die Auslastungs-Agents oder -Controller selbst einen Engpass darstellen. In diesem Fall entspricht der im Test angezeigte Durchsatz nicht dem Maximum, das von der Farm unterstützt werden kann.SQL Server - Folgen Sie in Ihrer Testumgebung den Hinweisen in den Abschnitten "Konfigurieren von SQL Server" und "Überprüfen von Speicherleistung und -zuverlässigkeit" im Artikel Speicher- und SQL Server-Kapazitätsplanung und -Konfiguration (SharePoint Server 2010).Überprüfung des Datasets - Bei der Auswahl der Inhalte, die Tests unterzogen werden, sollten Sie bedenken, dass in einem optimalen Szenario Daten aus einem vorhandenen Produktionssystem verwendet werden. So können Sie beispielsweise Ihre Inhaltsdatenbanken aus einer Produktionsfarm sichern und in Ihrer Testumgebung wiederherstellen. Fügen Sie dann die Datenbanken an, um die Inhalte in die Farm zu übertragen. Immer wenn Sie Tests auf erfundene Daten oder Beispieldaten anwenden, besteht das Risiko, dass die Ergebnisse aufgrund von Unterschieden der gesammelten Inhalte verfälscht werden.Wenn Sie Beispieldaten erstellen müssen, sollten Sie die folgenden Aspekte für die Inhalte berücksichtigen:Alle Seiten sollten veröffentlicht sein; es sollten keine Inhalte ausgecheckt sein.Die Navigation sollte realistisch sein; erstellen Sie nicht mehr als das, was Sie normalerweise in einer Produktionsumgebung verwenden würden.Sie sollten eine Vorstellung von den Anpassungen haben, die in der Produktionswebsite verwendet werden. So sollten beispielsweise Gestaltungsvorlagen, Stylesheets, JavaScript usw. so eng wie möglich in der Produktionsumgebung implementiert sein. Bestimmen Sie die Anzahl der erforderlichen SharePoint-Gruppen und/oder Berechtigungsebenen und wie Benutzer diesen zugeordnet werden.Stellen Sie fest, ob Profile importiert werden müssen, und wie lange dies ggf. dauert.Finden Sie heraus, ob Benutzergruppen benötigt werden, wie diese ggf. erstellt und aufgefüllt werden. Legen Sie fest, ob zusätzliche Inhaltsquellen für Suchen erforderlich sind und was Sie benötigen, um diese zu erstellen. Wenn Sie keine Inhaltsquellen erstellen müssen, finden Sie heraus, ob Sie Netzwerkzugang haben, um sie zu durchforsten. Stellen Sie fest, ob ausreichend Beispieldaten vorhanden sind - Dokumente, Listen, Listenelemente usw. Erstellen Sie andernfalls einen Plan dafür, wie Sie diese Inhalte erstellen.Erstellen Sie einen Plan, damit ausreichend eindeutige Inhalte im Rahmen der Tests durchsucht werden können. Häufig wird der Fehler gemacht, dass dasselbe Dokument sogar hundert- oder tausendfach unter unterschiedlichen Namen in verschiedene Dokumentbibliotheken hochgeladen wird. Dies kann sich auf die Suchleistung auswirken, da der Suchprozessor beträchtliche Zeit mit der Erkennung von Duplikaten verbringt, was in einer Produktionsumgebung mit tatsächlichen Inhalten nicht notwendig wäre.Erstellen von Tests und ToolsNach dem Einrichten der Testumgebung ist es Zeit, die Tests zu erstellen und zu optimieren, die für die Messung der Leistungskapazität der Farm verwendet werden. In diesem Abschnitt wird gelegentlich spezifisch auf Visual Studio Team System (Team Test Load Agent) verwiesen, doch können viele der Konzepte unabhängig vom verwendeten Auslastungstool angewendet werden. Weitere Informationen zu Visual Studio Team System finden Sie unter Visual Studio Team System im MSDN (http://msdn.microsoft.com/de-de/library/fda2bad5.aspx" ).Sie können auch das SharePoint LoadTesting Kit (LTK) zusammen mit VSTS für die Durchführung von Auslastungstests von SharePoint 2010-Farmen verwenden. Mit dem LoadTesting Kit wird ein Visual Studio Team System 2008-Auslastungstest auf der Grundlage von Windows SharePoint Services 3.0- und Microsoft Office SharePoint Server 2007-IIS-Protokollen generiert. Der VSTS-Auslastungstest kann verwendet werden, um als Bestandteil der Kapazitätsplanungsübung oder des Stresstests vor dem Upgrade eine synthetische Last für SharePoint Foundation 2010 oder SharePoint Server 2010 zu generieren.Das LoadTesting Kit gehört zum Lieferumfang des Microsoft SharePoint 2010 Administration Toolkit Version 1.0, das im Microsoft Download Center (http://www.microsoft.com/downloads/details.aspx?familyid=718447d8-0814-427a-81c3-c9c3d84c456e&displaylang=de-de) verfügbar ist.Ein wesentliches Kriterium für den Erfolg der Tests ist die Fähigkeit, eine realistische Arbeitslast zu simulieren, indem Anforderungen für die unterschiedlichsten Testwebsitedaten generiert werden, so als würden Benutzer auf die unterschiedlichsten Inhalte einer SharePoint Server 2010-Farm im Produktionsbetrieb zugreifen. Dazu müssen Sie die Tests in der Regel so konstruieren, dass sie datengesteuert sind. Anstatt Hunderte individueller hardcodierter Tests zu erstellen, die auf eine bestimmte Seite zugreifen, sollten Sie nur einige wenige Tests verwenden, die Datenquellen mit den URLs für diese Elemente enthalten, um dynamisch auf diese Gruppe von Seiten zuzugreifen.In Visual Studio Team System (Team Test Load Agent) kann eine Datenquelle die unterschiedlichsten Formate aufweisen, doch sind CSV-Dateien häufig am einfachsten zu verwalten und zwischen Entwicklungs- und Testumgebungen zu transportieren. Wenn CSV-Dateien mit solchen Inhalten erstellt werden, ist es eventuell notwendig, benutzerdefinierte Tools zum Aufzählen der SharePoint Server 2010-basierten Umgebung und Aufzeichnen der verschiedenen URLs zu erstellen.Möglicherweise benötigen Sie Tools für Aufgaben wie die folgenden:Erstellen von Benutzern und Gruppen in Active Directory oder anderen Authentifizierungsspeichern bei Verwendung der formularbasierten AuthentifizierungAufzählen von URLs für Websites, Listen und Bibliotheken, Listenelemente, Dokumente usw. sowie Übertragen in CSV-Dateien für AuslastungstestsHochladen von Beispieldokumenten für verschiedene Dokumentbibliotheken und WebsitesErstellen von Websitesammlungen, Webs, Listen, Bibliotheken, Ordner und ListenelementenErstellen von "Meine Websites"Erstellen von CSV-Dateien mit Benutzernamen und Kennwörtern für Testbenutzer. Dies sind die Benutzerkonten, über die die Auslastungstests ausgeführt werden. Es sollten mehrere Dateien vorhanden sein, sodass einige beispielsweise nur Administratorbenutzer enthalten, einige Benutzer mit erhöhten Rechten (wie z. B. Autor/Mitwirkender, Hierarchie-Manager usw.) und andere wiederum nur Leser usw.Erstellen einer Liste von Beispielstichwörtern und -begriffen für die SucheAuffüllen von SharePoint-Gruppen und Berechtigungsebenen mit Benutzern und Active Directory-Gruppen (oder Rollen bei Verwendung der formularbasierten Authentifizierung)Beim Erstellen der Webtests sollten Sie u. a. die folgenden optimalen Methoden beachten und implementieren:Aufzeichnen einfacher Webtests als Ausgangspunkt. Diese Tests enthalten hartcodierte Werte für Parameter wie URLs und IDs usw. Ersetzen Sie diese hartcodierten Werte durch Hyperlinks aus Ihren CSV-Dateien. Die Datenbindung dieser Werte ist in Visual Studio Team System (Team Test Load Agent) äußerst einfach.Festlegen von Gültigkeitsregeln für die Tests. Wenn beispielsweise eine Seite angefordert wird, erhalten Sie als Antwort auf einen Fehler oft die Seite error.aspx. Aus Webtestperspektive handelt es sich einfach um eine weitere positive Antwort, da in den Auslastungstestergebnissen der HTTP-Statuscode 200 (erfolgreich) angezeigt wird. Offensichtlich ist jedoch ein Fehler aufgetreten, der anderweitig nachverfolgt werden sollte. Durch eine oder mehrere Gültigkeitsregeln können Sie bestimmten, als Antwort gesendeten Text abfangen, sodass die Überprüfung nicht erfolgreich ausgeführt und die Anforderung als Fehler gekennzeichnet wird. In Visual Studio Team System (Team Test Load Agent) kann als einfache Gültigkeitsregel ResponseUrl bei der Überprüfung verwendet werden. Dabei wird ein Fehler ausgegeben, wenn die nach Umleitungen gerenderte Seite nicht dieselbe Antwortseite ist, die im Test aufgezeichnet wurde. Sie können auch eine FindText-Regel hinzufügen, bei der ein Fehler aufgezeichnet wird, wenn der Ausdruck "Zugriff verweigert" beispielsweise in der Antwort gefunden wird.Verwenden von mehreren Benutzern in verschiedenen Rollen für Tests. Verschiedene Verhalten, wie z. B. das Zwischenspeichern der Ausgabe wird abhängig von den Rechten des jeweiligen Benutzers unterschiedlich gehandhabt. So erhalten beispielsweise ein Websitesammlungsadministrator oder ein authentifizierter Benutzer mit Genehmigungs- oder Dokumenterstellungsrechten keine zwischengespeicherten Ergebnisse, da es ihnen stets möglich sein sollte, auf die aktuellste Version von Inhalten zuzugreifen. Anonyme Benutzer hingegen erhalten zwischengespeicherte Inhalte. Sie müssen sicherstellen, dass es sich bei den Testbenutzern um eine Kombination dieser Rollen handelt, die in etwa der Zusammenstellung der Benutzer in der Produktionsumgebung entspricht. Wenn beispielsweise in einer Produktionsumgebung nur zwei oder drei Websitesammlungsadministratoren vorkommen, sollten Sie keine Tests erstellen, bei denen 10% der Seitenanforderungen von Benutzerkonten stammen, die Websitesammlungsadministratoren für die Testinhalte sind.Die Analyse abhängiger Anforderungen ist ein Attribut von Visual Studio Team System (Team Test Load Agent), das bestimmt, ob der Test-Agent versuchen sollte, nur die Seite oder die Seite einschließlich aller zugehörigen Anforderungen, die Teil der Seite sind, abzurufen, wie z. B. Bilder, Stylesheets und Skripts usw. Beim Testen der Auslastung werden diese Elemente in der Regel aus verschiedenen Gründen ignoriert:Nach dem erstmaligen Zugreifen eines Benutzers auf eine Website werden diese Elemente häufig vom lokalen Browser zwischengespeichertDie Elemente stammen in einer SharePoint Server 2010-basierten Umgebung in der Regel nicht von SQL Server. Wenn der BLOB-Cache aktiviert ist, werden sie vielmehr von den Webservern bereitgestellt, sodass keine SQL Server-Last generiert wird.Wenn der Prozentsatz der Benutzer Ihrer Website, die diese erstmalig besuchen hoch ist, oder wenn Sie die Browserzwischenspeicherung deaktiviert haben oder aus einem sonstigen Grund nicht vorhaben, den BLOB-Cache zu verwenden, kann es sinnvoll sein, die Analyse abhängiger Anforderungen in Ihren Tests zu aktivieren. Für die meisten Implementierungen stellt dies jedoch tatsächlich eine Ausnahme und nicht die Regel dar. Durch Aktivieren der Funktion können die vom Testcontroller gemeldeten RPS-Zahlen deutlich ansteigen. Diese Anforderungen werden so schnell bereitgestellt, dass Sie möglicherweise zu dem trügerischen Schluss gelangen, dass mehr Kapazität in der Farm verfügbar ist als tatsächlich vorhanden.Denken Sie daran, auch die Aktivität von Clientanwendungen zu modellieren. Auch durch Clientanwendungen, wie Microsoft Word, PowerPoint, Excel und Outlook, werden Anforderungen für SharePoint Server 2010-Farmen generiert. Durch Senden der Serveranforderungen, wie z. B. beim Abrufen von RSS-Feeds, Abrufen thematischer Informationen, Anfordern von Details zur Website- und Listenstruktur und Synchronisieren von Daten usw., steigt die Auslastung innerhalb der Umgebung. Diese Anforderungstypen sollten berücksichtigt und modelliert werden, wenn diese Clients Teil Ihrer Implementierung sind.In den meisten Fällen sollte ein Webtest nur eine einzelne Anforderung enthalten. Die Optimierung und Problembehandlung der Testumgebung und einzelner Anforderungen ist einfacher, wenn der Test nur eine einzelne Anforderung enthält. Webtests müssen in der Regel mehrere Anforderungen enthalten, wenn der simulierte Vorgang auf mehreren Anforderungen zusammen gesetzt ist. Wenn Sie beispielsweise diese Reihe von Aktionen testen möchten, benötigen Sie einen aus mehreren Schritten bestehenden Test: Auschecken eines Dokuments, Bearbeiten des Dokuments, Einchecken und Veröffentlichen. Ebenfalls erforderlich ist es, zwischen den Schritten den Zustand zu erhalten. So sollte beispielsweise dasselbe Benutzerkonto für das Auschecken, Bearbeiten und Einchecken verwendet werden. Solche Vorgänge aus mehreren Schritten, die erfordern, dass zwischen den einzelnen Schritten der Zustand erhalten bleibt, werden am besten mit mehreren Anforderungen in einem einzelnen Webtest durchgeführt.Führen Sie jeden Webtest einzeln aus. Stellen Sie sicher, dass jeder Test erfolgreich beendet werden kann, ehe er innerhalb eines umfangreicheren Auslastungstests ausgeführt wird. Überprüfen Sie, dass alle Namen für Webanwendungen aufgelöst werden und die im Test verwendeten Benutzerkonten über ausreichende Rechte für die Ausführung des Tests verfügen.Webtests umfassen die Anforderungen nach einzelnen Seiten, das Hochladen von Dokumenten und das Anzeigen von Listenelementen usw. Diese werden in Auslastungstests alle kombiniert. Ein Auslastungstest ist eine Kombination der verschiedenen Webtests, die ausgeführt werden sollen. Jedem Webtest wird ein Prozentsatz der Zeit für die Ausführung eingeräumt. Wenn Sie beispielsweise feststellen, dass 10% der Anforderungen in einer Produktionsfarm Suchabfragen sind, konfigurieren Sie einen Abfragewebtest für den Auslastungstest, der 10% der Zeit ausgeführt wird. In Visual Studio Team System (Team Test Load Agent) befassen sich Auslastungstests auch mit der Konfiguration von Faktoren wie der Browsermischung, der Netzwerkmischung, Auslastungsmustern und Ausführungseinstellungen. Für Auslastungstests sollten zusätzlich die folgenden optimalen Methoden beachtet und implementiert werden:Verwenden eines angemessenen Lese-/Schreibverhältnisses bei den Tests. Eine überhöhte Anzahl von Schreibvorgängen kann sich deutlich auf den Gesamtdurchsatz eines Tests auswirken. Selbst Farmen für die Zusammenarbeit tendieren zu Lese-/Schreibverhältnissen mit deutlich mehr Lese- als Schreibvorgängen. Weitere Informationen finden Sie unter Abschätzen von Leistungs- und Kapazitätsanforderungen (Office SharePoint Server).Berücksichtigen der Auswirkungen anderer ressourcenintensiver Vorgänge und Festlegen, ob diese während des Auslastungstests ausgeführt werden sollen. So werden beispielsweise Vorgänge wie Sichern und Wiederherstellen im Allgemeinen nicht während eines Auslastungstests ausgeführt. Eine vollständige Durchforstung sollte in der Regel nicht während eines Auslastungstests ausgeführt werden, während eine inkrementelle Durchforstung nicht ungewöhnlich ist. Überlegen Sie sich, wie der Zeitplan für diese Aufgaben in der Produktion aussieht - werden sie zu Spitzenauslastungszeiten ausgeführt? Wenn dies nicht der Fall ist, sollten sie vermutlich von den Auslastungstests ausgenommen werden, wenn Sie versuchen, die maximale Auslastung bei gleichbleibendem Zustand zu ermitteln, die zu Spitzenzeiten unterstützt werden kann.Keine Verwendung von Reaktionszeiten. Reaktionszeiten sind ein Feature von Visual Studio Team System (Team Test Load Agent), das die Simulierung des Zeitraums ermöglicht, den ein Benutzer zwischen dem Klicken auf einer Seite verstreichen lässt. So lädt beispielsweise ein typischer Benutzer möglicherweise eine Seite, verbringt drei Minuten mit Lesen und klickt dann auf eine Verknüpfung auf der Seite, um eine andere Site zu besuchen. Die korrekte Modellierung in einer Testumgebung ist beinahe unmöglich und bringt den Testergebnissen keinen zusätzlichen Wert. Die Modellierung ist deshalb so schwierig, da die meisten Organisationen keine Möglichkeit haben, verschiedene Benutzer und den Zeitraum zwischen Klicks in verschiedenen Typen von SharePoint-Websites zu überwachen (wie z. B. Veröffentlichungssites im Gegensatz zu Websites für die Zusammenarbeit usw.). Darüber hinaus stellt die Modellierung keinen tatsächlichen Mehrwert dar, da ein Benutzer zwar zwischen Seitenanforderungen pausiert, SharePoint Server 2010-basierte Server jedoch nicht. Sie erhalten nur einen konstanten Strom von Anforderungen mit Spitzen und Senken im Laufe der Zeit, verbringen jedoch keine Zeit im Leerlauf, so wie Benutzer zwischen dem Klicken auf Hyperlinks auf einer Seite pausieren.Kenntnisse über den Unterschied zwischen Benutzern und Anforderungen. Visual Studio Team System (Team Test Load Agent) weist ein Auslastungsmuster auf, bei dem Sie zur Eingabe der Anzahl der simulierenden Benutzer aufgefordert werden. Dies hat nichts mit den Anwendungsbenutzern zu tun, vielmehr geht es nur um die Anzahl der Threads, die von den Auslastungstest-Agents zum Generieren von Anforderungen verwendet werden. Ein häufiger Fehler besteht darin, anzunehmen, dass bei einer Bereitstellung für 5.000 Benutzer die Zahl 5.000 in Visual Studio Team System (Team Test Load Agent) verwendet werden sollte - was nicht der Fall ist. Dies ist einer der zahlreichen Gründe, weshalb bei der Schätzung der Anforderungen für die Kapazitätsplanung die Verwendungsanforderungen auf der Anzahl der Anforderungen pro Sekunde und nicht der Anzahl von Benutzern basieren sollten. Bei einem Visual Studio Team System (Team Test Load Agent)-Auslastungstest werden Sie feststellen, dass häufig Hunderte von Anforderungen pro Sekunde bei nur 50 bis 75 Auslastungstest-"Benutzern" generiert werden.Verwenden eines konstanten Auslastungsmusters für zuverlässige und reproduzierbare Testergebnisse. In Visual Studio Team System (Team Test Load Agent) haben Sie die Option, die Auslastung für eine konstante Anzahl von Benutzern (Threads, wie im vorherigen Punkt erläutert), ein intensiviertes Benutzerauslastungsmuster oder einen zielbasierten Verwendungstest zu simulieren. Ein intensiviertes Auslastungsmuster bedeutet, dass Sie mit einer niedrigeren Anzahl von Benutzern beginnen und alle paar Minuten zusätzliche Benutzer hinzufügen. Bei einem zielbasierten Verwendungstest wird ein Schwellenwert für einen bestimmten Diagnoseindikator, wie die CPU-Auslastung, eingerichtet und Versuche getestet, die Auslastung so zu halten, dass der Leistungsindikator sich zwischen den definierten Mindest- und Höchstschwellenwerten bewegt. Wenn Sie jedoch nur den maximalen Durchsatz der SharePoint Server 2010-Farm während Spitzenauslastungszeiten ermitteln möchten, ist es sinnvoller und genauer, nur ein konstantes Auslastungsmuster auszuwählen. Damit können Sie die auf das System anwendbare Auslastung einfacher bestimmen, ehe die Schwellenwerte, die in einer fehlerfreien Farm eingehalten werden sollten, regelmäßig überschritten werden.Bei der Ausführung eines Auslastungstests sollten Sie bedenken, dass Daten in der Datenbank geändert werden. Unabhängig davon, ob Dokumente hochgeladen, Listenelemente bearbeitet oder nur Aktivitäten in der Verwendungsdatenbank aufgezeichnet werden, werden Daten auf SQL Server geschrieben. Um konsistente und seriöse Testergebnisse aus den einzelnen Auslastungstests zu erhalten, sollten Sie vor der Ausführung des ersten Auslastungstests eine Sicherung erstellen. Nach jedem einzelnen Auslastungstest sollte der Inhalt mithilfe der Sicherung so wiederhergestellt werden, wie er zu Beginn des Tests vorlag.