AppFabric-Planungshandbuch zur Cachekapazität

Jason Roth, Rama Ramani, Jaime Alva Bravo

März 2011

Dieses Whitepaper stellt einen Leitfaden für die Kapazitätsplanung von Windows Server AppFabric-Cache dar.

1. Einführung

2. Auswerten der AppFabric-Cacheleistung

3. Methodik der Kapazitätsplanung

   1. Schritt 1: Verstehen von Engpässen und Bestimmen von Cachekandidaten

   2. Schritt 2: Auswerten aktueller Muster der Arbeitsauslastung

   3. Schritt 3: Grundlagen von physischer Infrastruktur und Hardwareressourcen

   4. Schritt 4: Abschließen des erforderlichen Leistungs-SLAs für alle Anwendungen

   5. Schritt 5: Bestimmen der geeigneten AppFabric-Funktionen und Konfigurationseinstellungen

4. Kapazitätsplanungstool

5. Nächste Schritte bei der Kapazitätsplanung

6. Überwachen der fortlaufenden Anforderungen an die Cachekapazität

Einführung

Microsoft AppFabric 1.1 für Windows Server-Cache stellt einen verteilten Cachecluster im Arbeitsspeicher bereit. Dieses Dokument stellt einen Leitfaden für die Kapazitätsplanung für eine Bereitstellung von Microsoft AppFabric 1.1 für Windows Server-Cache am Unternehmensstandort dar.

Die Architektur von Microsoft AppFabric 1.1 für Windows Server-Cache ist im Detail in der Dokumentation beschrieben. Weitere Informationen finden Sie unter Windows Server AppFabric-Cachefunktionen. Kurz gefasst lässt sich sagen, dass ein AppFabric-Cachecluster aus einem oder mehreren Cacheservern (auch als Cachehosts bezeichnet) besteht. Die Caches sind über die Cachehosts verteilt und im Arbeitsspeicher gespeichert.

Die in diesem Dokument vermittelten Informationen basieren auf Planungsarbeiten, die Microsoft mit Kunden durchgeführt hat. Alle Kunden von AppFabric-Cache stellen die gleiche Frage: „Wie viele Server benötigen wir für unser Szenario?“ Bei vielen dieser Gespräche beginnen wir mit der typischen Antwort „Das hängt davon ab“. Im Anschluss dringen wir dann schnell zu Detailfragen vor und erreichen mit etwas Glück einen guten Ausgangspunkt. Im Verlauf dieses Prozesses schälen sich weitere, spezifischere Fragen heraus:

• Wie viel Cachespeicher benötigen die ausgeführten Anwendungen?

• Wie viele Computer sollten in einem Cachecluster eingesetzt werden?

• Wie viel Arbeitsspeicher sollte auf jedem der Computer verfügbar sein, und wie sollten sie konfiguriert sein?

• Wie wirkt sich die Netzwerkbandbreite auf die Leistung des Cacheclusters aus?

Dieses Whitepaper verfolgt den Zweck, die aus dieser Art von Kundendiskussion gelernten Lektionen festzuhalten, mit der Zielsetzung, eine Methodik für Ihre Kapazitätsplanung bereitzustellen.

Als Leser dieses Whitepaper können Sie einem aus einer Reihe verschiedener Entwicklungsstadien angehören:

1. Sie beginnen gerade, sich mit verteilter Cachefunktionalität zu befassen und verfügen nicht über detaillierte Daten zur Zusammensetzung der Arbeitsauslastung, den Leistungsanforderungen oder der Topologie der Serverbereitstellung. An diesem Punkt können Sie sich sinnvollerweise über Leistungsdaten von AppFabric-Cache informieren, um einen Ausgangspunkt zu gewinnen.

2. Vielleicht haben Sie sich aber auch schon mit Funktionen und Leistung von AppFabric-Cache befasst. In diesem Fall wünschen Sie Unterstützung bei der genauen Betrachtung Ihres spezifischen Szenarios und der Anforderungen auf oberer Ebene. Damit beginnt Ihr Einstieg in die Details der Kapazitätsplanung.

3. Schließlich können Sie auch bereits über eine Produktionsumgebung verfügen. In diesem Stadium benötigen Sie weiterführende Informationen zur Analyse der Leistungsdaten, um sicherzustellen, dass Sie über ausreichend Kapazität verfügen. Darüber hinaus werden Sie auch dem zukünftigen Anstieg der Arbeitsauslastung Rechnung tragen wollen. Dazu benötigen Sie, ausgehend vom Laufzeitverhalten des AppFabric-Caches, die Schlüsselindikatoren und optimalen Verfahren.

Dieses Whitepaper ist so aufgebaut, dass diese Stadien der Reihe nach behandelt werden. Wenn Sie lediglich die AppFabric-Leistung bewerten möchten, verweisen wir auf ein umfassendes Whitepaper von unserem Partner Grid Dynamics. In diesem Dokument geben wir die Daten aus diesem Whitepaper übersichtlich gegliedert wieder, um Ihnen die Auswertung zu erleichtern und Informationen zum Kapazitätsplanungsprozess zur Verfügung zu stellen.

Wenn Sie bereit sind, den Kapazitätsplanungsprozess zu durchlaufen, stellen wir eine Reihe von Schritten zur Verfügung, um eine Methodik zu formulieren, die Sie auf Ihr Szenario anwenden können.

Wenn Sie einen Cachecluster verwenden oder testen, können Sie den Kapazitätsplanungsprozess anhand einer Reihe ausgewählter Leistungsindikatoren überprüfen, um sicherzustellen, dass Sie über die richtige Kapazität verfügen. Darüber hinaus werden einige optimale Verfahren erörtert.

Auswerten der AppFabric-Cache-Leistung

Unser Partner Grid Dynamics hat vor Kurzem eine Reihe von Texts zur Leistung von AppFabric-Cache abgeschlossen. Die Ergebnisse wurden im folgenden Whitepaper veröffentlicht: Windows Server AppFabric Cache: Ausführliches Datenblatt zu & Leistung und Skalierbarkeit.

Jeder Test konzentriert sich auf eine bestimmte Variable, wie etwa die Größe des Caches oder die Anzahl der Server im Cachecluster. Die Grid Dynamics-Studie kann verwendet werden, um die Leistung und Skalierbarkeit von AppFabric-Cache zu bewerten. Sie können die Durchsatz- und Latenzdaten einer großen Bandbreite von Testszenarien und -topologien mit Ihren Anwendungserfordernissen vergleichen. Normalerweise wurden in jedem Test nur einer oder zwei Parameter verändert, um ihren Einfluss auf die Leistung darzustellen. Die Gesamtmenge dieser Parameter umfasst:

Auslastungsmuster	Cachenutzungsmuster, d.h. Prozentsatz der 'Get'-, 'Put'-, 'BulkGet'-, 'GetAndLock'- und 'PutAndUnlock'-Vorgänge
Menge der im Cache gehaltenen Daten	Die Menge der während des Tests im Cache gespeicherten Daten
Clustergröße	Anzahl der Server im Cachecluster
Objektgröße	Die Größe von Objekten nach der Serialisierung, die im Cache gespeichert sind
Typkomplexität	Verschiedene .NET-Objekttypen, wie etwa Byte, String[] usw., die im Cache gespeichert sind
Sicherheit	Sicherheitseinstellungen des Cacheclusters

Über das Überprüfen von Leistung und Skalierbarkeit von AppFabric-Cache hinaus hat Grid Dynamics die Testumgebung bereitgestellt, mit deren Hilfe Sie die Test mit Ihren eigenen Daten und Arbeitsauslastungen wiederholen können. Damit steht eine weitere Option zum Beurteilen der Cacheleistung für Ihr spezifisches Szenario zur Verfügung.

Zwar empfehlen wir dringend, die gesamte Studie und die darin gezogenen Schlussfolgerungen durchzuarbeiten, trotzdem folgt hier eine Zusammenfassung der Erkenntnisse aus der Studie als Grundlage zum Verständnis der bewährten Methoden, die im Rest dieses Dokuments erörtert werden:

