Die folgende Tabelle enthält Angaben zur Hardware der
Werbung
Kapazitätsplanung für Microsoft SharePoint 2010 „Meine Website“- und Communityfeatures Dieses Dokument wird „wie besehen“ bereitgestellt. Die in diesem Dokument enthaltenen Informationen und Ansichten, einschließlich URLs und Verweise auf Internetwebsites, können ohne vorherige Ankündigung geändert werden. Das Risiko der Nutzung liegt bei Ihnen. Einige der hier beschriebenen Beispiele dienen ausschließlich der Veranschaulichung und sind rein fiktiv. Eventuelle Ähnlichkeiten mit realen Unternehmen, Organisationen, Produkten, Domänenamen, E-MailAdressen. Logos, Personen, Orten oder Ereignissen sind Zufall und unbeabsichtigt. Mit diesem Dokument werden keine Rechte an geistigem Eigentum an einem Microsoft-Produkt auf Sie übertragen. Sie sind berechtigt, dieses Dokument zu kopieren und für eigene interne Referenzzwecke zu nutzen. © 2010 Microsoft Corporation. Alle Rechte vorbehalten. Kapazitätsplanung für Microsoft SharePoint 2010 „Meine Websites“- und Communityfeatures Gaurav Doshi, Wenyu Cai Microsoft Corporation Gilt für: Microsoft SharePoint Server 2010 Zusammenfassung: Dieses Whitepaper bietet Anleitungen zur Leistungs- und Kapazitätsplanung für ein „Meine Websites“- und Communityportal auf Grundlage von Microsoft SharePoint 2010. In diesem Dokument wird Folgendes behandelt: Vorgaben für Testumgebungen, z. B. Hardware, Farmtopologie und Konfiguration Dataset für Testfarmen Testdaten und Empfehlungen für die Bestimmung der Hardware, Topologie und Konfiguration für die Bereitstellung einer vergleichbaren Umgebung sowie für die Optimierung der Umgebung für entsprechende Kapazitäts- und Leistungsanforderungen Inhaltsverzeichnis Zusammenfassung …………………………………………………………………………………………………………………………4 Einführung .................................................................................................................................... 5 Szenario ................................................................................................................................................ 5 Annahmen und Voraussetzungen ........................................................................................................ 5 Glossar .................................................................................................................................................. 5 Übersicht ...................................................................................................................................... 7 Skalierungsansatz ................................................................................................................................. 7 Korrelieren der Testumgebung mit einer Produktionsumgebung ....................................................... 7 Hinweise zu den Tests .......................................................................................................................... 8 Testeinrichtung.…………………………………………………………………………………………………………………………………..9 Hardware .............................................................................................................................................. 9 Software ............................................................................................................................................... 9 Topologie und Konfiguration.............................................................................................................. 10 Dataset und Volumegeometrie .......................................................................................................... 11 Transaktionsmischung ........................................................................................................................ 12 Ergebnisse und Analyse ............................................................................................................... 15 Vergleich aller Testläufe ..................................................................................................................... 15 Auswirkungen der Suchdurchforstung nach Personen ....................................................................... 19 Analyse ............................................................................................................................................... 20 Empfehlungen ...................................................................................................................... ......23 Anhang ..................................................................................................................................... ..24 Zusammenfassung Dieses Dokument enthält vor allem die Ergebnisse unserer Tests des „Meine Websites“- und Commuityportals: - - - - - Die Umgebung wurde auf acht Front-End-Webserver für einen Anwendungsserver und einen Datenbankserver vertikal skaliert, was zu einer nahezu linearen Steigerung des Durchsatzes führte. Das Hinzufügen von noch mehr Front-End-Webservern führte zu keiner weiteren Durchsatzsteigerung, da die Auslastung der Datenbankserver-CPU an diesem Punkt einen Engpass darstellte. Eine weitere Skalierung kann erreicht werden, indem die Inhaltsdatenbank und Dienstdatenbank auf zwei getrennte Datenbankserver ausgelagert werden. Bei der 8 x 1 x 2-Topologie haben wir die Leistungsgrenze erreicht. An diesem Punkt wurde die CPU-Auslastung von sowohl dem Front-End-Webserver als auch dem Anwendungsserver zu einem Engpass. Dies führt uns zu der Annahme, dass bei der vorliegenden Hardware, Testarbeitslast und dem Dataset der Maximalwert für Anforderungen pro Sekunde (APS) für 8x1x2 sich auf 1877 beläuft. Bei Untersuchung der Trends scheint es möglich, denselben Durchsatz mit einer stabilen Farm zu erreichen, sofern die Engpässe auf dem Front-End-Webserver und Anwendungsserver beseitigt werden. Der Front-End-Webserver-Engpass kann durch Hinzufügen weiterer FrontEnd-Webserver und der Anwendungsserverengpass durch Verwenden zweier Computer beseitigt werden, die die Rollen von Anwendungsservern übernehmen. Das haben wir allerdings nicht in der Testumgebung ausprobiert. Durchsatz und Hardwarevariationen haben keinen Einfluss auf die Latenz. Wenn die Einschränkung aus Sicherheitsgründen aktiviert ist, kann ein Front-End-Webserver ca. 8-10 APS durch Datenverkehr vom Outlook Connector für soziale Netzwerke unterstützen. Dies bedeutet, dass ein Front-End-Webserver ca. 28.000 bis 36.000 Mitarbeiter unterstützen kann, die den Outlook Connector für soziale Netzwerke den ganzen Tag nutzen. Wenn Sie also den Outlook Connector für soziale Netzwerke für 100.000 Mitarbeiter bereitstellen, können Sie den Datenverkehr unterstützen, der von drei Front-End-Webservern generiert wird. Diese Werte können je nach Nutzung von Communitytags in Ihrem Unternehmen variieren. Wenn Sie davon ausgehen, dass in Ihrem Unternehmen Communitytags weniger genutzt werden als in unserer Testumgebung, erhalten Sie ggf. einen besseren Durchsatz pro Front-End-Webserver. Die inkrementelle Suchdurchforstung nach Personen hat keine wesentlichen Auswirkungen auf den Durchsatz der Farm, solange die Farm einen stabilen Status hat. Einführung Szenario In diesem Dokument werden die Testmethodik und Ergebnisse vorgestellt, die Sie als Richtlinien für die Kapazitätsplanung eines Communityportals nutzen können. Ein Communityportal ist eine Microsoft SharePoint 2010-Bereitstellung, bei der jeder Mitarbeiter im Unternehmen über ein Benutzerprofil verfügt, die gesuchten Fachleute im Unternehmen finden kann, sich über Newsfeeds mit anderen Mitarbeitern verbindet und eine persönliche Website für die Speicherung und Freigabe von Dokumenten hat. Zusätzlich zu diesem durch Communityfunktionen verursachten Datenverkehr gibt es noch eine erhebliche Menge an typischem durch Zusammenarbeit verursachten Datenverkehr, wenn Mitarbeiter Dokumente auf ihre persönlichen Websites hochladen, freigeben, anzeigen und aktualisieren. Wir gehen davon aus, dass diese Ergebnisse beim Entwerfen eines separaten Portals hilfreich sind, das für „Meine Websites“- und Communityfunktionen genutzt wird. Unterschiedliche Szenarien haben unterschiedliche Anforderungen, weshalb es erforderlich ist, diese Anleitung durch weitere Tests auf Ihrer eigenen Hardware und in Ihrer eigenen Umgebung zu ergänzen. Nach der Lektüre dieses Dokuments sind Sie in der Lage, folgende Aufgaben auszuführen: Bestimmen der Hardware, die zur Unterstützung der gewünschten Skalierung erforderlich ist: Anzahl der Benutzer, Verarbeitungslast und aktivierte Features. Entwerfen der physischen und logischen Topologie, um eine optimale Zuverlässigkeit und Effizienz sicherzustellen. Auf Hochverfügbarkeit/Notfallwiederherstellung wird in diesem Dokument nicht eingegangen. Berücksichtigen der Auswirkungen der laufenden Suchdurchforstung nach Personen und von Profilsynchronisierungen auf den APS-Wert einer Communityportalbereitstellung Vor dem Lesen dieses Artikels sollten Sie sich mit Folgendem vertraut machen: Kapazitätsplanung und Größenbestimmung für Microsoft SharePoint 2010-Produkte und Technologien Office SharePoint Server 2010-Softwarebeschränkungen Abschätzen von Leistungs- und Kapazitätsanforderungen (Office SharePoint Server) (steht auf der TechNet-Website zum Download bereit) Wenn Sie sich für eine Anleitung zur Kapazitätsplanung für typische Zusammenarbeitsszenarien interessieren, lesen Sie: Abschätzen von Leistungs- und Kapazitätsanforderungen (Office SharePoint Server) Annahmen und Voraussetzungen In diesem Szenario wird in der Communityportalbereitstellung kein benutzerdefinierter Code ausgeführt. Wir können das Verhalten von benutzerdefiniertem Code oder Drittanbieterlösungen, die in Ihrem „Meine Websites“- und Communityportal installiert werden, nicht garantieren. Der Authentifizierungsmodus war NTLM. Glossar In diesem Dokument werden verschiedene Fachbegriffe verwendet. Es folgen die entsprechenden Definitionen: APS: Anforderungen pro Sekunde. Die Anzahl der Anforderungen, die von einer Farm oder einem Server in einer Sekunde empfangen werden. Dies ist ein gängiges Maß für die Verarbeitungslast von Servern und Farmen. Beachten Sie, dass zwischen Anforderungen und dem Laden von Seiten ein Unterschied besteht. Jede Seite enthält verschiedene Komponenten, durch die beim Laden der Seite eine oder mehrere Anforderungen erstellt werden. Deshalb werden beim Laden einer einzelnen Seite verschiedene Anforderungen erstellt. In der Regel werden beim Messen des APS-Werts Überprüfungen der Authentifizierung und Ereignisse, die wenig Ressourcen benötigen, nicht berücksichtigt. Grüner Bereich: Dies ist der Zustand, in dem der Server die folgenden Kriterien einhalten kann: o Die serverseitige Latenz beträgt bei mindestens 75 % der Anforderungen weniger als 0,5 Sekunden. o Alle Server weisen eine CPU-Auslastung von weniger als 50 % auf. Hinweis: Da in dieser Testumgebung keine aktive Suchdurchforstung ausgeführt wird, wurde die CPU-Auslastung des Datenbankservers auf maximal 40 % begrenzt, um 10 % für die Suchdurchforstungslast zu reservieren. Dies setzt voraus, dass die Microsoft SQL Server-Ressourcenkontrolle in der Produktionsumgebung eingesetzt wird, um die Suchdurchforstungslast auf 10 % der CPU-Leistung zu begrenzen. o Die Fehlerrate ist niedriger als 0,01 %. Maximalbereich: Dies ist der Zustand, in dem der Server die folgenden Kriterien einhalten kann: o Die HTTP-Anforderungseinschränkung ist aktiviert, ohne dass Fehler vom Typ 503 (Server ausgelastet) zurückgegeben werden. o Die Fehlerrate ist niedriger als 0,1 %. o Die serverseitige Latenz beträgt bei mindestens 75 % der Anforderungen weniger als 1 Sekunde. o Die CPU-Auslastung des Datenbankservers ist unter 80 %, sodass 10 % für die Suchdurchforstungslast reserviert werden können, was mithilfe der SQL ServerRessourcenkontrolle begrenzt wird. AxBxC (Graphnotation): Dies ist die Anzahl der Webserver, Anwendungsserver und Datenbankserver in einer Farm. 8x1x2 bedeutet beispielsweise, dass diese Umgebung acht Webserver, einen Anwendungsserver und zwei Datenbankserver enthält. VSTS-Last: Von Visual Studio Team System (VSTS) zum Simulieren virtueller Benutzer intern verwendete Threads. Wir haben VSTS verstärkt eingesetzt, um stetig immer mehr APS für die Topologie zu generieren. Übersicht Skalierungsansatz In diesem Abschnitt wird die spezifische Reihenfolge vorgestellt, die wir für die Skalierung von Computern in Ihrer Umgebung empfehlen. Denselben Ansatz haben wir auch bei der Skalierung dieser Testumgebung befolgt. Dieser Ansatz ermöglich Ihnen das Bestimmen der optimalen Konfiguration für Ihre Verarbeitungslast und kann wie folgt beschrieben werden: 1. Als Erstes haben wir die Webserver horizontal skaliert. Die horizontale Skalierung erfolgte unter der getesteten Verarbeitungslast so weit wie möglich, bis der Datenbankserver zu einem Engpass wurde und keine weiteren Anforderungen von den Webservern mehr erfüllen konnte. 2. Bis zu diesem Zeitpunkt befanden sich die Inhaltsdatenbank und Dienstdatenbanken (Benutzerprofildatenbank, Datenbank für Funktionen und Daten für das soziale Netzwerk usw.) alle auf demselben Datenbankserver. Als wir erkannten, dass der Datenbankserver der Engpass war, haben wir diesen horizontal skaliert, indem die Inhaltsdatenbanken auf einen anderen Datenbankserver verschoben wurden. Bis zu diesem Zeitpunkt generierten die Webserver nicht genügend Last für die Datenbankserver, weshalb diese noch weiter horizontal skaliert wurden. 3. In der Testumgebung haben wir die horizontale Skalierung nicht noch weiter getestet. Wenn Sie jedoch noch eine weitere Skalierung benötigen, ist der nächste logische Schritt der Einsatz von zwei Computern, die Anwendungsserveraufgaben übernehmen. Wir begannen mit einer minimalen Farmkonfiguration mit einem Front-End-Webserver, einem Anwendungsserver und einem Computer mit SQL Server (Datenbankserver). Nach mehreren Durchläufen mit verschiedenen Konfigurationen endeten wir bei einer Farmkonfiguration mit acht Front-End-Servern, einem Anwendungsserver und zwei Datenbankservern mit SQL Server. Im Abschnitt „Ergebnisse und Analyse“ finden Sie einen Vergleich der Leistungseigenschaften für „Grüner Bereich“ und „Maximalbereich“ bei den jeweiligen Testdurchläufen. Weitere Einzelheiten dazu finden Sie im Anhang. Korrelieren der Testumgebung mit einer Produktionsumgebung Die in diesem Dokument beschriebene Testumgebung ist ein verkleinertes Modell einer Produktionsumgebung bei Microsoft. Wenngleich es wesentliche Unterschiede zwischen den beiden Umgebungen gibt, kann es nützlich sein, sie nebeneinander zu untersuchen, da beide „Meine Website“und Communityumgebungen sind, deren Nutzungsmuster ähnlich sein sollten. Die Testumgebung enthält ein Dataset, das dem Dataset der Produktionsumgebung nahezu entspricht. Die Verarbeitungslast für Testzwecke entspricht zum Großteil der Verarbeitungslast der Produktionsumgebung. Dennoch gibt es auch wesentliche Unterschiede. Der wichtigste dieser Unterschiede ist, dass in der Testumgebung weniger individuelle Benutzer die Vorgänge ausführen. Außerdem werden im Vergleich zur Produktionsumgebung Vorgänge auf eine kleinere Anzahl von Benutzerprofilen angewendet. Ferner weisen die Testläufe in der Testumgebung eine kürzere Dauer auf. All dies hat Auswirkungen auf die Anzahl der Cachetreffer im Benutzerprofilcache, der auf dem Anwendungsserver verwaltet wird. Im Benutzerprofildienst werden auf dem Anwendungsserver zuletzt verwendete Benutzerprofile zwischengespeichert. Die Standardgröße dieses Caches ist 256 MB, was ungefähr 500.000 Benutzerprofilen entspricht. Da die Anzahl der in den Tests verwendeten Benutzerprofile auf 1500 begrenzt wurde und die Dauer der Tests kürzer als die Wiederverwendungszeit des Caches war, ergaben sich fast immer Cachetreffer. Aus diesem Grund sind die Durchsatzwerte in diesem Dokument meist eher hoch. Sie müssen jedoch definitiv mit fehlgeschlagenen Zugriffen auf den Cache in Ihrer Umgebung und deshalb mit einer niedrigeren Durchsatzrate rechnen. Eine detaillierte Fallstudie einer Produktionsumgebung mit einem „Meine Websites“- und Communityportal finden Sie unter Abschätzen von Leistungs- und Kapazitätsanforderungen (Office SharePoint Server). Hinweise zu den Tests In diesem Dokument werden Ergebnisse aus einer Testumgebung präsentiert. Da es sich um eine Testund nicht um eine Produktionsumgebung handelte, konnten wir verschiedene Faktoren steuern, um bestimmte Leistungsaspekte für diese Verarbeitungslast zu veranschaulichen. Außerdem wurden die in der folgenden Liste enthaltenen Elemente der Produktionsumgebung in der Testumgebung ausgelassen, um das Testen des Verarbeitungsaufwands zu vereinfachen. Das Weglassen dieser Elemente wird für Produktionsumgebungen nicht empfohlen. Zwischen den Testläufen haben wir immer nur eine Variable geändert, um das Vergleichen von Ergebnissen zwischen Testläufen zu erleichtern. Die in dieser Testumgebung eingesetzten Datenbankserver gehörten nicht zu einem Cluster, da Redundanz für diese Tests nicht erforderlich war. Suchdurchforstungen wurden im Verlauf der Tests nicht ausgeführt, was jedoch in einer Produktionsumgebung der Fall sein kann. Um dies zu berücksichtigen, haben wir die SQL Server-CPUAuslastung in unserer Definition von „Grüner Bereich“ und „Maximalbereich“ verringert, um die Ressourcen zu berücksichtigen, die eine Suchdurchforstung belegt hätte, wenn sie gleichzeitig mit unseren Tests ausgeführt worden wäre. Testeinrichtung Hardware Die folgende Tabelle enthält Angaben zur Hardware der Computer, die für diese Tests verwendet wurden. Alle Front-End-Webserver, die der Serverfarm bei den verschiedenen Testläufen hinzugefügt wurden, weisen dieselben technischen Daten auf. Front-End-Webserver Anwendungsserver Datenbankserver Servermodell PE 2950 PE 2950 Dell PE 6850 Prozessor(en) 2px4c @ 2,33 GHz 2px4c @ 2,33 GHz 4px4c @3,19 GHz Arbeitsspeicher (RAM) 8 GB 8 GB 32 GB Anzahl der Netzwerkkarten 2 2 1 Netzwerkkartengeschwindigkeit 1 Gigabit 1 Gigabit 1 Gigabit Lastenausgleichstyp F5 - Hardwaregerät zum Lastenausgleich – – Protokollierebene des vereinheitlichten Protokollierungsdiensts (ULS) Mittel Mittel – Tabelle 1: Hardwarespezifikationen für Servercomputer Software Die folgende Tabelle enthält die Software, die auf Servern in dieser Testumgebung installiert und ausgeführt wurde. Front-EndWebserver Anwendungsserver Datenbankserver Betriebssystem Windows Server 2008 R2 x64 Windows Server 2008 R2 x64 Windows Server 2008 x64 Softwareversion Microsoft SharePoint 4763.1000 (RTM), Office Web Applications 4763.1000 (RTM) Microsoft SharePoint 4763.1000 (RTM), WAC 4763.1000 (RTM) SQL Server 2008 R2 CTP3 Lastenausgleichstyp F5 - Hardwaregerät zum Lastenausgleich – – Protokollierebene des vereinheitlichten Protokollierungsdiensts (ULS) Mittel Mittel – Antivireneinstellungen Deaktiviert Deaktiviert Deaktiviert Tabelle 2: Softwarespezifikationen für Servercomputer Topologie und Konfiguration Im folgenden Topologiediagramm wird die Hardwareeinrichtung für die Tests veranschaulicht. Diagramm 1: Farmkonfiguration Diagramm 1 zeigt die Dienste, die in der Testumgebung bereitgestellt wurden. Dataset und Volumegeometrie Das Dataset der Testfarm bestand aus insgesamt 166,5 GB mit „Meine Website“-Inhalten (gleichmäßig verteilt auf 10 Inhaltsdatenbanken), 27,7 GB mit Profildatenbankinhalten, 3,7 GB mit Inhalten in der Datenbank für Funktionen und Daten für das soziale Netzwerk (GUIDs für Communitytags, Notizen und Bewertungen) und 0,14 GB mit Inhalten in der Datenbank zur Verwaltung von Metadaten (Text für Communitytags und dazugehörige GUIDs). In der folgenden Tabelle wird das Dataset detailliert beschrieben: Anzahl der Benutzerprofile Durchschnittliche Anzahl von Mitgliedschaften pro Benutzer Durchschnittliche Anzahl unterstellter Mitarbeiter pro Benutzer Durchschnittliche Anzahl von Kollegen pro Benutzer Gesamtanzahl der Profileigenschaften Gesamtanzahl mehrwertiger Eigenschaften Anzahl der Benutzergruppen Anzahl von „Meine Websites“ Anzahl der Blogwebsites Gesamtanzahl der Ereignisse im Aktivitätsfeed ~150.000 74 Anzahl der Communitytags/Bewertungen 5,04 Mio.** 6 28 101 21 130 ~10.000 ~600 798.000* Tabelle 3: Details zum Dataset * Eine Untersuchung zu Communitytags von del.icio.us ergab, dass ein aktiver Benutzer 4,2 Tags pro Monat erstellt. (Tags bedeutet hier eine beliebige Aktivität zum Zuweisen von Metadaten zu URLs und umfasst Stichworttags, Bewertungen und Notizen.) Ein aktiver Benutzer erstellt also pro Tag 0,14 Tags (4,2:30 = 0,14). Wenn angenommen 1/3 der Benutzer des Communityportals aktiv Tags erstellen, beträgt die Anzahl dieser Kategorisierungen 150.000:3x0,14 pro Tag. In Aktivitätsfeedtabellen werden Aktivitäten 14 Tage gespeichert, weshalb die Gesamtanzahl der Kategorisierungsaktivitäten in der Aktivitätsfeedtabelle 150.000:3x0,14x14 beträgt. Wenn wir zusätzlich zum Versehen von Ereignissen mit Tags davon ausgehen, dass ein aktiver Benutzer ein weiteres Ereignis pro Tag (z. B. eine Profileigenschaft- oder Statusaktualisierung) hinzufügt, werden Aktivitätsfeedtabellen 150.000:3x1x14 Ereignisse hinzugefügt. Demzufolge beträgt die Gesamtanzahl von Ereignissen in Aktivitätsfeedtabellen 150.000:3x1,14x14 = 798.000. Davon handelt es sich bei 98.000 Ereignissen um Kategorisierungsaktivitäten, die eine Einschränkung aus Sicherheitsgründen auslösen können. Die restlichen Ereignisse werden per Zufallsgenerator auf Statusaktualisierungen und Profileigenschaftsänderungen verteilt. ** Es wird angenommen, dass 1/3 der Benutzerschaft aktive Benutzer sind, von denen jeder 4,2 Tags pro Monat erstellt, wobei ein Tag ein Stichworttag, eine Notiz oder eine Bewertung sein kann. Wenn die Farm zwei Jahre genutzt wird, beläuft sich die Gesamtanzahl der Tags auf 150.000 : 3 x 4,2 x 12 x 2 = 5,04 Mio. In der folgenden Tabelle wird die Volumegeometrie detailliert beschrieben: Datenbank Datenbankgröße RAIDKonfiguration Inhaltsd -tenbank 1, 2, 3, 4 Inhaltsda -enbank 5, 6 Inhaltsda -tenbank 7, 8 Inhaltsda -tenbank 9, 10 61,4 GB 39 GB 32,3 GB 33,7 GB Profil 27,7 GB 0 0 0 0 0 Datenbank für Funktionen und Daten für das soziale Netzwerk Meta -daten 3,7 GB 0,14 0 0 Anzahl der Spindeln für MDF-Datei Anzahl der Spindeln für LDFDatei 1 1 1 1 6 1 1 eine physische Spindel wird von allen Datenbanken gemeinsam genutzt Tabelle 4: Details zur Volumegeometrie Transaktionsmischung Wichtige Hinweise Die Tests bilden lediglich die Kernzeitnutzung eines typischen Communityportals ab. Berücksichtigt wurden keine zyklischen Änderungen beim von Benutzern generierten Datenverkehr aufgrund von Tag-und-Nacht-Zyklen. Zeitgeberaufträge, die in großem Maß Ressourcen benötigen, z. B. Profilsynchronisierungen oder Durchforstungen zur Personensuche, wurden unabhängig voneinander mit derselben Testverarbeitungslast getestet, um ihre Auswirkungen auf die Benutzer zu bestimmen. Dieser Test legt den Schwerpunkt auf Communityvorgänge, wie z. B. Newsfeeds, Vergeben von Communitytags und Lesen von Benutzerprofilen. Es gibt auch in geringem Maß typischen durch Zusammenarbeit verursachten Datenverkehr, auf dem aber nicht der Fokus liegt. Wir gehen davon aus, dass diese Ergebnisse beim Entwerfen eines separaten Portals hilfreich sind, das für „Meine Websites“- und Communityfeatures genutzt wird. Die Testmischung enthält keinen Datenverkehr aus Suchdurchforstungen nach Inhalten. Dies wurde jedoch in unseren Tests berücksichtigt, indem die Definition „Grüner Bereich“ eine SQL Server-CPU-Auslastung von 40 % vorgibt (im Gegensatz zu den standardmäßigen 50 %), um 10 % für Suchdurchforstungen zu berücksichtigen. Gleichsam haben wir eine 80 %-ige SQL ServerCPU-Auslastung als Kriterium für einen maximalen APS-Wert verwendet. Zusätzlich zur Testmischung in der folgenden Tabelle haben wir auch acht APS pro Front-EndWebserver für den Datenverkehr durch den Outlook Connector für soziale Netzwerke hinzugefügt. Wir hatten die Einschränkung aus Sicherheitsgründen aktiviert und bemerkten eine Stressbelastung des Sicherheitstokendiensts, als wir ca. 8 APS an Datenverkehr durch den Outlook Connector für soziale Netzwerke auf einem Front-End-Webserver erreichten, um Aktivitäten von Kollegen zu berücksichtigen. Dies ist abhängig vom Dataset, der Testverarbeitungslast und Hardware, die wir in der Testumgebung genutzt haben, weshalb sich bei Ihnen ein vollständig anderes Verhalten ergeben kann. Um eine weitere Stressbelastung des Sicherheitstokendiensts zu vermeiden, entschlossen wir uns, Datenverkehr durch den Outlook Connector für soziale Netzwerke abhängig von der Anzahl der Front-End-Webserver bei jedem Konfigurationstestlauf hinzuzufügen. Bei einer 1x1x1-Konfiguration gibt es acht APS an Datenverkehr durch den Outlook Connector für soziale Netzwerke, bei einer 2x1x1Konfiguration ergeben sich 16 APS an Datenverkehr durch den Outlook Connector für soziale Netzwerke usw. Die folgende Tabelle zeigt die allgemeinen Transaktionsmischungen: Beschreibung Lesen/Schreiben % der Mischung Hinzufügen eines Kollegen Erstellen einer Bewertung für eine URL, Schreiben einer Notiz oder Versehen einer URL mit einem Tag Schreiben Listenvorgangsdokument Abrufen veröffentlichter Links zum Abbilden von Clientaufrufen von PublishedLinksService.asmx Abrufen von RSS-Feeds aus Listen Anzeigen aller Elemente in Dokumentbibliotheken und Listen in „Meine Website“ Anzeigen eines Blogbeitrags Anzeigen mehrere „Meine Website“-Seiten (Mein Inhalt, Kollegen, Newsfeed, Mein Profil, Profil eines anderen Benutzers, Organisations-Browser, Mitgliedschaften, Tags und Notizen) Synchronisierung gemeinsam genutzter OneNote-Dateien Bearbeiten meiner Profilseite oder Statusmeldung, Aktualisieren des Bilds Office Web Apps: Öffnen von und Bildläufe durch Dateien (PowerPoint, Word, Excel) Lesen/Schreiben 2,36 % Lesen Lesen 6,92 % 3,72 % Lesen Lesen 1,07 % 0,04 % Lesen Lesen 3,87 % 10,0 % Schreiben 2,31 % Lesen 0,13 % Listensynchronsierung mit Outlook Lesen Hochladen eines Dokuments Laden von Seiten, Dokumentbibliotheken, Ordnern aus der Inhaltsdatenbank Gemeinsame Dokumenterstellung Schreiben 2,11 % Schreiben 3,22 % 48,16 % 0,09 % Lesen Lesen/Schreiben 15,93 % 0,17 % Tabelle 5: Transaktionsmischung Zusätzliche Testmischung mit dem Outlook Connector für soziale Netzwerke zum Generieren von acht APS pro Front-End-Webserver: Automatische Synchronisierungen von Meine Kollegen Automatische Synchronisierungen der Newsfeeds von Meine Kollegen Lesen Lesen Tabelle 6: Testmischung für den Outlook Connector für soziale Netzwerke 4% 96 % Ergebnisse und Analyse Vergleich aller Testläufe Wie bereits erwähnt, begannen wir mit einer minimalen Farmkonfiguration mit einem Front-EndWebserver, einem Anwendungsserver und einem Computer mit SQL Server. Nach mehreren Durchläufen mit verschiedenen Konfigurationen endeten wir mit einer Farmkonfiguration mit acht Front-End-Servern, einem Anwendungsserver und zwei Computern mit SQL Server. Bei jedem dieser Testläufe erhöhten wir schrittweise die Belastung, um den grünen Bereich und Maximalbereich zu bestimmen. Einzelheiten zur schrittweisen Belastungssteigerung bei jedem Testdurchlauf finden Sie im Anhang. Im der folgenden Tabelle finden Sie einen Vergleich der Leistungseigenschaften für „Grüner Bereich“ und „Maximalbereich“ bei den jeweiligen Testdurchläufen. Die folgende Tabelle und die Diagramme bieten eine Übersicht für Vergleichs- und Analysezwecke. Ergebnisse für den grünen Bereich: Lassen Sie uns zunächst topologieübergreifend einen Blick auf die Leistungsmerkmale für den grünen Bereich werfen. Die folgende Tabelle zeigt eine Übersicht der Ergebnisse: Topologie Grüner Bereich - APS Grüner Bereich - 75. Quantil Latenz Grüner Bereich Front-End-WebserverCPU Grüner Bereich AnwendungsserverCPU Grüner Bereich - SQL Server-CPU 1x1x1 2x1x1 3x1x1 5x1x1 8x1x1 137,25 278,08 440,72 683,07 793,67 0,12 0,16 0,14 0,16 0,31 8x1x2 873,4 0,32 36,90 47,84 46,88 48,68 46,13 31,79 47,20 9,45 5,45 18,88 10,61 26,91 16,46 35,58 48,73 24,73 32,40 (17,9 für Inhaltsdatenbank und 14,5 für 30,03 Dienstdatenbank) Tabelle 7: Leistung im grünen Bereich Die folgende Abbildung zeigt Variationen bei der CPU-Auslastung und APS bei unterschiedlichen Topologien für Ergebnisse im grünen Bereich. 1000 60 50 800 700 40 600 500 30 400 20 300 200 % CPU-Auslastung Anforderungen pro Sekunde (APS) 900 Grüner Bereich – Web-FrontEnd-Server-CPU Grüner Bereich – Anwendungsserver-CPU Grüner Bereich – SQL ServerCPU 10 100 0 Grüner Bereich - APS 0 1x1x1 2x1x1 3x1x1 5x1x1 8x1x1 8x1x2 Topologie Informationen zum Diagramm: - - Durch Hinzufügen weiterer Computer zur Topologie wurde der APS-Wert durchgängig gesteigert. Es ist eindeutig, dass die Front-End-Webserver-CPU bei 5x1x1 der entscheidende Faktor für das Heranführen der Topologie an die Obergrenze des grünen Bereichs war. Bei 8x1x1 erreichte die Anwendungsserver-CPU die Obergrenze des grünen Bereichs, bevor die Front-End-Webserver die Obergrenze des grünen Bereichs erreichen konnten. Die SQL Server-CPU war bei allen Szenarien sehr stabil. Ergebnisse für den Maximalbereich: Die folgende Tabelle zeigt eine Übersicht der Ergebnisse aller Topologien für den Maximalbereich. 1x1x1 Maximalbereich - APS Maximalbereich - Latenz Maximalbereich - FrontEnd-Webserver-CPU Maximalbereich Anwendungsserver-CPU Maximalbereich - SQL Server-CPU 2x1x1 3x1x1 203,28 450,75 615,00 0,22 0,23 0,22 5x1x1 971,13 8x1x1 8x1x2 0,22 1655 0,31 75,13 78,17 70,00 67,02 67 12,97 27,07 28,40 48,28 67,1 1877 0,32 71,6 73,4 7,64 16,06 21,00 79,5 38,38 Tabelle 8: Ergebnisse aller Topologien für den Maximalbereich 74,9 (45,9 für Inhaltsdatenbank und 29 für Dienstdatenbank) Die folgende Abbildung zeigt Variationen bei der CPU-Auslastung und den APS bei unterschiedlichen Topologien für Ergebnisse im Maximalbereich. 90 1800 80 1600 70 1400 60 1200 50 1000 40 800 30 600 400 20 200 10 0 % CPU-Auslastung Anforderungen pro Sekunde (APS) 2000 Maximalbereich - APS Maximabereich – Web-FrontEnd-Server-CPU Maximalbereich – Anwendungsserver-CPU Maximalbereich – SQL ServerCPU 0 1x1x1 2x1x1 3x1x1 5x1x1 8x1x1 8x1x2 Topologie Informationen zum Diagramm: - Durch Hinzufügen weiterer Computer zur Topologie wurde der APS-Wert durchgängig gesteigert. Bei 5x1x1 war die Front-End-Webserver-CPU eindeutig der Engpass. Bei 8x1x1 wurde die SQL Server-CPU zum Engpass. Anfänglich war die Auslastung der Anwendungsserver-CPU höher als die der SQL Server-CPU. Doch es ist offenkundig, dass die Wachstumsrate der SQL Server-CPU-Auslastung höher als die der Anwendungsserver-CPU-Auslastung ist. Bei einem höheren Durchsatz überstieg die SQL Server-CPU-Auslastung die Anwendungsserver-CPU-Auslastung und wurde zum Engpass. Vergleich zwischen grünem Bereich und Maximalbereich: In den folgenden Diagrammen werden Durchsatz und Latenz von grünem Bereich und Maximalbereich bei unterschiedlichen Topologien verglichen. Anforderungen pro Sekunde (APS) 2000 1800 1600 1400 1200 1000 Grüner Bereich - APS 800 Maximalbereich - APS 600 400 200 0 1x1x1 2x1x1 3x1x1 5x1x1 8x1x1 8x1x2 Topologie 0.35 0.3 Latenz (Sek.) 0.25 0.2 0.15 Grüner Bereich - 75. Quantil Latenz 0.1 Maximalbereich - 75. Quantil Latenz 0.05 0 1x1x1 2x1x1 3x1x1 5x1x1 8x1x1 8x1x2 Topologie Informationen zum Diagramm: - Die Latenzzeiten ändern sich entsprechend dem Durchsatz oder der Topologie nicht wesentlich. In allen unseren Tests lag die Latzenzzeit unter 0,5 Sekunden, was überaus akzeptabel ist. Die Steigerung des Durchsatzes ist nahezu linear. Hinweis zu E/A-Vorgängen pro Sekunde: In der folgenden Tabelle und im nachfolgenden Diagramm werden die E/A-Vorgänge pro Sekunde in jeder Datenbank in den verschiedenen Topologien gezeigt. Die Datenträger-E/A war zu keiner Zeit ein Engpass, weshalb nach Analyse des Trends die Daten für spätere Topologien nicht aufgezeichnet wurden. 1x1x1 2x1x1 3x1x1 5x1x1 Maximalbereich Maximalbereich Maximalbereich Maximalbereich Lesevorgänge/Sek. (Inhaltsdatenbank) Lesevorgänge/Sek. (Profildatenbank) Lesevorgänge/Sek. (Datenbank für Funktionen und Daten für das soziale Netzwerk) Schreibvorgänge/Sek. (Inhaltsdatenbank) Schreibvorgänge/Sek. (Profildatenbank) Schreibvorgänge/Sek. (Datenbank für Funktionen und Daten für das soziale Netzwerk) 21.33 20.80 24.24 22.42 14,97 17,20 19,82 13,50 1,81 1,83 2,10 2,01 50,12 76,24 80,02 99,16 9,01 24,31 23,35 38,29 4,12 9,47 10,63 19,45 Tabelle 9: Gemessene E/A-Vorgänge pro Sekunde E/A-Vorgänge pro Sekunde pro Topologie Lesevorgänge/Sek. (Inhaltsdatenbank) 100.00 90.00 Lesevorgänge/Sek. (Profildatenbank) Vorgänge pro Sek. 80.00 70.00 60.00 Lesevorgänge/Sek. (Datenbank für Funktionen und Daten für das soziale Netzwerk) Schreibvorgänge/Sek. (Inhaltsdatenbank) 50.00 40.00 30.00 20.00 Schreibvorgänge/Sek. (Profildatenbank) 10.00 0.00 1x1x1_Max 2x1x1_Max 3x1x1_Max 5x1x1_Max Topologie Schreibvorgänge/Sek. (Datenbank für Funktionen und Daten für das soziale Netzwerk) Auswirkungen der Suchdurchforstung nach Personen Wir wollten die Auswirkung der Suchdurchforstung nach Personen auf den gebotenen Durchsatz durch eine bestimmte Konfiguration und nach Latenzzeit für die Benutzer messen. Für diesen Test nutzten wird die Ergebnisse einer 8x1x1-Konfiguration als Basis und begannen mit der inkrementellen Suchdurchforstung nach Personen. Bei der inkrementellen Durchforstung wurden 49.375 Elemente in 53 Minuten indiziert. Die folgende Tabelle zeigt den Vorgleich der Leistungsmerkmale der 8x1x1-Konfiguration mit und ohne inkrementelle Suchdurchforstung nach Personen: Basis - Ergebnisse von 8x1x1 für den grünen Bereich Ergebnisse von 8x1x1 für den grünen Bereich mit Suchdurchforstung nach Personen Durchsatz [APS] 1024 1026 Front-End-WebserverCPU [%] 39,84 41,6 AnwendungsserverCPU [%] 41,40 43,1 Inhalts/Dienstdatenbank SQL Server-CPU [%] 36,63 39,5 Indexerstellung - CPU [%] 0,52 34,6 Suchdienst -SQL Server-CPU [%] 3,62 14,8 Tabelle 10: Vergleich der Leistungsmerkmale Informationen zur Tabelle: - Der APS-Wert blieb nahezu identisch. Da es bei der 8x1x1-Konfiguration im grünen Bereich keinen Ressourcenengpass gab, ist der APS-Wert nicht betroffen. Die Front-End-Webserver- und SQL Server-CPU-Auslastung für die Inhalts-und Dienstdatenbank stieg nur geringfügig. Die Auslastung der Suchindexerstellungs- bzw. SQL Server-CPU stieg von 0,5 % auf 34,6% bzw. 3,6 % auf 14,8 %. Analyse Anwendungsserverskalierung Ihn wird ggf. aufgefallen sein, dass bei keiner der Konfigurationen der Anwendungsserver einen Engpass darstellte. Ferner werden Sie bei der Untersuchung der Auslastung der Anwendungsserver-CPU bei verschiedenen VSTS-Lasten innerhalb einer einzelnen Konfiguration feststellen, dass diese anwächst und dann abflacht. Ein ideales Beispiel ist die 8x1x1-Konfiguration (detaillierte Ergebnisse finden Sie im Anhang): VSTS-Last 416 616 816 1016 1216 1416 1616 AnwendungsserverCPU 37,6 49,4 57,9 61,9 67,1 65,3 63,10 Dies war zu erwarten. Bei einem Communityportal ist für die meisten Vorgänge ein SharePoint-Dienst mit dem Namen Benutzerprofildienst erforderlich. Die meisten Vorgänge erfordert das Abrufen eines Benutzerprofils aus der Profildatenbank, die beim Erstellen des Benutzerprofildiensts bereitgestellt wird. Um häufige SQL Server-Roundtrips zu vermeiden, bietet der Anwendungsserver für den Benutzerprofildienst einen Cache mit Benutzerprofilen. Anfänglich ist dieser Cache in der Testumgebung leer, weshalb der Anwendungsserver auf vom Front-End-Webserver eingehende Anforderungen durch ständiges Abrufen von Benutzerprofilen aus SQL Server reagiert. Diese Profile werden anschließend im Cache gespeichert, und nachfolgend kann auf alle Anforderungen des Front-End-Webservers vom Anwendungsserver ohne SQL Server-Roundtrips durch ein Nachschlagen im Cache geantwortet werden. Da die Anzahl der Benutzerprofile in den Tests begrenzt war, speicherte der Anwendungsserver nach und nach alle diese Benutzerprofile im Cache, weshalb dessen Auslastung anstieg. Nachdem alle Profile im Cache gespeichert wurden, erfolgten ständige Nachschlagevorgänge im Cache, weshalb sich die Auslastung der Anwendungsserver-CPU stabilisierte. Datenverkehr durch den Outlook Connector für soziale Netzwerke und Einschränkung aus Sicherheitsgründen Der Outlook Connector für soziale Netzwerke ist ein Office 2010-Add-In, über das die Aktivitäten Ihrer SharePoint-Kollegen in Outlook angezeigt werden. Dieses Add-In steht auch als kostenloser Download für Office 2007 und Office 2003 zur Verfügung. Der Outlook Connector für soziale Netzwerke fragt den Server mit SharePoint stündlich ab, um Aktivitäten der Kollegen seines Benutzers abzurufen. Diese Aktivitäten werden eine Stunde im Cache gespeichert. In der nächsten Stunde werden nur Unterschiede bei den Aktivitäten abfragt, die seit dem letzten Aufruf von SharePoint erfolgt sind. Deshalb gibt es ein sehr gut vorhersehbares Datenverkehrsmuster. Bei einer Bereitstellung des Outlook Connectors für soziale Netzwerke und SharePoint für 100.000 Personen werden, vorausgesetzt, alle Personen nutzen das Add-In den ganzen Tag, 100.000 Anforderungen pro Stunde generiert, was 27,77 Anforderungen pro Sekunde (APS) entspricht. Das Anzeigen der Aktivitäten anderer Personen führt möglicherweise zu einer Preisgabe von Informationen. Wenn die URL, die ein Kollege mit einem Tag versehen hat, vertraulich ist, sodass ein Benutzer keinen Zugriff darauf hat, erfährt der Benutzer im Outlook Connector für soziale Netzwerke, dass diese vertrauliche Information vorhanden ist. Um diese Informationspreisgabe zu verhindern, filtert SharePoint alle Aktivitäten und zeigt nur die URLs in Aktivitäten an, auf die ein Benutzer Zugriff hat. Diese Filterung heißt auch Einschränkung aus Sicherheitsgründen. Sie ist standardmäßig aktiviert, kann aber deaktiviert werden. Nicht bei jeder Aktivität ist die Einschränkung aus Sicherheitsgründen erforderlich. Von den 16 von SharePoint unterstützten Aktivitätstypen erfordern nur vier die Einschränkung aus Sicherheitsgründen (das Kategorisieren mit Tags, Pinnwandkommentare, Bewertungen und Änderungen an der Mitgliedschaft von Verteilerlisten). Und da der Outlook Connector für soziale Netzwerke nur die Aktivitäten abfragt, die seit der letzten Synchronisierung hinzugefügt oder geändert wurden, ist die Anzahl der Aktivitäten pro Benutzer, bei denen eine Einschränkung aus Sicherheitsgründen erforderlich ist, vergleichsweise niedrig. Jede Anforderung des Outlook Connectors für soziale Netzwerke, die eine Einschränkung aus Sicherheitsgründen erfordert, führt zu einem authentifizierten WCF-Aufruf des Anwendungsservers des Suchdiensts. Zum Abrufen des Authentifizierungstokens für diesen Aufruf erfolgt anfangs ein WCFAufruf des Sicherheitstokendiensts. Wir fanden heraus, dass wenn der APS-Wert des Outlook Connectors für soziale Netzwerke acht APS pro Front-End-Webserver übersteigt, der Sicherheitstokendienst unter Stress gerät. Dies muss nicht unbedingt immer der Fall sein, was von der Gesamtanzahl der Benutzer und Communitytags abhängt, die die Kollegen eines Benutzers erstellen. Beim Dataset, das wir angelegt haben, und den Benutzern, die wir eingesetzt haben, gab es wahrscheinlich genügend Aktivitäten, die eine Einschränkung aus Sicherheitsgründen erforderten, dass dies bei uns aufgetreten ist. Deshalb haben wir den Datenverkehr durch den Outlook Connector für soziale Netzwerke abhängig von der Anzahl der verfügbaren FrontEnd-Webserver erhöht. Bei der 1x1x1-Konfiguration haben wir acht APS durch Datenverkehr vom Outlook Connector für soziale Netzwerke, bei der 2x1x1-Konfiguration 16 APS durch den Datenverkehr vom Outlook Connector für soziale Netzwerke erzeugt usw. Mit der gewählten Testkonfiguration (Dataset, Testmischung und Hardware) konnten wir 8x60x60, d. h. 28.800 Anforderungen pro Stunde unterstützen. Bei der Funktionsweise des Outlook Connectors für soziale Netzwerke bedeutet dies, dass wir 28.800 Mitarbeiter, die den Outlook Connector für soziale Netzwerke einsetzen, auf einem einzelnen Front-End-Webserver mit aktivierter Einschränkung aus Sicherheitsgründen unterstützen könnten. Bei drei Front-End-Webservern und aktivierter Einschränkung aus Sicherheitsgründen können analog 28.800x3, d. h. 86.400-Nutzer des Outlook Connectors für soziale Netzwerke unterstützt werden. Dies sollte Ihnen beim Bestimmen der Hardware zur Unterstützung des Outlook Connectors für soziale Netzwerke helfen. Bedenken Sie jedoch, dass unsere Ergebnisse spezifisch für unsere gewählte Testkonfiguration (Dataset, Testmischung und Hardware) gelten. Berücksichtigen Sie ferner, dass Sie die Einschränkung aus Sicherheitsgründen über PowerShell deaktivieren oder die Häufigkeit der Synchronisierung des Outlook Connectors für soziale Netzwerke mit SharePoint ändern können. Diese beiden Optionen haben wesentliche Auswirkungen auf die Hardwareanforderungen. Empfehlungen Bei unseren Tests haben wir Folgendes herausgefunden: - - - - - Die Umgebung wurde auf acht Front-End-Webserver für einen Anwendungsserver und einen Datenbankserver vertikal skaliert, was zu einer nahezu linearen Steigerung des Durchsatzes führte. Das Hinzufügen weiterer Front-End-Webserver führte zu keiner weiteren Durchsatzsteigerung, da die Auslastung der Datenbankserver-CPU an dieser Stelle einen Engpass darstellte. Eine weitere Skalierung kann erreicht werden, indem die Inhaltsdatenbank und Dienstdatenbank auf zwei getrennte Datenbankserver ausgelagert werden. Wir sind bei der 8 x 1 x 2-Topologie bis an die Leistungsgrenze gegangen. An dieser Stelle wurde die CPU-Auslastung von sowohl dem Front-End-Webserver als auch dem Anwendungsserver zu einem Engpass. Dies führt uns zu der Annahme, dass bei der vorliegenden Hardware, Testarbeitslast und dem Dataset der Maximalwert für Anforderungen pro Sekunde (APS) für 8x1x2 sich auf 1877 beläuft. Bei Untersuchung der Trends scheint es möglich, denselben Durchsatz mit einer stabilen Farm zu erreichen, sofern die Engpässe auf dem Front-End-Webserver und Anwendungsserver beseitigt werden. Der Front-End-Webserver-Engpass kann durch Hinzufügen weiterer FrontEnd-Webserver und der Anwendungsserverengpass durch Verwenden zweier Computer beseitigt werden, die die Rollen von Anwendungsservern übernehmen. Das haben wir allerdings nicht in der Testumgebung ausprobiert. Durchsatz und Hardwarevariationen haben keinen Einfluss auf die Latenz. Wenn die Einschränkung aus Sicherheitsgründen aktiviert ist, kann ein Front-End-Webserver ca. 8-10 APS an Datenverkehr durch den Outlook Connector für soziale Netzwerke unterstützen. Dies bedeutet, dass ein Front-End-Webserver ca. 28.000 bis 36.000 Mitarbeiter unterstützen kann, die den Outlook Connector für soziale Netzwerke den ganzen Tag nutzen. Wenn Sie also den Outlook Connector für soziale Netzwerke für 100.000 Mitarbeiter bereitstellen, können Sie den Datenverkehr unterstützen, der von drei Front-End-Webservern generiert wird. Diese Werte können je nach Nutzung von Communitytags in Ihrem Unternehmen variieren. Wenn Sie davon ausgehen, dass in Ihrem Unternehmen Communitytags weniger genutzt werden als in unserer Testumgebung, erhalten Sie ggf. einen besseren Durchsatz pro Front-End-Webserver. Die inkrementelle Suchdurchforstung nach Personen hat keine wesentlichen Auswirkungen auf den Durchsatz der Farm, solange die Farm einen stabilen Status hat. Anhang Ergebnisse der Testdurchläufe 1x1x1-Topologie Zusammenfassung der Ergebnisse - Zusätzlich zu der oben genannten Testmischung wies diese Farm acht APS durch Datenverkehr vom Outlook Connector für soziale Netzwerke auf, der Feedereignisse von einem Benutzer anfragte. - In einer Farm mit einem Front-End-Webserver, Anwendungsserver und Server mit SQL Server war der Front-End-Webserver eindeutig der Engpass. Entsprechend den Daten in der folgenden Tabelle erreichte die Front-End-Webserver-CPU eine Auslastung von ca. 90 % bei 238 Anforderung pro Sekunde (APS), wenn die weiter oben beschriebene Transaktionsmischung verwendet wurde. - Diese Konfiguration lieferte im grünen Bereich einen APS-Wert von 137,25 (bei einem 75. Quantil Latenz von 0,12 Sekunden) und eine Front-End-Webserver-CPU-Auslastung von ca. 47,8 %. Dies bedeutet, dass diese Farm zuverlässig einen APS-Wert von 137,25 bieten kann. Der APS-Wert im Maximalbereich dieser Farm war 203,2 mit einer Latenz von 0,22 Sekunden und einer Front-End-Webserver-CPU-Auslastung von ca. 85 %. - Da der Front-End-Webserver einen Engpass darstellt, fügten wir für den nächsten Testlauf der Farm einen weiteren Front-End-Webserver hinzu. Leistungsindikatoren und Diagramme Es folgen verschiedene Leistungsindikatoren, die beim Testen einer 1x1x1-Farm auf verschiedenen VSTSLaststufen erfasst wurden. VSTS-Last Anforderungen pro Sekunde (APS) Front-End-WebserverCPU Anwendungsserver-CPU SQL Server-CPU 75. Quantil [Sek.] 95. Quantil [Sek.] 52 77 102 127 152 177 99,8 147 188 218 238 243 33,9 7,92 4,7 0,13 0,29 50 11,7 6,48 0,16 0,47 71,8 13,5 7,99 0,17 0,41 81,1 14,1 8,21 0,25 0,55 90,8 13,9 8,41 0,3 0,55 89 13,3 8,88 0,45 0,77 Tabelle 1: Leistungsindikatoren in einer 1x1x1-Farmkonfiguration APS und Latenz bei 1x1x1 300 75. Quantil Latenz (Sek.) 0.45 250 0.4 0.35 200 0.3 0.25 150 0.2 100 0.15 0.1 50 0.05 0 Anforderungen pro Sekunde (APS) 0.5 75. Quantil Latenz Anforderungen pro Sekunde (APS) 0 52 77 102 127 152 177 VSTS-Last APS und CPU-Auslastung bei 1x1x1 100 90 250 80 70 200 60 150 50 40 100 30 20 50 % CPU-Auslastung Anforderungen pro Sekunde (APS) 300 Anforderungen pro Sekunde (APS) Web-Front-End-CPU Anwendungsserver-CPU SQL Server-CPU 10 0 0 52 77 102 127 152 177 VSTS-Last 2x1x1-Farmkonfiguration Zusammenfassung der Ergebnisse - Zusätzlich zu der oben genannten Testmischung wies diese Farm 16 APS durch Datenverkehr vom Outlook Connector für soziale Netzwerke auf, der Feedereignisse von einem Benutzer anfragte. - In einer Farm mit zwei Front-End-Webservern, einem Anwendungsserver und einem Server mit SQL Server war der Front-End-Webserver der Engpass. Entsprechend den nachfolgenden Daten - - erreichte die Front-End-Webserver-CPU eine Auslastung von ca. 89 % bei 520 Anforderung pro Sekunde (APS), wenn die weiter oben beschriebene Transaktionsmischung verwendet wurde. Diese Konfiguration lieferte im grünen Bereich einen APS-Wert von 278 (bei einem 75. Quantil Latenz von 0,16 Sekunden) und eine Front-End-Webserver-CPU-Auslastung von ca. 47 %. Dies bedeutet, dass diese Farm bei der gewählten Testkonfiguration zuverlässig einen APS-Wert von 278 bieten kann. Der APS-Wert im Maximalbereich dieser Farm war 450 mit einer Latenz von 0,23 Sekunden und einer Front-End-Webserver-CPU-Auslastung von ca. 78 %. Da der Front-End-Webserver bei diesem Testlauf einen Engpass darstellt, fügten wir für den nächsten Testlauf der Farm einen weiteren Front-End-Webserver zum Beseitigen des Engpasses hinzu. Leistungsindikatoren und Diagramme In der nachfolgenden Tabelle und dem Diagramm sind verschiedene Leistungsindikatoren angegeben, die beim Testen einer 2x1x1-Farm auf verschiedenen VSTS-Laststufen erfasst wurden. VSTS-Last Anforderungen pro Sekunde (APS) Front-End-WebserverCPU Anwendungsserver-CPU SQL Server-CPU 75. Quantil [Sek.] 95. Quantil [Sek.] 104 154 204 254 304 354 190 278 390 455 500 520 36 16 8,06 0,16 0,42 50,9 24,9 10,6 0,22 0,64 71,9 28,3 14,2 0,22 0,51 86,9 26,5 16,4 0,33 0,69 87,1 26,5 17,9 0,42 0,73 89,5 24,9 18,9 0,53 0,89 Tabelle 2: Leistungsindikatoren bei der 2x1x1-Konfiguration 0.6 600 0.5 500 0.4 400 0.3 300 0.2 200 0.1 100 0 Anforderungen pro Sekunde (APS) 75. Quantil Latenz (Sek.) APS und Latenz bei 2X1X1 75. Quantil Latenz Anforderungen pro Sekunde (APS) 0 104 154 204 254 304 354 VSTS-Last APS und CPU-Auslastung bei 2X1X1 600 90 500 % CPU-Auslastung 80 70 400 60 50 300 40 200 30 20 100 10 0 Anforderungen pro Sekunde (APS) 100 Anforderungen pro Sekunde (APS) Web-Front-End-CPU Anwendungsserver-CPU SQL Server-CPU 0 104 154 204 254 304 354 VSTS-Last 3x1x1-Farmkonfiguration Zusammenfassung der Ergebnisse - Zusätzlich zu der oben genannten Testmischung wies diese Farm 24 APS durch Datenverkehr vom Outlook Connector für soziale Netzwerke auf, der Feedereignisse von einem Benutzer anfragte. - In einer Farm mit drei Front-End-Webservern, einem Anwendungsserver und einem Server mit SQL Server war der Front-End-Webserver der Engpass. Entsprechend den nachfolgenden Daten - - erreichte die Front-End-Webserver-CPU eine Auslastung von ca. 76 % bei 629 Anforderung pro Sekunde (APS), wenn die weiter oben beschriebene Transaktionsmischung verwendet wurde. Diese Konfiguration lieferte im grünen Bereich einen APS-Wert von 440 (bei einem 75. Quantil Latenz von 0,14 Sekunden) und eine Front-End-Webserver-CPU-Auslastung von ca. 48 %. Dies bedeutet, dass diese Farm bei der gewählten Testkonfiguration zuverlässig einen APS-Wert von 440 bieten kann. Der APS-Wert im Maximalbereich dieser Farm war 615 mit einer Latenz von 0,22 Sekunden und einer Front-End-Webserver-CPU-Auslastung von ca. 70 %. Da der Front-End-Webserver bei diesem Testlauf einen Engpass darstellt, fügten wir weitere Front-End-Webserver hinzu. Angesichts der Differenz aufgrund des Hinzufügens eines FrontEnd-Webservers in den Testläufen beschlossen wir, zwei Front-End-Webserver hinzuzufügen. Hierdurch wollten wir herausfinden, ob der Anwendungsserver oder Server mit SQL Server einen Engpass darstellt. Leistungsindikatoren und Diagramme In der nachfolgenden Tabelle und dem Diagramm sind verschiedene Leistungsindikatoren angegeben, die beim Testen einer 3x1x1-Farm auf verschiedenen VSTS-Laststufen erfasst wurden. VSTS-Last Anforderungen pro Sekunde (APS) Front-EndWebserver-CPU AnwendungsserverCPU SQL Server-CPU 75. Quantil [Sek.] 95. Quantil [Sek.] 156 231 306 381 456 531 264 393 532 624 634 629 30,5 46,3 62,55 72,95 75,4 76 22,7 10,4 0,17 0,63 35,6 14,8 0,26 1,08 34,2 20,8 0,27 0,76 32,5 22,5 0,28 0,68 32,5 22,8 0,31 0,88 29,4 22,4 0,40 0,98 Tabelle 3: Leistungsindikatoren bei der 3x1x1-Konfiguration APS und Latenz bei 3X1X1 700 75. Quantil Latenz (Sek.) 0.40 600 0.35 500 0.30 0.25 400 0.20 300 0.15 200 0.10 100 0.05 0.00 Anforderungen pro Sekunde (APS) 0.45 Anforderungen pro Sekunde (APS) 75. Quantil Latenz 0 156 231 306 381 456 531 VSTS-Last 80 700 70 600 60 500 50 400 40 300 30 200 20 100 10 0 Anforderungen pro Sekunde (APS) % CPU-Auslastung APS und CPU-Auslastung bei 3X1X1 Anforderungen pro Sekunde (APS) Web-Front-End-CPU Anwendungsserver-CPU SQL Server-CPU 0 156 231 306 381 456 531 VSTS-Last 5x1x1-Farmkonfiguration Zusammenfassung der Ergebnisse - Zusätzlich zu der oben genannten Testmischung wies diese Farm 40 APS durch Datenverkehr vom Outlook Connector für soziale Netzwerke auf, der Feedereignisse von einem Benutzer anfragte. - In einer Farm mit fünf Front-End-Webservern, einem Anwendungsserver und einem Server mit SQL Server stieg die Auslastung der SQL Server- und Anwendungsserver-CPU deutlich an, doch - - noch immer war die Front-End-Webserver-CPU der Engpass. Entsprechend den nachfolgenden Daten erreichte die Front-End-Webserver-CPU eine Auslastung von ca. 88 % bei 1315 Anforderung pro Sekunde (APS), wenn die weiter oben beschriebene Transaktionsmischung verwendet wurde. Diese Konfiguration lieferte im grünen Bereich einen APS-Wert von 683 (bei einem 75. Quantil Latenz von 0,16 Sekunden) und eine Front-End-Webserver-CPU-Auslastung von ca. 46 %. Dies bedeutet, dass diese Farm bei der gewählten Testkonfiguration zuverlässig einen APS-Wert von 683 bieten kann. Der APS-Wert im Maximalbereich dieser Farm war 971 mit einer Latenz von 0,22 Sekunden und einer Front-End-Webserver-CPU-Auslastung von ca. 68 %. Nach Untersuchung des Trends entschlossen wir uns, drei Front-End-Webserver hinzuzufügen und die 8x1x1-Konfiguration zu testen. Mit dieser Konfiguration wollten wir herausfinden, ob der Anwendungsserver oder Server mit SQL Server einen Engpass darstellt. Leistungsindikatoren und Diagramme Es folgen verschiedene Leistungsindikatoren, die beim Testen einer 5x1x1-Farm auf verschiedenen VSTSLaststufen erfasst wurden. Da wir keine wesentlichen Auswirkungen von Änderungen an der VSTS-Last oder der Konfiguration auf die Latenz erkannten, stellten wir die Aufzeichnung ein. VSTS-Last Anforderungen pro Sekunde (APS) Front-EndWebserver-CPU AnwendungsserverCPU SQL Server-CPU 260 385 510 635 760 885 359 560 901 1188 1281 1315 20,5 34 56,2 77,5 86,1 88 40,2 13,9 50,6 20,3 66,9 34,9 71,3 53,6 66,3 58,4 58,7 64 Tabelle 4: Leistungsindikatoren bei der 5x1x1-Konfiguration 1400 100 90 80 70 60 50 40 30 20 10 0 1200 1000 800 600 400 200 0 % CPU-Auslastung Anforderungen pro Sekunde (APS) APS und CPU-Auslastung bei 5X1X1 Anforderungen pro Sekunde (APS) Web-Front-End-CPU Anwendungsserver-CPU SQL Server-CPU 260 385 510 635 760 885 VSTS-Last 8x1x1-Farmkonfiguration Zusammenfassung der Ergebnisse - Zusätzlich zu der oben genannten Testmischung wies diese Farm 64 APS durch Datenverkehr vom Outlook Connector für soziale Netzwerke auf, der Feedereignisse von einem Benutzer anfragte. - In einer Farm mit acht Front-End-Webservern, einem Anwendungsserver und einem Server mit SQL Server war schließlich die SQL Server-CPU der Engpass. Entsprechend den nachfolgenden Daten erreichte die SQL Server-CPU eine Auslastung von ca. 80 % bei 1664 Anforderung pro Sekunde (APS), wenn die weiter oben beschriebene Transaktionsmischung verwendet wurde. - Diese Konfiguration lieferte im grünen Bereich einen APS-Wert von 793 (bei einem 75. Quantil Latenz von 0,31 Sekunden) und eine SQL Server-CPU-Auslastung von ca. 30 %, während die Auslastung der Anwendungsserver-CPU ca. 48 % betrug. Dies bedeutet, dass diese Farm bei der gewählten Testkonfiguration zuverlässig einen APS-Wert von 793 bieten kann. Der APS-Wert im Maximalbereich dieser Farm war 1655 mit einer Latenz von 0,31 Sekunden und einer Steuerelement-CPU-Auslastung von ca. 80 %. - Da bei diesem Testlauf die SQL Server-CPU der Engpass war, beseitigten wir den Engpass durch Verteilen der Inhaltsdatenbank und der Dienstdatenbank auf zwei verschiedene SQL ServerInstanzen für den nächsten Testlauf. Leistungsindikatoren und Diagramme In der nachfolgenden Tabelle und dem Diagramm sind verschiedene Leistungsindikatoren angegeben, die beim Testen einer 8x1x1-Farm auf verschiedenen VSTS-Laststufen erfasst wurden. VSTS-Last Anforderungen pro Sekunde (APS) Front-EndWebserver-CPU AnwendungsserverCPU SQL Server-CPU 416 616 816 1016 1216 1416 1616 664 1101 1359 1530 1655 1664 26,7 44,4 54,7 61,5 67 65,9 65,10 37,6 23,2 49,4 42 57,9 57,9 61,9 69,5 67,1 79,5 65,3 80,8 63,10 77,30 1617,00 Tabelle 5: Leistungsindikatoren bei der 8x1x1-Konfiguration 1800 90 1600 80 1400 70 1200 60 1000 50 800 40 600 30 400 20 200 10 0 0 416 616 816 1016 1216 1416 1616 VSTS-Last % CPU-Auslastungs Anforderungen pro Sekunde (APS) APS und CPU-Auslastung bei 8X1X1 Anforderungen pro Sekunde (APS) Web-Front-End-CPU Anwendungsserver-CPU SQL Server-CPU 8x1x2-Farmkonfiguration Zusammenfassung der Ergebnisse - Zusätzlich zu der oben genannten Testmischung wies diese Farm 64 APS durch Datenverkehr vom Outlook Connector für soziale Netzwerke auf, der Feedereignisse von einem Benutzer anfragte. - In einer Farm mit acht Front-End-Webservern, einem Anwendungsserver und zwei Servern mit SQL Server konnten wir mit der Konfiguration ans Limit gehen. Der Front-End-Webserver und Anwendungsserver stellten einen Engpass dar. Die kombinierte SQL Server-CPU-Auslastung lag ebenfalls im höheren 70 %-Bereich. Die Farm konnte maximal 1817 APS unterstützen. - Die war unser letzter Testlauf. Wenn Sie jedoch noch eine weitere Skalierung benötigen, ist der nächste Schritt der Einsatz von zwei Computern, die Anwendungsserveraufgaben übernehmen. Dies ermöglicht Ihnen eine wesentlich höhere Anzahl von Front-End-Webservern, wodurch die Last der einzelnen Front-End-Webserver sinkt. Leistungsindikatoren und Diagramme In der nachfolgenden Tabelle und dem Diagramm sind verschiedene Leistungsindikatoren angegeben, die beim Testen einer 8x1x2-Farm auf verschiedenen VSTS-Laststufen erfasst wurden. VSTS-Last Anforderungen pro Sekunde (APS) Front-EndWebserver-CPU AnwendungsserverCPU Gesamte SQL Server-CPU SQL Server-CPU für Inhaltsdatenbanken SQL Server-CPU für Dienstdatenbanken 466 666 866 1066 1266 1416 466 873,40 1431 1703 1766 1817 19,90 36,90 57,60 68,00 71,40 71,60 29,80 47,20 63,50 71,40 71,90 73,40 19,61 32,40 55,20 63,60 68,50 74,90 9,93 17,90 31,90 40,10 42,30 45,90 9,68 14,50 23,30 23,50 26,20 29,00 Tabelle 6: Leistungsindikatoren bei der 8x1x2-Konfiguration 2000 1800 1600 1400 1200 1000 800 600 400 200 0 80 70 Anforderungen pro Sekunde (APS) 60 Web-Front-End-CPU 50 40 30 20 10 0 466 666 866 1066 1266 1416 VSTS-Last % CPU-Auslastung Anforderungen pro Sekunde (APS) APS und CPU-Auslastung bei 8X1X2 Anwendungsserver-CPU Gesamte SQL ServerCPU Inhaltsdatenbanken – SQL Server-CPU Dienstdatenbanken – SQL Server-CPU