• AppFabric-Cache wird linear in dem Maß skaliert, wie einem Cachecluster weitere Computer hinzugefügt werden.

• Die Cachegröße hat einen geringen Einfluss, abgesehen von großen Caches mit einem hohen Prozentsatz an Schreibvorgängen. Neben anderen Faktoren bewirken hohe Schreibauslastungen eine starke Belastung der .NET Garbage Collection, wenn der verwaltete Heap groß ist.

• Hohe Typkomplexität wirkt sich nur auf die clientseitige Leistung aufgrund von Serialisierung aus.

• Get-Massenaufrufe führen zu einer besseren Netzwerkauslastung. Direkter Cachezugriff ist erheblich schneller als Proxyzugriff (ASP.NET, WCF), dies ist jedoch auf die Leistung der Zwischenschicht statt auf die Cacheleistung zurückzuführen.

• Das Leistungsverhalten bei pessimistischem und optimistischem Sperren ist ähnlich, Sie sollten also die Technik verwenden, die sich optimal für Ihren Anwendungsentwurf eignet. Sowohl Latenz als auch Durchsatz verbessern sich bei abnehmendem Konfliktverhältnis.

• Cacheclustersicherheit verringert die Leistung nicht und ist standardmäßig aktiviert. Der höchste Durchsatz und die geringste Latenz werden erreicht, wenn die Sicherheit deaktiviert ist, jedoch kann das wegen der Vertraulichkeit der Daten und wegen Geschäftsanforderungen inakzeptabel sein.

• Netzwerkengpässe werden durch den Einsatz eines dedizierten Netzwerks zwischen Anwendungsservern und Cacheservern verringert.

Beachten Sie, dass das Grid Dynamics-Dokument einen guten Ausgangspunkt für die Bewertung von AppFabric-Cache darstellt und darüber hinaus Rohdaten und beobachtete Muster enthält, die dem Kapazitätsplanungsprozess zugrunde gelegt werden können.

Methodik der Kapazitätsplanung

Wenn Sie sich entschieden haben, dass Ihre Anwendung von einem verteilten Cache im Arbeitsspeicher (wie z. B. AppFabric-Cache) profitieren kann, treten Sie in das Kapazitätsplanungsstadium ein. Zwar ist es möglich, einige Schritte der Kapazitätsplanung durch direkte Tests auf einem AppFabric-Cachecluster auszuführen, trotzdem kann es erforderlich werden, eine Einschätzung ohne derartige Tests vorzunehmen. Das ist das Hauptaugenmerk dieses Abschnitts. Die folgenden Schritte beschreiben ein systematisches Verfahren zum Durchdenken Ihrer AppFabric-Cache-Anforderungen:

1. Verstehen von Engpässen und Bestimmen von Cachekandidaten

2. Auswerten aktueller Muster der Arbeitsauslastung

3. Grundlagen von physischer Infrastruktur und Hardwareressourcen

4. Abschließen des erforderlichen Leistungs-SLAs für alle Anwendungen

5. Bestimmen der geeigneten AppFabric-Funktionen und Konfigurationseinstellungen

Dieses Dokument stellt Beispiele für diese Schritte bereit und untersucht dazu die Anforderungen einer Beispielanwendung eines Onlinewarenhauses. Cachefunktionalität kann jedoch für jede Art von .NET-Anwendung eingesetzt werden, und mehrere Anwendungen können auf den gleichen Cachecluster zugreifen. In diesem Szenario sollten Sie die nachfolgenden Schritte für jede Anwendung durchführen und die Ergebnisse aggregieren, um eine genaue Abschätzung der Kapazität zu erhalten.

Schritt 1: Verstehen von Engpässen und Bestimmen von Cachekandidaten

Bestimmen Sie zuerst die Daten, die im Cache zwischengespeichert werden sollen. Dies geschieht mithilfe von Tools zur Leistungsanalyse, wie etwa SQL Server Profiler, Systemmonitor, Tests in Visual Studio und viele andere. Mithilfe dieser Tools lassen sich Datenbankobjekte, auf die häufig zugegriffen wird, oder langsame Aufrufe von Webdiensten bestimmen. Die von diesen Back-End-Informationsspeichern zurückgegebenen Datensätze stellen potenzielle Kandidaten für die Zwischenspeicherung im Cache dar. Das temporäre Speichern dieser Daten im Cache kann die Leistung verbessern und die Last auf den Back-End-Datenspeichern verringern.

Nachdem die potenziellen Cachekandidaten bestimmt wurden, ist es sinnvoll, diese Objekte einer von drei Hauptkategorien zuzuordnen: Aktivitätsdaten, Referenzdaten und Ressourcendaten. Dies lässt sich am Besten anhand von Beispielen erklären.

• Aktivitätsdaten enthalten Lese-/Schreibdaten, die mit einem einzelnen Benutzer zusammenhängen. Beispielsweise stellt der Einkaufskorb eines Benutzers in einem Onlinewarenhaus eine Form von Aktivitätsdaten dar. Sie beziehen sich auf die aktuelle Sitzung des Benutzers und können sich mit großer Häufigkeit ändern. Zwar ist die hohe Verfügbarkeit des Einkaufskorbs wichtig, doch ist für diese Daten nicht zwangsläufig eine dauerhafte Speicherung in einer Back-End-Datenbank erforderlich. Aufgrund ihrer temporären Merkmale bieten sich Aktivitätsdaten als Kandidaten für die Zwischenspeicherung im Cache an.

• Referenzdaten sind schreibgeschützte Daten, die von mehreren Benutzern oder mehreren Anwendungsinstanzen gemeinsam verwendet werden. Auf diese Daten wird häufig zugegriffen, sie ändern sich jedoch selten. Im Beispiel-Onlinewarenhaus stellt der Produktkatalog eine Form von Referenzdaten dar. Der Katalog ist für einen oder mehrere Tag(e) gültig, auf ihn wird jedoch möglicherweise viele Tausend Mal von verschiedenen Benutzern zugegriffen. Dieser Datentyp stellt ebenfalls einen guten Kandidaten für die Zwischenspeicherung im Cache dar. Ohne Zwischenspeicherung ist für jeden Benutzer, der den Produktkatalog anzeigt, ein Zugriff auf die Daten in der Datenbank erforderlich. Die Verwendung von Caches kann die Belastung der Back-End-Datenbank durch wiederholte Anforderung semistatischer Daten deutlich reduzieren. Aufgrund ihrer dauerhaften Charakteristik stellen diese Daten ebenfalls Kandidaten für die Zwischenspeicherung im Cache dar.

• Ressourcendaten sind Daten mit Lese-/Schreibzugriff, die von Benutzern gemeinsam verwendet werden. Beispielsweise enthält ein Supportforum Daten dieses Typs. Alle Benutzer können eine Antwort auf Beiträge im Forum lesen.

Da verschiedene Typen zwischengespeicherter Daten unterschiedliche Verwendungsmuster aufweisen, kann das Klassifizieren der Daten in diese Kategorien nützlich sein. Wenn ein Objekt z. B. als Referenzdaten identifiziert wird, legt dies automatisch nahe, dass die Arbeitsauslastung vorwiegend in Lesezugriffen besteht. Ferner kann der Prozess das Bestimmen von Ablaufrichtlinien unterstützen, die bei Daten, die häufiger geändert werden, tendenziell kürzer sind. Für die Entwicklung können aufgrund dieser logischen Unterteilungen Bereiche identifiziert werden, die sich zum Verkapseln im Code eignen.

Es wird empfohlen, Schätzungen für einzelne Objekte zu erstellen und die betreffenden Daten anschließend zu aggregieren. Die folgende Tabelle zeigt ein Beispiel für die in diesem Stadium erfassten Informationen:

Zwischenzuspeicherndes Objekt	Cachekategorisierung	Dauerhafter Speicherort
Einkaufswagenobjekt	Aktivitätsdaten	Keine
Benutzereinstellungen-Objekt	Aktivitätsdaten	Back-End-Datenbank
Produktkatalog	Referenzdaten	Back-End-Datenbank
Benutzerforumthread	Ressourcendaten	Back-End-Datenbank

Beim Identifizieren von Cachedaten für die Zwischenspeicherung ist es nicht erforderlich, in jeder der Kategorien geeignete Daten zu finden. Es kann sich herausstellen, dass sich Leistung und Skalierbarkeit einfach durch Zwischenspeichern des Einkaufswagens Ihrer Anwendung im Cache verbessern lassen. Der wichtige Punkt bei diesem Schritt besteht in der Verwendung der verfügbaren Informationen, um die optimal für den Cache geeigneten Elemente zu identifizieren.

Schritt 2: Auswerten aktueller Muster der Arbeitsauslastung

Sobald Sie die für die Zwischenspeicherung geeigneten Daten bestimmt haben, müssen Sie nachvollziehen, wie die Anwendung aktuell auf diese Daten zugreift und welche Arbeitsauslastungsmuster sich daraus ergeben. Am Ende dieses Schritts sollten Sie in der Lage sein, eine grobe Abschätzung Ihrer Anforderungen an den Cachespeicher zu formulieren. Sie sollten ferner ein besseres Verständnis für die Zugriffsweise und Verwendung der Daten erworben haben, was für spätere Schritten wichtig ist.

Wenn Sie beispielsweise den Produktkatalog als Kandidat für die Zwischenspeicherung ansehen, sollten Sie untersuchen, wann die Anwendung Katalogdaten abruft und wie häufig diese Anforderungen eintreffen. Ausgehend vom vorhergehenden Schritt wissen Sie, dass es sich um Referenzdaten handelt und daher auch um eine vorwiegend durch Lesezugriffe bestimmte Arbeitsauslastung. Für zukünftige Kapazitätsentscheidungen können Sie sich von einem tiefgehenden Verständnis der Arbeitsauslastungsmuster für verschiedene Objekte leiten lassen. An dieser Stelle sollten wir genauer betrachten, welche Punkte dieser Schritt im einzelnen umfasst.

Ein besseres Verständnis der aktuellen Datenzugriffsmuster kann auf verschiedene Weise erworben werden:

1. Überprüfen Sie den Code gründlich, um zu sehen, an welchen Stellen und wie häufig auf die Daten zugegriffen wird.

2. Verwenden Sie einen Codeprofiler, der die Häufigkeit von Methodenaufrufen und die entsprechenden Leistungsdaten zurückgeben kann.

3. Erstellen Sie Instrumentation in dem Code, der bestimmte Datenzugriffsabschnitte umgibt. Protokollieren Sie Datenzugriffsversuche und die zugehörige Leistung des Datenvorgangs.

4. Verwenden Sie einen Datenbankprofiler, wie etwa SQL Server Profiler, um die Anzahl und Dauer von Datenbankoperationen zu beobachten.

Beachten Sie, dass viele dieser Techniken möglicherweise schon im vorhergehenden Schritt verwendet wurden, um die für die Zwischenspeicherung geeigneten Daten zu bestimmen. In diesem Stadium liegt Ihr Augenmerk jedoch auf detaillierteren Zahlen, die für spätere Berechnungen zur Kapazitätsplanung verwendet werden können.

Ein Teil dieser Auswertung schließt das Verständnis des Verhältnisses von Lese- zu Schreibzugriffen ein. Die Lese-/Schreibauslastung kann einen Einfluss auf spätere Entscheidungen zur Kapazität haben. Beispielsweise bringt eine Arbeitsauslastung mit einem hohen Prozentsatz von Schreibvorgängen eine umfangreichere .NET Garbage Collection mit sich. Dies wird in einem späteren Schritt besprochen.

Ein weiterer Faktor ist die Häufigkeit von Lese- und Schreibvorgängen zu Spitzenlastzeiten. In der folgenden Tabelle sind Beispieldaten aufgelistet, die in diesem Stadium für das Einkaufswagenobjekt aus dem Beispiel erfasst wurden.

Zu analysierendes Objekt	Einkaufswagen
Lesevorgänge %	50%
Schreibvorgänge %	50%
Lesevorgänge pro Sekunde (Max)	250
Schreibvorgänge pro Sekunde (Max)	250

Diese Analyse sollte wiederum für jeden Objekttyp durchgeführt werden. Verschiedene Objekttypen weisen verschiedene Zugriffsmuster und unter Last verschiedene maximale Lese- und Schreibraten pro Sekunde auf.

Damit Sie die Cacheanforderungen ermitteln können, müssen Sie eine Schätzung für die maximale Anzahl aktiver Objekte jedes Typs zu jedem Zeitpunkt im Cache vornehmen. Diese Schätzung schließt ein Gleichgewicht zwischen der Häufigkeit von Objekteinfügungen und der Lebenserwartung dieser Objekte ein. Dies lässt sich besser anhand eines Beispiels verstehen.

Im Beispiel der ASP.NET-Webanwendung weisen die Betriebsdaten möglicherweise aus, dass Spitzenlasten von bis zu 25.000 gleichzeitigen Benutzern auftreten. Für jeden Benutzer sind Informationen zum Sitzungsstatus erforderlich, so dass 25.000 zwischengespeicherte Objekte benötigt werden. Die Ablaufzeit dieser Objekte kann jedoch beispielsweise auf 30 Minuten festgelegt werden. Aus den Betriebsdaten lässt sich ableiten, dass während der Spitzenzeiten mit 5.000 neuen Benutzern pro Stunde zu rechnen ist, d.h., dass während des Ablaufintervalls von 30 Minuten 2.500 neue Benutzer ankommen können. Darüber hinaus entscheiden sich manche Benutzer, ihre Browser zu schließen und eine neue Sitzung zu starten. Zwar handelt es sich um die gleichen Benutzer, sie verwenden jetzt jedoch eine andere Sitzung. Dafür sollte zusätzlich Kapazität eingeplant werden. Schließlich sollte ein zu erwartendes Wachstum für die nächsten 6-12 Monate eingeplant werden. Schließlich kann dann die Berechnung für die maximale Anzahl aktiver Objekte im Cache etwa wie folgt aussehen:

Zu analysierendes Objekt:	Einkaufswagen
Spitzenanzahl gleichzeitiger Benutzer	25000
Neue Benutzer während des Ablaufzeitraums (30 Minuten)	2500
Vorhandene Benutzer, die neue Browsersitzungen starten	250
Geschätztes zukünftiges Wachstum (25%)	6940
Aktive Objekte gesamt (Max):	~35.000 aktive Objekte maximal

Wenn Änderungen bei den Eingangsgrößen auftreten, etwa beim Ablaufzeitraum, wirkt sich das darauf aus, wie viele nicht abgelaufene Objekte sich während der Spitzenlast im Cache befinden. Dies ist lediglich ein Beispiel für den zugrunde gelegten Denkprozess. Bei anderen Objekttypen müssen möglicherweise andere Muster und Variablen in die Berechnung einfließen. Wenn beispielsweise ein freigegebener Produktkatalog für einen gesamten Tag gültig ist, sollte die maximale Anzahl der Produktkatalogobjekte im Cache während des Tages 1 sein.

Die Kenntnis der maximalen Anzahl der Objekte im Cache führt jedoch nur weiter, wenn auch die durchschnittliche Objektgröße bekannt ist. Das ist ein grundsätzlich schwieriges Problem. Im Einkaufswagenbeispiel kann ein Benutzer einen einzelnen Artikel in den Einkaufswagen legen, während ein anderer Benutzer vielleicht 10 oder 20 Artikel kaufen möchte. Das Ziel besteht darin, den Durchschnitt zu ermitteln. Wie bei den meisten Zahlen in diesem Prozess wird das nicht perfekt gelingen, das Endergebnis ist jedoch ein wohlüberlegter Ausgangspunkt für den Cachecluster anstelle bloßen Ratens.

Objekte werden im Cache in serialisierter Form gespeichert. Zum Verstehen der durchschnittlichen Objektgröße muss also die durchschnittliche Größe des serialisierten Objekts berechnet werden. AppFabric verwendet die Klasse NetDataContractSerializer für die Serialisierung, bevor die Elemente im Cache gespeichert werden. Zum Bestimmen der durchschnittlichen Objektgröße fügen Sie Ihrer Anwendung Instrumentationscode hinzu, der die Objekte serialisiert und ihre serialisierte Größe aufzeichnet.

Im folgenden Codebeispiel wird versucht, die durchschnittliche Größe eines Einzelobjekts zu schätzen. Das serialisierte Objekt hat den Namen obj. Die Variable length wird zum Aufzeichnen der Länge verwendet. Wenn Probleme beim Abrufen der Größe mithilfe von NetDataContractSerializer auftreten, wird stattdessen BinaryFormatter verwendet. Diese Methode kann zur einfacheren Verwendung umschlossen werden. In diesem Fall würde obj als Parameter übergeben, und length würde von der Methode zurückgegeben.

// requires following assembly references:
//
//using System.Xml;
//using System.IO;
//using System.Runtime.Serialization;
//using System.Runtime.Serialization.Formatters.Binary;
//
// Target object “obj”
//
long length = 0;

MemoryStream stream1 = new MemoryStream();
using (XmlDictionaryWriter writer = 
    XmlDictionaryWriter.CreateBinaryWriter(stream1))
{
    NetDataContractSerializer serializer = new NetDataContractSerializer();
    serializer.WriteObject(writer, obj);
    length = stream1.Length; 
}

if (length == 0)
{
    MemoryStream stream2 = new MemoryStream();
    BinaryFormatter bf = new BinaryFormatter();
    bf.Serialize(stream2, obj);
    length = stream2.Length;
}

Wenn Sie planen, AppFabric-Cache für den Sitzungsstatus zu verwenden, müssen Sie berücksichtigen, dass der SQL Server-Anbieter für den ASP.NET-Sitzungsstatus immer "BinaryFormatter" anstelle von "NetDataContractSerializer" verwendet. Bisweilen können mithilfe der NetDataContractSerializer-Klasse serialisierte Objekte mehrere Male größer sein als die serialisierte Größe von Objekten, die mithilfe von BinaryFormatter serialisiert wurden. Dies ist wichtig, wenn Sie die Größe von Sitzungsstatusobjekten in SQL Server betrachten, da Sie nicht von dieser Größe ausgehen können, in der Annahme, die Größe im Cache wäre die gleiche. Sie sollten diese Größe mit sechs multiplizieren, um einen groben Schätzwert zu erhalten. Zum Erhalten eines besseren Schätzwerts wenden Sie den oben dargestellten Code auf die im Sitzungsstatus gespeicherten Objekte an. Mit den bis zu diesem Punkt erfassten Daten können Sie jetzt beginnen, die Gesamtanforderungen an den Arbeitsspeicher zu berechnen. Dieser Schritt umfasst die folgenden Teilaufgaben:

1. Konzentration auf einen Objekttyp (z. B. das Objekt "Einkaufswagen").

2. Ermitteln Sie für dieses Objekt zuerst die durchschnittliche serialisierte Objektgröße.

3. Addieren Sie zu dieser Durchschnittsgröße 500 Byte, um den Cachemehraufwand zu berücksichtigen.

4. Multiplizieren Sie die erhaltene Größe mit der maximalen Anzahl der aktiven Objekte. Dadurch erhalten Sie die Summe der Cachespeicheranforderungen für diesen Objekttyp.

5. Addieren Sie einen geschätzten Mehraufwand für interne Cachestrukturen (5%).

6. Wiederholen Sie diese Schritte für jeden der identifizierten Objekttypen.

7. Aggregieren Sie die Ergebnisse, um die Gesamtsumme der Cachespeicheranforderungen zu ermitteln.

Beachten Sie, dass Sie in diesem Prozess näherungsweise 0,5 KB Mehraufwand pro Objekt zur Schätzgröße addieren sollten. Ferner gibt es weitere interne Datenstrukturen, die Arbeitsspeicher im Cache in Anspruch nehmen. Bereiche, Tags und Benachrichtigungen erfordern für ihre Verwaltung sämtlich weiteren Arbeitsspeicher. In unseren Beispielberechnungen addieren wir 5 Prozent der Summe, um diesen internen Strukturen Rechnung zu tragen, jedoch kann das in Ihrem Fall auch mehr oder weniger ausmachen, abhängig von dem Maß, in dem Sie diese Cachefunktionen verwenden.

An diesem Punkt sollten Sie den Einfluss einer bestimmten Funktion der AppFabric-Cache-Funktion berücksichtigen, nämlich Hohe Verfügbarkeit. Diese Funktion erstellt Kopien der im Cache zwischengespeicherten Elemente auf sekundären Servern. Dies bedeutet, dass beim Ausfall eines einzelnen Cacheservers der sekundäre Cacheserver übernimmt und keine Daten verloren werden. Wenn Sie sich für die Verwendung der Funktion für hohe Verfügbarkeit entscheiden, müssen Sie Ihre Arbeitsspeicherschätzung verdoppeln. Sie müssen darüber hinaus Windows Server 2008 Enterprise Edition oder höher verwenden. Beachten Sie, dass die Funktion für hohe Verfügbarkeit auf der Ebene des benannten Caches agiert. Dies bedeutet, dass – falls Sie sich entscheiden, innerhalb eines Clusters zwei benannte Caches zu erstellen – Sie nicht zwangsläufig auch für jeden Cache hohe Verfügbarkeit verwenden müssen. Die Anwendung kann einige Elemente in den benannten Cache mit hoher Verfügbarkeit und einige in den benannten Cache ohne hohe Verfügbarkeit einstellen. Dies kann bei der optimalen Nutzung Ihrer Arbeitsspeicherressourcen hilfreich sein. Es ist daher wichtig, die Entscheidung zum Einsatz von hoher Verfügbarkeit zu kennen, da sich dadurch die Speicheranforderungen für die Caches, die damit arbeiten, verdoppeln.

Als Beispiel folgt hier eine Tabelle, in der die Anforderungen für Aktivitätsdaten und Referenzdaten in der gleichen Anwendung ausgewertet werden. Je nach Ihrem Szenario können Sie sich entscheiden, die Schätzung auf der Objektebene oder der Anwendungsebene vorzunehmen. Sie müssten dem Beispiel lediglich weitere Spalten hinzufügen und diese entsprechend beschriften.

Zu analysierendes Objekt:	Aktivitätsdaten	Referenzdaten
Durchschnittliche serialisierte Objektgröße:	250 KB	60 KB
Cacheclustermehraufwand pro Objekt:	0,5 KB	0,5 KB
Angepasste durchschnittliche serialisierte Objektgröße:	250,5 KB	60,5 KB
Max. aktive Objekte:	~35000	~68000
Cachespeicheranforderungen:	8,4 GB	3,9 GB
Hohe Verfügbarkeit aktiviert?	16,8 GB	Nein
Mehraufwand für interne Datenstrukturen (5%):	0,8 GB	0,2 GB
Speichergesamtanforderungen:	17,6 GB	4,1 GB

Die Aggregierung dieser Schätzungen bildet den anfänglichen Arbeitsspeicherbedarf für den Cachecluster. In diesem Beispiel beträgt die Summe 21,7 GB. Auf der Grundlage dieser Schätzung können Sie sich jetzt auf andere Erwägungen konzentrieren, wie etwa die physische Infrastruktur, SLA-Anforderungen und die AppFabric-Einstellungen zur Cachekonfiguration.

Schritt 3: Grundlagen von physischer Infrastruktur und Hardwareressourcen

Sie müssen unbedingt über ein Verständnis Ihrer physischen Infrastruktur und der Verfügbarkeit von Ressourcen verfügen. Dies sind einige häufige Fragen:

1. Können physische Computer oder virtuelle Computer bereitgestellt werden?

2. Wenn vorhandene Hardware eingesetzt werden soll, wie sind die Computer konfiguriert (z. B. 8 GB Arbeitsspeicher, Vierkernprozessor)?

3. Soll sich der Cachecluster im gleichen Datencenter wie die Anwendungsserver befinden?

4. Welche Netzwerkressourcen stehen zur Verfügung?

Wenn Sie die Verwendung virtueller Computer für die Cacheserver erwägen, müssen einige Überlegungen angestellt werden. Beispielsweise muss der Einfluss durch die Ausführung mehrere virtueller Computer auf einem physischen Computer berücksichtigt werden. Mehrere virtuelle Computer müssen sich ggf. die gleiche Netzwerkkarte teilen, wodurch die Gefahr von Netzwerkengpässen steigt. Ferner kann hohe Verfügbarkeit zwischen einem primären und einem sekundären Cachehost eingerichtet werden, die beide als virtuelle Computer auf dem gleichen physischen Computer ausgeführt werden. Wenn dieser physische Computer abstürzt, besteht keine Kopie der Daten mehr. Weitere Informationen finden Sie unter Hilfestellung zum Ausführen von AppFabric-Caches auf einem virtuellen Computer.

Für vorhandene Computer gibt es keine empfohlenen Spezifikationen. Allerdings lässt sich sagen, dass bei einigen großen Clustern Computer mit Vierkernprozessor und 16 GB Arbeitsspeicher (RAM) gut funktioniert haben. Im Allgemeinen betreffen die wichtigsten Überlegungen die Planung der richtigen Menge an physischem Arbeitsspeicher und der Netzwerkauslastung.

Sowohl bei physischen als auch bei virtuellen Computern sollte der Standort des Cacheclusters für die Anwendungs- oder Webserver, die den Cache verwenden, notiert werden. Wenn sie sich in getrennten Datencentern befinden, achten Sie darauf, dass sich die Latenzzeiten zwischen den Datencentern nicht negativ auf die Leistung auswirken. An diesem Punkt kann die Versuchung groß sein, die Anwendung- oder Webserver als Cacheserver zu verwenden. Dies ist zwar möglich, wird aber nicht unterstützt. Erstens können sich jegliche Lastspitzen auf diesen Computern, wie etwa durch IIS, auf den Cachecluster auswirken. Zweitens geht der Cachedienst von der Annahme aus, dass er auf einem dedizierten Server ausgeführt wird und potenziell viel mehr Arbeitsspeicher als von Ihnen angegeben verwenden kann.

Hinsichtlich der Netzwerkressourcen sollten Sie die erwartete Netzwerkauslastung auswerten und sie mit der vorhandenen Infrastruktur vergleichen. Zuerst müssen Sie wissen, welche Datenmenge auf jedem Cacheserver erwartet wird und ob die Fähigkeiten der Netzwerkkarte ausreichen. Ist das nicht der Fall, können Sie weitere Cacheserver anfordern. Betrachten Sie beispielsweise ein Szenario, in dem die Durchschnittgröße von Objekten im Cache 500,5 KB beträgt und 240 Vorgänge pro Sekunden auf dem Cachecluster auftreten. Wenn ein einzelner Cachehost verwendet wird, ergeben sich dann folgende Zahlen:

Anzahl der pro Sekunde gelesenen/geschriebenen Objekte:	240
Anzahl der Computer im Cachecluster:	1
Anzahl der Cachevorgänge pro Computer pro Sekunde:	240
Durchschnittliche Objektgröße:	500,5 KB
Größe der pro Sekunde übermittelten Daten:	240 * 500,5 = 117,3 MB/s

Wenn jeder Computer über eine 1 GBit/s-Netzwerkkarte verfügt, ist der maximale Durchsatz ungefähr 119 MB/s. Der berechnete Wert von 117,3 MB/s würde diesen einen Server wahrscheinlich überfordern. Dadurch wird es sehr wahrscheinlich, dass sich das Netzwerk als Engpass erweist. Wenn jedoch drei Computer im Cachecluster verwendet werden, bewirkt eine gleichmäßige Verteilung der Cacheanforderungen eine Auslastung mit einem Drittel der berechneten Last auf jedem der Server.

Berücksichtigen Sie ebenfalls die Netzwerkauslastung der Anwendungsserver, die auf den Cachecluster zugreifen. Wenn diese große Datenmengen mit anderen Systemen austauschen, sollten Sie den Aufbau eines dedizierten Netzwerks zwischen den Anwendungsservern und dem Cachecluster in Erwägung ziehen. Für diesen Zweck ist der Einbau einer zusätzlichen Netzwerkkarte auf jedem Anwendungsserver erforderlich.

Die abschließende Überlegung zum Netzwerk betrifft die Frage, ob das Netzwerk die erforderliche Last entlang des gesamten Pfads verarbeiten kann. Lediglich eine 1GBit/s-Netzwerkkarte auf jedem Cacheserver zu installieren, ist nicht ausreichend. Der Switch und andere Punkte im Netzwerk müssen ebenfalls imstande sein, die Last zu verarbeiten. Arbeiten Sie mit den Administratoren zusammen, um dieser Anforderung zu entsprechen.

Schritt 4: Abschließen des erforderlichen Leistungs-SLAs für alle Anwendungen

Bevor Sie sich für eine endgültige Konfiguration entscheiden, müssen Sie auch alle Geschäftsanforderungen, einschließlich Vereinbarungen zum Servicelevel (SLAs, Service Level Agreements) hinsichtlich Leistung und Zuverlässigkeit, verstanden haben. Praktisch beeinflusst dieser Schritt die Entscheidung zur Anzahl der Cachecluster und der Anzahl der Cachehosts in jedem Cluster.

Wenn Sie z. B. eine unternehmenswichtige Anwendung, die einen Cachehost verwendet, einsetzen, kann es durchaus sinnvoll sein, den betreffenden Cachecluster von Anwendungen mit geringerer Priorität zu isolieren. Diese Anwendungen geringerer Priorität könnten potenziell mehr Arbeitsspeicher-, Netzwerk- oder CPU-Ressourcen verwenden und so einen negativen Einfluss auf die Ausführung der unternehmenswichtigen Anwendung haben.

Hier sind einige spezifische Faktoren, die sich auf diese Entscheidung auswirken:

• Die Sicherheit auf der Cacheclusterebene bleibt gewahrt. Wenn ein Benutzer Zugriff auf den Cachecluster hat, kann er potenziell auf alle Daten auf dem Cachecluster zugreifen (vorausgesetzt, der Benutzer kennt den Cachenamen und den anzufordernden Schlüssel). Wenn Sie verschiedene Sicherheitseinstellungen für verschiedene Typen von Daten benötigen, können getrennte Cachecluster sinnvoll sein. Weitere Informationen finden Sie unter Verwalten der Sicherheit.

• Entfernung nicht abgelaufener Elemente tritt auf, wenn der Arbeitsspeicher den hohen Grenzwert erreicht. Ein Unterschätzen der für einen Cache erforderlichen Menge Arbeitsspeicher kann sich negativ auf alle Caches im Cluster auswirken. Wenn Entfernung aufgrund von ungenügendem Arbeitsspeicher auftritt, geschieht dies quer über alle Caches, selbst wenn nur ein Cache für den ungenügenden Arbeitsspeicher verantwortlich ist. Dies kann etwas durch Erstellen von Caches ohne Entfernung gemildert werden, jedoch muss dies vorsichtig geschehen. Weitere Informationen finden Sie unter Ablauf und Entfernung.

• Die Verwaltung kann mit separaten Cacheclustern bis zu einem gewissen Grad einfacher sein. Sie werden vermutlich keine separaten Cluster für 100 verschiedene Caches verwalten möchten. Es kann jedoch sinnvoll sein, separate Cachecluster für zwei verschiedene große Caches zu verwenden, da sie dann separat verwaltet, skaliert und überwacht werden können.

Schließlich müssen bei einigen Anforderungen auch Latenz und Durchsatz berücksichtigt werden. Damit Sie diese Entscheidung gut informiert treffen können, konsultieren Sie das Grid Dynamics-Whitepaper als Quelle für Hilfestellung und Testergebnisse. Beispielsweise können Sie Ihre Durchsatzanforderungen für den Cachecluster mit den veröffentlichten Testergebnissen aus dem Grid Dynamics-Papier vergleichen. Diese Studie kann z. B. nahelegen, dass Sie zu wenige Server für den angezielten Durchsatz vorgesehen haben. Sie müssen sich jedoch bewusst sein, dass die Studie den Objekttypen, den Objektgrößen und der physischen und logischen Infrastruktur in Ihrem Szenario möglicherweise nicht genau entspricht. Sie stellt jedoch geprüfte Testergebnisse zur Verfügung, die Ihnen helfen können, eine informierte Entscheidung zu treffen.

Schritt 5: Bestimmen der geeigneten AppFabric-Funktionen und -Konfigurationseinstellungen

Bei diesem Teil des Prozesses werden bestimmte Konfigurationseinstellungen von AppFabric-Cache sowie die Architektur eines AppFabric-Cacheclusters beleuchtet. Selbst wenn die richtigen empirischen und Unternehmensdaten erfasst wurden, kann ein Außerachtlassen dieser AppFabric-Cache-Einstellungen trotzdem zu einer Fehlplanung führen.

In der folgenden Tabelle ist eine Vielzahl von AppFabric-Cache-Funktionen mit den zugehörigen Erwägungen für die Kapazitätsplanung aufgelistet.

Bereiche	Sie können mehrere Bereiche erstellen, doch wird jeder Bereich auf einem einzelnen Cachehost ausgeführt. Anwendungen müssen mehrere Bereiche verwenden, um den verteilten Speicher nutzen zu können. Beachten Sie, dass alle Aufrufe, in denen keine Bereiche angegeben sind, intern automatisch Standardbereiche verwenden. Jeder Cachehost im Cachecluster muss in der Lage sein, die Maximalgröße des größten Bereichs bereitzustellen.
Benachrichtigungen	Caches können Benachrichtigungen aktivieren, und Cacheclients können diese Benachrichtigungen empfangen. Dadurch entstehen serverseitig zusätzlicher Netzwerkverkehr und zusätzliche Prozessorauslastung. Die Auswirkungen hängen vom Benachrichtigungsintervall und der Anzahl der gesendeten Benachrichtigungen ab. Eine große Anzahl von Benachrichtigungen bei sehr kurzen Intervallen kann einen Einfluss auf Skalierbarkeit und Leistung haben. Es bestehen keine festen Richtlinien für die Abschätzung dieses Einflusses, daher muss das Verhalten während der Tests beobachtet werden.
Lokaler Cache	Lokaler Cache verbessert die Leistung durch Zwischenspeicherung von Objekten auf den Clients sowie auf dem Server. Bedenken Sie den Einfluss auf den Arbeitsspeicher auf Clientcomputern, wenn Sie lokalen Cache verwenden. Dieses Feature wirkt sich nicht auf die serverseitige Kapazitätsplanung für den Arbeitsspeicher aus, da alle lokal zwischengespeicherten Elemente auch auf dem Server vorhanden sind. Wenn jedoch Benachrichtigungen für die Invalidierung des lokalen Caches verwendet werden, kann die Serverseite von der Verarbeitung der Benachrichtigungen betroffen sein.
Anwendungsentwurf und Konfiguration auf der Clientseite	Der clientseitige Anwendungsentwurf kann sich auf die Gesamtleistung auswirken. Beispielsweise ist es sinnvoll, die erstellten DataCacheFactory-Objekte zur Wiederverwendung zu speichern, statt sie für jeden Aufruf erneut zu erstellen. Ferner kann es vorteilhaft sein, für jeden Thread ein DataCacheFactory-Objekt zu erstellen. Wenn Sie hingegen ein gemeinsames DataCacheFactory-Objekt für mehrere Threads verwenden, erwägen Sie, die Einstellung "MaxConnectionsToServer" heraufzusetzen. Dadurch wird die Anzahl der Verbindungen mit den Cacheservern pro DataCacheFactory erhöht.
Hohe Verfügbarkeit	Wie bereits festgestellt, erfordern Caches, die hohe Verfügbarkeit verwenden, den doppelten errechneten Arbeitsspeicher. Für diese Funktion ist jedoch außerdem eine Mindestanzahl von drei Servern erforderlich. Wenn einer der Server ausfällt, müssen zwei verbleibende Server verfügbar sein, um die primäre und die sekundäre Kopie jedes Elements nach einem Ausfall zu unterstützen. Beachten Sie, dass für diese Funktion außerdem Windows Server 2008 Enterprise Edition oder höher auf allen Servern erforderlich ist.
Benannte Caches	Aktuell besteht ein Grenzwert von 128 benannten Caches. Dies wird dann zu einer Einflussgröße für die Kapazitätsplanung, wenn Sie Anwendungen einsetzen, die mehr als diese festgelegte Anzahl erfordern. An diesem Punkt benötigen Sie mehr als einen Cachecluster, oder Ihre Anwendungen müssen so ausgelegt werden, dass sie mit einer kleineren Anzahl Caches auskommen. Eine andere Strategie kann darin bestehen, programmgesteuert Bereiche innerhalb von benannten Caches zu erstellen.
XML-Konfigurationsspeicher	Wenn Sie einen freigegebenen Netzwerkspeicherort für Ihren Cachecluster-Konfigurationsspeicher verwenden, sollten Sie wenigstens drei Server im Cluster verwenden, die als führende Hosts festgelegt sind. Weitere Informationen zu den Gründen finden Sie unter Aktualisieren von Cacheservern.

Es sollte nicht überraschen, dass eine der wichtigsten Einstellungen auf jedem der Cachehosts die Arbeitsspeichereinstellung ist. Sie können die standardmäßigen Arbeitsspeichereinstellungen auf jedem der Cachehosts mithilfe des Windows PowerShell-Befehls Get-CacheHostConfig anzeigen.

Der folgende Screenshot zeigt die Ausgabe von Get-CacheHostConfig auf einem Computer mit 4 GB Arbeitsspeicher (RAM).

Standardmäßig beträgt die Menge des für den Cache reservierten Arbeitsspeichers auf einem Server 50% des gesamten Arbeitsspeichers. In diesem Beispiel ist die Hälfte des Arbeitsspeichers 2 GB. Der verbleibende Arbeitsspeicher steht dann dem Betriebssystem und den Diensten zur Verfügung. Selbst auf Computern mit wesentlich mehr Arbeitsspeicher empfiehlt es sich, diese Standardeinstellung beizubehalten. Wie bereits erwähnt geht der Cachedienst davon aus, dass er auf einem dedizierten Computer ausgeführt wird und erheblich mehr Arbeitsspeicher beanspruchen kann, als für den Cache zugewiesen wurde. Zwar ist ein Teil dieses Speichergebrauchs auf die interne Auslegung des Cachediensts zurückzuführen, zum Teil hängt er jedoch auch mit der .NET-Arbeitsspeicherverwaltung und Garbage Collection zusammen. Selbst wenn Arbeitsspeicher freigegeben wird, muss er in einer .NET-Anwendung auf die Garbage Collection warten, um vom Prozessspeicher freigesetzt zu werden. Für den Prozess ist ein Puffer an physischem Arbeitsspeicher erforderlich, um dem nicht deterministischen Charakter der Garbage Collection Rechnung zu tragen.

Wenn Sie den Einfluss von Garbage Collection in der Praxis verstanden haben, werden Sie feststellen, dass Arbeitsauslastungen mit einem hohen Prozentanteil und großer Häufigkeit von Schreibvorgängen einen großen Arbeitsspeicherpuffer für die Garbage Collection-Zyklen benötigen. Auf Arbeitsauslastungen, deren Schwerpunkt auf Lesezugriffen liegt, trifft diese Überlegung nicht zu. In diesem Fall können Sie in Einzelfällen erwägen, die Menge des für den Cache reservierten Arbeitsspeichers heraufzusetzen. Z. B. können Sie auf einem Computer mit 16 GB Arbeitsspeicher 12 GB für die Cachegrößeneinstellung (anstelle der standardmäßigen 8 GB) reservieren, was noch 4 GB Mehraufwand für Betriebssystem und Dienste bereitstellt. Dabei wird davon ausgegangen, dass der Computer ausschließlich für den Cachedienst verwendet wird – dies stellt ohnehin zurzeit die einzig unterstützte Konfiguration dar. In diesem Beispiel sollten Sie diese Arbeitsspeicherkonfiguration mit der vorhergesehen Last testen. Wenn die Zuordnung des Arbeitsspeichers zu aggressiv ist, macht sich diese Fehleinschätzung bei den Tests durch speicherbezogene Probleme, wie Entfernung oder Einschränken der maximalen Bandbreite, bemerkbar. Weitere Informationen finden Sie unter Behandlung von Serverproblemen (Windows Server AppFabric-Cache). Im folgenden Beispiel wird der Befehl Set-CacheHostConfig verwendet, um die Cachegröße auf einem Server mit dem Namen Server1 auf 12 GB festzulegen:

Set-CacheHostConfig -HostName Server1 -CachePort 22233 -CacheSize 12288

Das andere Element, das in der Get-CacheHostConfig-Ausgabe beachtet werden muss, betrifft die Grenzwerte. Der untere Grenzwert (LowWatermark) weist standardmäßig einen Wert von 70% der Cachegrößeneinstellung auf. Wenn der Cachearbeitsspeicher den unteren Grenzwert erreicht, beginnt der Cachedienst mit der Entfernung von Objekten, die bereits abgelaufen sind. Dies ist völlig in Ordnung, da auf diese Objekte ohnehin nicht zugegriffen werden kann.

Der obere Grenzwert (HighWatermark) weist standardmäßig einen Wert von 90% der Cachegrößeneinstellung auf. Beim Erreichen des oberen Grenzwerts werden Objekte entfernt, unabhängig von ihrem Ablaufzustand, bis der Arbeitsspeicher wieder den unteren Grenzwert erreicht. Offensichtlich hat dieses Vorgehen das Potenzial, die Leistung empfindlich zu beeinträchtigen und zu einer schlechten Benutzererfahrung zu führen.

Es empfiehlt sich daher, den Cachegebrauch anhand des unteren Grenzwerts zu planen, um die Gefahr, den oberen Grenzwert zu erreichen, zu vermeiden. Eine detailliertere Beschreibung finden Sie unter "Ablauf und Entfernung".

In einem früheren Beispiel wurde eine Schätzung von 21,7 GB als Gesamtanforderung für den Cachearbeitsspeicher errechnet. Da hohe Verfügbarkeit gewünscht ist, müssen mindestens drei Server vorhanden sein. Wir gehen von 16 GB Arbeitsspeicher pro Server aus. In diesem Beispiel bleibt die standardmäßige Cachegrößeneinstellung von 8 GB pro Server unverändert. Wie zuvor erwähnt, sollte der untere Grenzwert (70%) das auf jedem Server verfügbare Arbeitsspeicherziel darstellen. Dies bedeutet, dass auf jedem Cacheserver geschätzt 5,6 GB Arbeitsspeicher zur Verfügung stehen. Ausgehend von diesen Faktoren zeigt die folgende Tabelle, dass die vier Server 22,4 GB Cachespeicher bereitstellen und so der Anforderung von 21,7 GB entsprechen würden.

Speichergesamtanforderung	21,7 GB
Anfänglicher Arbeitsspeicher (Cachehost)	16 GB
Cachegrößeneinstellung (Cachehost)	8 GB
Unterer Grenzwert (Cachehost)	70%
Angepasstes Arbeitsspeicherziel pro Cachehost	5,6 GB
Gesamtarbeitsspeicher auf dem Cachecluster (3 Computer)	5,6 GB * 4 Server = 22,4

Beachten Sie auch hier, dass Sie auch die im Grid Dynamics-Whitepaper veröffentlichten Ergebnisse verwenden können, um diese Schätzung im Verhältnis zu den Durchsatz- und Latenzzielen zu überprüfen. Diese Testergebnisse könnten zu geringfügigen Änderungen bei dieser ersten Schätzung führen, etwa durch Hinzufügen eines weiteren Cacheservers. Der wichtige Aspekt hier ist jedoch, die verfügbaren Ressourcen zu verwenden, um eine Entscheidung auf der Grundlage von Informationen zu treffen.

Kapazitätsplanungstool

Eine Kalkulationstabelle stellt das logische Tool für die Schritte zur Kapazitätsplanung in den vorhergehenden Abschnitten dar. Dafür steht eine Beispieltabelle zur Verfügung, die hier heruntergeladen werden kann. Einträge mit einem Sternsymbol stellen Elemente dar, die aufgrund von Planung und verfügbaren Ressourcen geändert werden sollten. Die verbleibenden Berechnungen werden von der Kalkulationstabelle ausgeführt.

Im ersten Teil der Kalkulationstabelle wird die Serverkonfiguration für die einzelnen Cachehosts angegeben. Beachten Sie, dass diese im Rahmen des Planungsprozesses geändert werden kann, um die Unterschiede in den endgültigen Berechnungen zu beobachten. Im folgenden Screenshot ist dieser erste Abschnitt dargestellt.

Im zweiten Abschnitt können Sie Schätzwerte für verschiedene Arten von Objekten einsetzen. In der Beispielkalkulationstabelle werden nur zwei Abschnitte für "Activity Data" (Aktivitätsdaten) und "Reference Data" (Referenzdaten) verwendet. Es schließt sich eine Reihe leerer Spalten an. Sie können diese Spalten umbenennen, abhängig von der Granularität Ihrer Planung (Objekt, Kategorie, Anwendung usw.). Im folgenden Screenshot ist dieser zweite Abschnitt dargestellt.

Im dritten Abschnitt werden die Netzwerkanforderungen geschätzt. Sie setzen die durchschnittlichen gelesene bzw. geschriebene Objektgröße und die maximale Anzahl der Lese-/Schreibvorgänge pro Sekunde ein. Der Abschnitt errechnet die maximale Anforderung an die Netzwerkbandbreite für den betreffenden Objekttyp. Dies kann verwendet werden, um eine grobe Einschätzung zu erhalten, ob die vorhandene Ausstattung an Computern und Netzwerkkarten die Last verarbeiten kann. Wie bereits im vorhergehenden Abschnitt erörtert, muss die Bandbreite entlang des gesamten Netzwerkpfads ebenfalls berücksichtigt werden. Im folgenden Screenshot ist dieser dritte Abschnitt dargestellt.

Im letzten Abschnitt werden die Anforderungen aus den Arbeitsspeicher- und den Netzwerkabschnitten aggregiert. Anschließend werden die Angaben zur Computerkonfiguration aus dem ersten Abschnitt verwendet, um die Berechnung der Anzahl der Server auszuführen. Im Feld "Additional Servers" (Weitere Server) können Sie diese errechnete Summe ggf. erhöhen. Wenn z. B. in den Berechnungen angegeben wurde, dass nur zwei Server erforderlich sind, können Sie der Endsumme einen weiteren Server hinzufügen, um hohe Verfügbarkeit ordnungsgemäß zu unterstützen. Im folgenden Screenshot ist dieser letzte Abschnitt dargestellt.

Nächste Schritte bei der Kapazitätsplanung

Im vorhergehenden Abschnitt wurde eine Methodik zum Bestimmen einer anfänglichen Schätzung für die Anzahl der Cachecluster, die Anzahl der Cachehosts und die Konfiguration dieser Cachehosts vorgestellt. Sie sollten sich jedoch bewusst sein, dass es sich um eine Schätzung handelt, die ggf. auf der Grundlage von Tests und von fortlaufender Überwachung geändert werden muss.

Wenn Sie sich entscheiden, Ihre Pläne zum Einsatz von AppFabric-Cache voranzutreiben, können Sie eine Machbarkeitsstudie erstellen, um ein Gefühl dafür zu entwickeln, wie AppFabric-Cache in Ihrer Lösung funktioniert. Anschließend bietet sich die Einrichtung eines Testcacheclusters an, um Tests in Ihrer Umgebung durchzuführen. Abhängig von den Testergebnissen können Sie weitere Änderungen an der Konfiguration vornehmen, um den Anforderungen an Kapazität, Leistung und Skalierbarkeit zu entsprechen. Im folgenden Abschnitt werden bestimmte fortlaufende Metriken behandelt, die sowohl während eines Test- als auch während des Produktionsbetriebs verfolgt werden können.

Überwachen der fortlaufenden Anforderungen an die Cachekapazität

Das Planen von Cachekapazität stellt keine exakte Wissenschaft dar. Viele der Größen, die in Schlussfolgerungen eingehen, stellen ihrerseits Schätzwerte dar. Darüber hinaus können sich Verwendung und Verwendungsmuster von Anwendungen im Lauf der Zeit ändern. Daher sollten Sie die Leistungsindikatoren im Auge behalten, um sicherzustellen, dass der Cachecluster den Kapazitätsanforderungen genügt. Erfolgreiche Kapazitätsplanung ist ein kontinuierlicher Prozess, der sich sowohl in Test- als auch in Produktionsumgebungen fortsetzt.

Das Systemmonitor-Tool stellt die beste Möglichkeit zur fortlaufenden Überwachung der Kapazität dar. Sie sollten auf jedem Cachehost die folgenden Indikatoren verfolgen:

Überwachungskategorie	Indikatoren des Systemmonitors
Arbeitsspeicher	AppFabric-Cache:Host\Datenvolumen gesamt in Byte AppFabric-Cache:Host\Entfernte Objekte gesamt AppFabric-Cache:Host\Entfernungsdurchgänge gesamt AppFabric-Cache:Host\Entfernter Arbeitsspeicher gesamt AppFabric-Cache:Host\Objektanzahl gesamt .NET CLR-Speicher(DistributedCacheService)\Auflistungsanzahl der Generation 0 .NET CLR-Speicher(DistributedCacheService)\Auflistungsanzahl der Generation 1 .NET CLR-Speicher(DistributedCacheService)\Auflistungsanzahl der Generation 2 .NET CLR-Speicher(DistributedCacheService)\Anzahl der fixierten Objekte .NET CLR-Speicher(DistributedCacheService)\GC-Zeitdauer in Prozent .NET CLR-Speicher(DistributedCacheService)\Objektheapgröße .NET CLR-Speicher(DistributedCacheService)\Heapgröße der Generation 0 .NET CLR-Speicher(DistributedCacheService)\Heapgröße der Generation 1 .NET CLR-Speicher(DistributedCacheService)\Heapgröße der Generation 2 Arbeitsspeicher\Verfügbare MB
Netzwerk	Netzwerkschnittstelle(*)\Empfangene Bytes/s Netzwerkschnittstelle(*)\Gesendete Bytes/s Netzwerkschnittstelle(*)\Aktuelle Bandbreite
CPU	Prozess(DistributedCacheService)\Prozessorzeit (%) Prozess(DistributedCacheService)\Threadanzahl Prozess(DistributedCacheService)\Workingset Prozessor(_Total)\Prozessorzeit (%)
Durchsatz	AppFabric-Cache:Host\Clientanforderungen gesamt AppFabric-Cache:Host\Clientanforderungen gesamt/s AppFabric-Cache:Host\Abrufanforderungen gesamt AppFabric-Cache:Host\Abrufanforderungen gesamt/s AppFabric-Cache:Host\Abrufanforderungen gesamt AppFabric-Cache:Host\Abrufanforderungen gesamt/s AppFabric-Cache:Host\GetAndLock-Anforderungen gesamt AppFabric-Cache:Host\GetAndLock-Anforderungen gesamt/s AppFabric-Cache:Host\Leseanforderungen gesamt AppFabric-Cache:Host\Leseanforderungen gesamt/s AppFabric-Cache:Host\Schreibvorgänge gesamt AppFabric-Cache:Host\Schreibvorgänge gesamt/s
Verschiedenes	AppFabric-Cache:Host\Cachefehler-Prozentsatz AppFabric-Cache:Host\Abgelaufene Objekte gesamt AppFabric-Cache:Host\Übermittelte Benachrichtigungen gesamt

Viele der hier aufgelisteten Indikatoren stehen in direktem Zusammenhang mit dem Kapazitätsplanungsprozess. Beispielsweise gibt es eine ganze Reihe von Indikatoren zum Arbeitsspeicher. "Arbeitsspeicher\Verfügbare MB" zeigt an, wieviel physischer Arbeitsspeicher im MB auf dem Computer verfügbar ist. Wenn dieser Indikator 10% des gesamten physischen Arbeitsspeichers unterschreitet, besteht eine erhebliche Gefahr, dass Bandbreiteneinschränkungen auftreten. Weitere Informationen finden Sie unter Problembehandlung bei Bandbreiteneinschränkung. Andere Indikatoren sind für bestimmte Cachefeatures spezifisch. "AppFabric-Cache:Host\Entfernungsdurchgänge gesamt" zeigt an, wie häufig Arbeitsspeicher entfernt wird. Wenn die Arbeitsspeichernutzung den oberen Grenzwert überschreitet, weist dieser Indikator die Entfernungsdurchgänge aus, bis der Arbeitsspeicher wieder auf den unteren Grenzwert gebracht wird. In ähnlicher Weise hängen die sonstigen Indikatoren mit dem Denkprozess zur Kapazitätsplanung zusammen, der in den vorhergehenden Abschnitten dieses Dokuments beschrieben wurde.

Achten Sie darauf, auch die Prozessindikatoren für den Dienst, DistributedCacheService, und den Prozessorindikator für den Computer zu erfassen. Eine hohe Prozessorauslastung kann sich negativ auf die Leistung des Cacheclusters auswirken. Wenn Phasen hoher Prozessorauslastung erkannt werden, ist es wichtig, herauszufinden, ob dies mit dem Cachedienst ("DistributedCacheService.exe") oder mit einem anderen auf dem Computer ausgeführten Dienst zusammenhängt.

Über den Systemmonitor hinaus können auch die Windows PowerShell-Befehle, die zusammen mit AppFabric installiert werden, verwendet werden. Viele dieser Befehle können verwendet werden, um die Integrität und den Status des Cacheclusters zu überwachen. Weitere Informationen finden Sie unter Systemüberwachungstools und Protokollierung und Indikatoren im AppFabric-Cache.

Siehe auch

Weitere Ressourcen

Installieren von Windows Server AppFabric
MSDN Windows Server AppFabric-Cachedokumentation
Programmierhandbuch für AppFabric-Caches
Konfigurieren eines ASP.NET-Sitzungsstatusanbieters
Speicheroptionen für die Cacheclusterkonfiguration
Handbuch zur Windows Server AppFabric-Cachebereitstellung und -Verwaltung
Links und Ressourcen zu Windows Server AppFabric

  2012-03-05