Průvodce plánováním kapacity ukládání do mezipaměti technologie Windows Server AppFabric

Jason Roth, Rama Ramani, Jaime Alva Bravo

Březen 2011

Tento dokument white paper poskytuje pokyny k plánování kapacity ukládání do mezipaměti technologie Windows Server AppFabric.

1. Úvod

2. Vyhodnocení výkonu ukládání do mezipaměti technologie AppFabric

3. Metodika plánování kapacity

   1. Krok 1: Zjištění kritických míst a identifikace dat ukládaných do mezipaměti

   2. Krok 2: Vyhodnocení aktuálních průběhů zatížení

   3. Krok 3: Znalost fyzické infrastruktury a hardwarových prostředků

   4. Krok 4: Finalizace smlouvy SLA o požadovaném výkonu všech aplikací

   5. Krok 5: Identifikace příslušných funkcí a konfigurace technologie AppFabric

4. Nástroj pro plánování kapacity

5. Další kroky při plánování kapacity

6. Monitorování průběžných požadavků na kapacitu ukládání do mezipaměti

Úvod

Ukládání do mezipaměti technologie Windows Server AppFabric poskytuje distribuovaný cluster mezipamětí v paměti. Tento dokument obsahuje pokyny k plánování kapacity pro místní nasazení ukládání do mezipaměti technologie Windows Server AppFabric.

Architektura ukládání do mezipaměti technologie Windows Server AppFabric je podrobně popsána v dokumentaci. Další informace naleznete v tématu Funkce ukládání do mezipaměti technologie Windows Server AppFabric. Cluster mezipamětí technologie AppFabric je tvořen jedním nebo více servery mezipaměti (které jsou rovněž označovány jako hostitelé mezipaměti). Mezipaměti jsou rozděleny mezi tyto hostitele mezipaměti a uloženy v paměti.

Poznámka

Existuje rovněž verze využívající technologii Windows Azure AppFabric určená pro ukládání do mezipaměti v cloudu. Některé kroky v tomto dokumentu, které se týkají odhadu paměťových nároků, budou platit také pro cloudové řešení, ale tento dokument se zaměřuje konkrétně na místní nasazení clusteru mezipamětí. Další informace o používání funkce ukládání do mezipaměti technologie Azure AppFabric naleznete v tématu Ukládání do mezipaměti technologie Windows Azure AppFabric.

Informace v tomto dokumentu se opírají o plánovací činnosti, které společnost Microsoft provádí ve spolupráci se zákazníky. Všichni zákazníci, kteří chtějí používat ukládání do mezipaměti technologie AppFabric, pokládají stejnou otázku: „Kolik serverů bude zapotřebí pro naši situaci?“ V mnoha těchto diskuzích začneme typickou odpovědí: „Jak se to vezme.“ Poté rychle probereme různé podrobnosti a nakonec se dostaneme do vhodného výchozího bodu. Během tohoto procesu začnou padat konkrétnější otázky:

• Kolik paměti vyžadují naše aplikace k ukládání do mezipaměti?

• Kolik počítačů bychom měli použít v clusteru mezipamětí?

• Kolik paměti by mělo být v každém počítači a jak má být nakonfigurovaná?

• Nakolik ovlivňuje šířka pásma sítě výkon clusteru mezipamětí?

Cílem tohoto dokumentu je shromáždit poznatky získané z těchto typů diskusí se zákazníky a poskytnout metodiku, kterou lze využít při plánování kapacity.

Pokud čtete tento dokument, zřejmě se nacházíte v jedné z několika vývojových fází:

1. Začínáte přemýšlet o distribuovaném ukládání do mezipaměti, ale nemáte žádné podrobné údaje o kombinaci zatížení, výkonových požadavcích ani topologii nasazení serverů. V této situaci můžete začít prostudováním výkonnostních údajů ukládání do mezipaměti technologie AppFabric.

2. Už jste zkoumali funkce a výkon ukládání do mezipaměti technologie AppFabric. Nyní se potřebujete podrobněji podívat na svoji konkrétní situaci a základní požadavky. V tomto okamžiku se dostanete k podrobnostem plánování kapacity.

3. Ukládání do mezipaměti již máte nasazeno do provozu. V této fázi chcete zjistit, jak analyzovat výkonnostní data a zajistit dostatečnou kapacitu. Kromě toho chcete počítat s budoucím zvýšením zatížení, přičemž na základě průběžného chování mezipaměti technologie AppFabric znáte klíčové ukazatele a osvědčené postupy.

Tento dokument white paper je strukturován tak, že jsou tyto fáze postupně vysvětleny. Pokud pouze vyhodnocujete výkon technologie AppFabric, můžete prostudovat komplexní dokument white paper, který vytvořil náš partner Grid Dynamics. Data z tohoto dokumentu white paper zde budou seskupena přehledným způsobem, který vám umožní vyhodnocení a získání informací o plánování kapacity.

Jste-li připraveni absolvovat proces plánování kapacity, poskytneme vám sadu kroků pro formalizaci metodiky, které můžete použít ve své situaci.

Jestliže cluster mezipamětí používáte nebo testujete, můžete proces plánování kapacity ověřit prostudováním sady klíčových ukazatelů výkonu, což vám pomůže zajistit správnou kapacitu. Kromě toho budete seznámeni s některými osvědčenými postupy.

Vyhodnocení výkonu ukládání do mezipaměti technologie AppFabric

Náš partner, společnost Grid Dynamics, nedávno provedl sérii výkonnostních testů ukládání do mezipaměti technologie AppFabric. Své výsledky publikoval v následujícím dokument white paper: Mezipaměť technologie Windows Server AppFabric: datový list s podrobnými údaji o výkonu a škálovatelnosti.

Každý test je zaměřen na určitou proměnnou, jako je například velikost mezipaměti nebo počet serverů v clusteru mezipamětí. Studii společnosti Grid Dynamics lze použít k vyhodnocení výkonu a škálovatelnosti ukládání do mezipaměti technologie AppFabric. Údaje o propustnosti a latenci získané pro celou řadu testovacích situací a topologií můžete porovnat s požadavky své aplikace. V jednotlivých testech byly zpravidla pozměněny pouze jeden či dva parametry, aby bylo možné vyhodnotit jejich vliv na výkon. Do úplné sady parametrů patří:

Průběh zatížení	Průběh využití mezipaměti, tedy procento operací Get, Put, BulkGet, GetAndLock a PutAndUnlock
Velikost dat ukládaných do mezipaměti	Množství dat ukládaných do mezipaměti během testu
Velikost clusteru	Počet serverů v clusteru mezipamětí
Velikost objektu	Velikost objektů ukládaných do mezipaměti po serializaci
Složitost typů	Různé typy objektů rozhraní .NET ukládané do mezipaměti, například bajt, řetězec[] apod.
Zabezpečení	Nastavení zabezpečení clusteru mezipamětí

Kromě ověření výkonu a škálovatelnosti ukládání do mezipaměti technologie AppFabric poskytla společnost Grid Dynamics testovací nástroje, které vám umožní reprodukovat tyto testy s vlastními daty a úlohami. To je další možnost, jak můžete vyhodnotit výkon ukládání do mezipaměti ve své konkrétní situaci.

Ačkoli vřele doporučujeme, abyste prostudovali celou studii a její závěry, zde je shrnutí několika poznatků, které objasní osvědčené postupy uvedené ve zbylých částech tohoto dokumentu:

• Ukládání do mezipaměti technologie AppFabric je při přidávání dalších počítačů do clusteru mezipamětí škálováno lineárně.

• Vliv velikosti mezipaměti je malý, s výjimkou velkých mezipamětí s vysokým procentem zápisů. Zatížení s převahou zápisů vyvíjí mezi jinými faktory větší tlak na uvolňování paměti rozhraní .NET, pokud je velikost spravované haldy velká.

• Velká složitost typů ovlivňuje kvůli serializaci pouze výkon na straně klienta.

• Hromadná volání operace get mají za následek lepší využití sítě. Přímý přístup do mezipaměti je mnohem rychlejší než proxy servery (ASP.NET, WCF), ale je tomu tak díky výkonu prostřední vrstvy, nikoli díky výkonu ukládání do mezipaměti.

• Výkon pesimistického a optimistického zamykání je podobný, měli byste proto použít techniku, která je nejvhodnější pro návrh dané aplikace. Při snižování míry konfliktů se zlepšuje jak latence, tak propustnost.

• Zabezpečení clusteru mezipamětí snižuje výkon a ve výchozím nastavení je povoleno. Nejvyšší propustnosti a nejnižší latence lze dosáhnout při vypnutém zabezpečení, to však může být nepřijatelné vzhledem k citlivé povaze dat a požadavkům podniku.

• Při použití vyhrazené sítě mezi aplikačními servery a servery mezipaměti jsou eliminována kritická místa sítě.

Dokument společnosti Grid Dynamics je výchozím bodem, ze kterého můžete vycházet při vyhodnocování ukládání do mezipaměti technologie AppFabric, a obsahuje navíc hrubá data a vypozorované charakteristiky, které lze použít k vysvětlení procesu plánování kapacity.

Metodika plánování kapacity

Jakmile usoudíte, že by distribuovaná mezipaměť v paměti (například ukládání do mezipaměti technologie AppFabric) přinesla vaší aplikaci prospěch, dostanete se do fáze plánování kapacity. Ačkoli lze určité kroky plánování kapacity provést prostřednictvím přímého testování clusteru mezipamětí technologie AppFabric, můžete být požádáni o vytvoření odhadu bez tohoto typu testování. Na to se zaměřuje tento oddíl. Následující kroky vám umožní systematicky promyslet požadavky na ukládání do mezipaměti technologie AppFabric:

1. Zjištění kritických míst a identifikace dat ukládaných do mezipaměti

2. Vyhodnocení aktuálních průběhů zatížení

3. Znalost fyzické infrastruktury a hardwarových prostředků

4. Finalizace smlouvy SLA o požadovaném výkonu všech aplikací

5. Identifikace příslušných funkcí a konfigurace technologie AppFabric

Tento dokument obsahuje příklady těchto kroků získané zkoumáním potřeb ukázkové aplikace online obchodu. Ukládání do mezipaměti však může používat libovolný typ aplikace rozhraní .NET, přičemž stejný cluster mezipamětí může využívat více než jedna aplikace. V takovém případě byste měli provést níže uvedený postup pro každou aplikaci a agregací výsledků získat přesný odhad kapacity.

Krok 1: Zjištění kritických míst a identifikace dat ukládaných do mezipaměti

Nejprve identifikujte data, která chcete ukládat do mezipaměti. K tomuto účelu slouží nástroje pro analýzu výkonu, například SQL Server Profiler, Sledování výkonu, testování v prostředí Visual Studio a mnoho dalších. Tyto nástroje umožňují identifikovat často používané databázové objekty nebo pomalá volání webových služeb. Mezi potenciální data ukládaná do mezipaměti patří datové sady vracené z těchto úložišť back-end. Dočasné uložení těchto dat do mezipaměti umožňuje zvýšit výkon a snížit zatížení datových úložišť back-end.

Jakmile identifikujete potenciální data ukládaná do mezipaměti, je užitečné roztřídit tyto objekty do jedné ze tří hlavních kategorií: data aktivity, referenční data a data prostředku. Tyto kategorie lze nejlépe vysvětlit na příkladech.

• Data aktivity obsahují čtená a zapisovaná data týkající se individuálního uživatele. Například u online obchodu patří mezi data aktivity nákupní košík uživatele. Vztahuje se na aktuální relaci uživatele může se často měnit. Ačkoli je důležité zachovat u nákupního košíku vysokou dostupnost, tato data nezbytně nevyžadují trvalé uložení v databázi back-end. Vzhledem ke své dočasné povaze jsou data aktivity logickým kandidátem pro uložení do mezipaměti.

• Referenční data jsou data určená jen pro čtení, která jsou sdílena několika uživateli nebo několika instancemi aplikace. Tato data se vyznačují častým přístupem, ale málo častými změnami. V příkladu online obchodu představuje referenční data katalog produktů. Tento katalog může být platný po několik dnů, různí uživatelé však k němu mohou učinit tisíce přístupů. Také tento typ dat je vhodným kandidátem pro uložení do mezipaměti. Bez určitého typu ukládání do mezipaměti vyžaduje každý uživatel, který prohlíží katalog produktů, přístup k datům z databáze. Ukládání do mezipaměti může zmírnit zatížení databáze back-end způsobené opakovanými žádostmi o polostatická data. Vzhledem ke své trvalé povaze jsou také tato data logickým kandidátem pro uložení do mezipaměti.

• Data prostředku jsou čtená a zapisovaná data sdílená mezi uživateli. Tento typ dat obsahuje například fórum podpory. Všichni uživatelé mohou číst příspěvky ve fóru a odpovídat na ně.

Protože různé typy dat ukládaných do mezipaměti budou mít odlišné charakteristiky použití, je užitečné data rozřadit do těchto kategorií. Pokud je například nějaký objekt identifikován jako referenční data, automaticky to naznačuje, že půjde spíše o zatížení určené jen pro čtení. To také pomůže určit zásady vypršení platnosti, která je kratší u častěji se měnících dat. Pro účely vývoje může toto logické rozdělení naznačit oblasti, které je možné zapouzdřit do kódu.

Je doporučeno vytvořit odhady pro jednotlivé objekty a poté tyto údaje agregovat. Následující tabulka znázorňuje příklad informací shromážděných v této fázi:

Objekt určený k uložení do mezipaměti	Kategorie ukládání do mezipaměti	Místo trvalého uložení
Objekt nákupního košíku	Data aktivity	Žádné
Objekt uživatelských předvoleb	Data aktivity	Databáze back-end
Katalog produktů	Referenční data	Databáze back-end
Vlákno uživatelského fóra	Data prostředku	Databáze back-end

Při identifikaci dat ukládaných do mezipaměti není nutné, abyste hledali data, která mají být uložena do mezipaměti pro každou kategorii. Můžete zjistit, že výkon a škálovatelnost lze vylepšit pouze tím, že se do mezipaměti bude ukládat nákupní košík vaší aplikace. V tomto kroku je důležité pomocí dostupných informací identifikovat nejvhodnější položky k uložení do mezipaměti.

Krok 2: Vyhodnocení aktuálních průběhů zatížení

Jakmile určíte data vhodná k uložení do mezipaměti, je třeba pochopit, jak aplikace k těmto datům aktuálně přistupuje, a zjistit průběhy zatížení. Na konci tohoto kroku byste měli být schopni dospět k hrubému odhadu paměťových nároků pro ukládání do mezipaměti. Měli byste rovněž lépe rozumět tomu, jakým způsobem jsou data zpřístupněna a používána, což bude důležité v dalších krocích.

Pokud například označíte produkt katalogů jako kandidáta pro uložení do mezipaměti, měli byste prozkoumat, kdy aplikace načítá data katalogu a jak jsou tyto žádosti časté. Z předchozího kroku víte, že se jedná o referenční data, proto jde primárně o zatížení určené jen pro čtení. Důkladná znalost průběhů zatížení různých objektů ovlivní budoucí rozhodování související s kapacitou. Podívejme se nyní blíže na postupy zahrnuté do tohoto kroku.

Aktuální průběhy přístupu k datům lze lépe poznat několika způsoby:

1. Pečlivým prozkoumáním kódu zjistěte, kdy je prováděn přístup k datům a jak častý je tento přístup.

2. Použijte profiler kódu, který dokáže poskytnout údaje o frekvenci volání metod a souvisejícím výkonu.

3. Vytvořte v kódu instrumentaci u specifických sekcí přístupu k datům. Protokolujte pokusy o přístup k datům a související výkon této datové operace.

4. Pomocí databázového profileru, jako je například SQL Server Profiler, zjistěte počet a dobu trvání databázových operací.

Je možné, že jste mnohé z těchto technik použili v předchozím kroku k určení dat, která mají být ukládána do mezipaměti. V této fázi však máte zájem o získání podrobnějších údajů, které lze použít v budoucích výpočtech plánování kapacity.

Součástí tohoto vyhodnocení je zjištění poměru čtení k zápisům. Zatížení způsobené čtením a zápisy může ovlivnit pozdější rozhodnutí týkající se kapacity. Například zatížení s vysokým procentem zápisů častěji aktivuje uvolnění paměti rozhraní .NET. To bude probráno v dalším kroku.

Dalším faktorem je frekvence čtení a zápisů během špičky zatížení. Následující tabulka obsahuje ukázková data shromážděná v této fázi pro objekt nákupního košíku v tomto příkladu.

Analyzovaný objekt	Nákupní košík
Procento čtení	50%
Procento zápisů	50%
Počet operací čtení za sekundu (max.)	250
Počet operací zápisu za sekundu (max.)	250

Tato analýza by měla být provedena pro každý typ objektu. Různé typy objektů budou mít během zatížení odlišné průběhy přístupů a odlišné maximální počty čtení a zápisů za sekundu.

Pro pochopení požadavků na ukládání do mezipaměti potřebujete odhadnout, jaký je maximální počet aktivních objektů jednotlivých typů v mezipaměti v každém okamžiku. V tomto odhadu je zohledněna rovnováha mezi frekvencí vkládání objektů a očekávanou životností těchto objektů. To lze nejlépe pochopit na příkladu.

U příkladu webové aplikace rozhraní ASP.NET mohou provozní data vykazovat 25 000 souběžných uživatelů v době špičky. Každý uživatel vyžaduje informace o stavu relace, což je 25 000 objektů uložených v mezipaměti. Doba vypršení platnosti těchto objektů však může být nastavena na 30 minut. Provozní data mohou ukazovat, že v době špičky se připojuje 5 000 nových uživatelů za hodinu, což znamená, že během třicetiminutového období vypršení platnosti se může připojit 2 500 nových uživatelů. Někteří uživatelé mohou navíc ukončit prohlížeč a spustit novou relaci. Ačkoli se jedná o stejného uživatele, používá nyní jinou relaci. To by mělo být zohledněno dodatečným dimenzováním. Mělo by se rovněž počítat s předpokládaným růstem za dalších 6 až 12 měsíců. Výpočet maximálního počtu aktivních objektů v mezipaměti by měl nakonec vypadat takto:

Analyzovaný objekt:	Nákupní košík
Počet souběžných uživatelů ve špičce	25000
Počet nových uživatelů během období vypršení platnosti (30 minut)	2500
Počet existujících uživatelů, kteří spustí novou relaci prohlížeče	250
Odhad budoucího růstu (25 %)	6940
Celkový počet aktivních objektů (max.):	~35 000 aktivních objektů

Při změně vstupních údajů (například období vypršení platnosti) se změní počet objektů s nevypršenou platností, které zůstávají v mezipaměti během špičky zatížení. To je jen příklad myšlenkového postupu. Jiné typy objektů mohou mít odlišné průběhy a proměnné, které se promítnou do výpočtu. Pokud je například sdílený katalog produktů platný po celý den, je maximální počet objektů katalogu produktů v mezipaměti během tohoto dne 1.

Znalost maximálního počtu objektů v mezipaměti pomůže pouze v případě, že zároveň znáte průměrnou velikost objektu. To je ovšem obtížný problém. U příkladu nákupního košíku může jeden uživatel vložit do košíku jedinou položku, zatímco jiný uživatel může mít v košíku deset nebo dvacet položek. Cílem je zjistit průměr. Jako většina čísel v tomto procesu nebude ani toto dokonalé, konečným výsledkem je ale dobře promyšlený výchozí bod pro cluster mezipamětí, nikoli pouhý odhad.

Objekty jsou do mezipaměti ukládány v serializované formě. Při zjišťování průměrné velikosti objektu je proto nutné vypočítat průměrnou velikost serializovaného objektu. Před uložením do mezipaměti serializuje technologie AppFabric položky pomocí třídy NetDataContractSerializer. Chcete-li určit průměrnou velikost objektu, přidejte do aplikace instrumentaci, která objekty serializuje a zaznamenává jejich serializovanou velikost.

Následující příklad kódu se snaží odhadnout průměrnou velikost jednoho objektu. Serializovaný objekt má název obj. K zaznamenání délky slouží proměnná length. Pokud při získávání velikosti pomocí třídy NetDataContractSerializer dojde k potížím, použije se místo toho třída BinaryFormatter. Pro snazší použití lze tento kód začlenit do metody. V takovém případě bude objekt obj předán jako parametr a metoda vrátí délku length.

// 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;
}

Poznámka

Pokud jste používali testovací instalaci clusteru mezipamětí, můžete do mezipaměti přidat položky a pak pomocí příkazu Get-CacheStatistics prostředí Windows PowerShell zjistit velikost jednoho nebo více objektů přidaných do mezipaměti. Alternativně můžete velikost několika objektů v mezipaměti vydělit počtem těchto objektů. Můžete zvolit, zda tyto odhady shromáždíte pomocí kódu nebo pomocí testování.

Pokud hodláte použít ukládání do mezipaměti technologie AppFabric pro stav relace, je důležité vědět, že zprostředkovatel systému SQL Server pro stav relace rozhraní ASP.NET vždy používá třídu BinaryFormatter a nikoli třídu NetDataContractSerializer. Objekty serializované pomocí třídy NetDataContractSerializer mohou být občas několikanásobně větší než při serializaci pomocí třídy BinaryFormatter. To je důležité při zjišťování velikosti objektů stavu relace v systému SQL Server, protože nemůžete použít tuto velikost a předpokládat, že stejná velikost bude v mezipaměti. Pro získání hrubého odhadu byste tuto velikost měli vynásobit šesti. Chcete-li získat lepší odhad, použijte u objektů uložených ve stavu relace výše uvedený kód. S doposud shromážděnými údaji můžete začít formulovat celkové paměťové nároky. Tento krok se skládá z následujících dílčích úkolů:

1. Zaměřte se na určitý typ objektu (například na objekt nákupního košíku).

2. Pro tento objekt nejprve zjistěte průměrnou velikost serializovaného objektu.

3. Přičtěte k této průměrné velikosti 500 bajtů, čímž zohledníte režii ukládání do mezipaměti.

4. Vynásobte tuto velikost maximálním počtem aktivních objektů. Tím získáte celkové paměťové nároky mezipaměti pro tento typ objektu.

5. Přidejte odhadovanou režii pro interní struktury mezipaměti (5 %).

6. Opakujte tento postup pro všechny identifikované typy objektů.

7. Agregováním těchto výsledků zjistěte celkové paměťové nároky mezipaměti.

Při tomto postupu byste k odhadům velikosti měli přidat přibližně 0,5 kB režie na každý objekt. Také jiné interní datové struktury vyžadují paměť v mezipaměti. Oblasti, značky a oznámení vyžadují další paměť. V ukázkových výpočtech byly tyto interní struktury zohledněny přidáním 5 % z celkového množství, může to však být více nebo méně v závislosti na tom, nakolik chcete tyto funkce ukládání do mezipaměti využívat.

V tomto okamžiku byste měli zvážit vliv jedné ze specifických funkcí ukládání do mezipaměti technologie AppFabric, a sice vysokou dostupnost. Tato funkce vytváří kopie položek uložených v mezipaměti na sekundárních serverech. To znamená, že pokud jeden server mezipaměti selže, převezme jeho činnost sekundární server mezipaměti a nedojde ke ztrátě dat. Pokud se rozhodnete použít vysokou dostupnost, musíte odhady paměti zdvojnásobit. Je také nutné použít systém Windows Server 2008 Enterprise nebo vyšší. Funkce vysoké dostupnosti je zajišťována na úrovni pojmenované mezipaměti. To znamená, že pokud byste chtěli vytvořit dvě pojmenované mezipaměti ve stejném clusteru, nemuseli byste nezbytně použít vysokou dostupnost pro každou mezipaměť. Aplikace by mohla některé položky ukládat do pojmenované mezipaměti s vysokou dostupností a některé do mezipaměti bez této funkce. To vám umožní využít většinu paměťových prostředků. Je proto důležité znát rozhodnutí ohledně vysoké dostupnosti, protože zdvojnásobuje paměťové nároky pro mezipaměti, které tuto funkci využívají.

Pro příklad je zde uvedena tabulka s vyhodnocením požadavků na data aktivity a referenční data ve stejné aplikaci. V závislosti na vaší situaci se můžete rozhodnout, zda tento odhad učiníte na úrovni objektu nebo na úrovni aplikace. Stačí, když k tomuto příkladu přidáte další sloupce a vhodně je pojmenujete.

Analyzovaný objekt:	Data aktivity	Referenční data
Průměrná velikost serializovaného objektu:	250 kB	60 kB
Režie clusteru mezipamětí na objekt:	0,5 kB	0,5 kB
Upravená průměrná velikost serializovaného objektu:	250,5 kB	60,5 kB
Maximální počet aktivních objektů:	~35000	~68000
Paměťové nároky na ukládání do mezipaměti:	8,4 GB	3,9 GB
Je povolena vysoká dostupnost?	16,8 GB	Ne
Režie pro interní datové struktury (5 %):	0,8 GB	0,2 GB
Celkové paměťové nároky:	17,6 GB	4,1 GB

Agregace těchto odhadů tvoří počáteční paměťové nároky pro cluster mezipamětí. V tomto příkladu činí celková velikost 21,7 GB. S tímto odhadem se nyní můžete pustit do dalších úvah, jako je fyzická infrastruktura, požadavky na smlouvu SLA a konfigurace mezipaměti technologie AppFabric.

Krok 3: Znalost fyzické infrastruktury a hardwarových prostředků

Znalost fyzické infrastruktury a dostupnosti prostředků je důležitá. Zde jsou některé běžné otázky:

1. Budete schopni zřídit fyzické nebo virtuální počítače?

2. Pokud máte stávající hardware, jaká je jeho konfigurace (například 8 GB paměti RAM, čtyřjádrový procesor)?

3. Bude cluster mezipamětí umístěn ve stejném datovém centru jako aplikační servery?

4. Jaké jsou schopnosti sítě?

Pokud servery mezipaměti zvažujete realizovat pomocí virtuálních počítačů, vezměte do úvahy následující aspekty. Musíte například zvážit, jaký dopad bude mít několik virtuálních počítačů v jednom fyzickém počítači. Několik virtuálních počítačů může sdílet stejnou síťovou kartu, což zvyšuje riziko vzniku kritických míst sítě. Rovněž vysokou dostupnost lze zřídit mezi primárním a sekundárním hostitelem mezipaměti, které jsou tvořeny virtuálními počítači v jednom fyzickém počítači. Pokud však tento fyzický počítač selže, nezůstane žádná kopie dat. Další informace naleznete v tématu Pravidla pro používání mezipaměti technologie AppFabric ve virtuálním počítači.

Pro stávající počítače se neudávají žádné doporučené specifikace. U velkých clusterů mezipamětí se však používají počítače s 16 GB paměti RAM a čtyřjádrovým procesorem. Obecně patří mezi nejdůležitější aspekty plánování množství fyzické paměti a síťového zatížení.

Jak u fyzických, tak u virtuálních počítačů je nutné uvažovat o umístění clusteru mezipamětí vzhledem k aplikačním nebo webovým serverům, které tuto mezipaměť používají. Pokud se nacházejí v samostatných datových centrech, zajistěte, aby latence mezi těmito datovými centry neměla nepříznivý vliv na výkon. V této fázi může být lákavé využít pro servery mezipaměti aplikační nebo webové servery. Ačkoli je to možné, není tato konfigurace podporována. Za prvé, jakékoli špičky ve využití prostředků těchto počítačů (způsobené například službou IIS) by ovlivnily cluster mezipamětí. Za druhé, služba ukládání do mezipaměti předpokládá, že běží na vyhrazeném serveru, a může potenciálně využívat mnohem více paměti, než určíte.

U schopností sítě byste měli vyhodnotit očekávané zatížení sítě a porovnat je se svou infrastrukturou. Nejprve musíte vědět, jaké očekávané množství dat má každý server mezipaměti obsluhovat, a zda jsou schopnosti síťové karty dostatečné. Pokud ne, bude zapotřebí více serverů mezipaměti. Uvažujte například situaci, kdy průměrná velikost objektu v mezipaměti činí 500,5 kB a v clusteru mezipamětí probíhá 240 operací za sekundu. Při použití jednoho hostitele mezipaměti byste došli k následujícím výsledkům:

Počet čtení a zápisů objektů za sekundu:	240
Počet počítačů v clusteru mezipamětí:	1
Počet operací s mezipamětí za sekundu na každý počítač:	240
Průměrná velikost objektu:	500,5 kB
Množství dat přenesených za sekundu:	240 × 500,5 = 117,3 MB/s

Pokud je každý počítač vybaven síťovou kartou o rychlosti 1GB/s, je maximální propustnost přibližně 119 MB/s. Vypočtená hodnota 117.3 MB/s by pravděpodobně tento jeden server zahltila. Kvůli tomu by se s velkou pravděpodobností stala kritickým místem síť. Pokud by však v clusteru mezipamětí byly použity tři počítače, díky rovnoměrnému rozdělení žádostí o mezipaměť by na každý server připadla 1/3 tohoto zatížení.

Zvažte také síťové využití aplikačních serverů, které získávají přístup ke clusteru mezipamětí. Pokud si vyměňují velký objem dat s jinými systémy, měli byste uvažovat o vytvoření vyhrazené sítě mezi aplikačními servery a clusterem mezipamětí. Pro tento účel je nutné vybavit každý aplikační server další síťovou kartou.

Posledním aspektem sítě je skutečnost, zda je síť schopna zvládnout požadované zatížení po celé trase. Síťová karta o rychlosti 1 Gb/s na každém serveru mezipaměti nestačí. Také přepínač a další body v síti musí být schopny toto zatížení zvládnout. Při plnění tohoto požadavku bude nutná spolupráce s provozním oddělením.

Krok 4: Finalizace smlouvy SLA o požadovaném výkonu všech aplikací

Před volbou konečné konfigurace potřebujete také znát všechny podnikové požadavky včetně smlouvy o úrovni výkonu a spolehlivosti. V praxi má tento krok vliv na rozhodnutí o počtu clusterů mezipamětí a počtu hostitelů mezipaměti v každém clusteru.

Pokud máte například nepostradatelnou aplikaci využívající cluster mezipamětí, mohli byste chtít izolovat tento cluster mezipamětí od jiných aplikací s nižší prioritou. Tyto aplikace s nižší prioritou by mohly potenciálně využívat více paměťových, síťových a procesorových prostředků, což by mělo negativní dopad na tuto nepostradatelnou aplikaci.

Zde jsou specifické faktory, jež mají vliv na toto rozhodnutí:

• Zabezpečení se udržuje na úrovni clusteru mezipamětí. Pokud má nějaký uživatel přístup ke clusteru mezipamětí, má potenciálně přístup ke všem datům v tomto clusteru mezipamětí (za předpokladu, že tento uživatel zná název mezipaměti a klíč požadavku). Pokud pro různé typy dat požadujete odlišné nastavení zabezpečení, může oddělení clusterů mezipamětí dávat smysl. Další informace naleznete v tématu Správa zabezpečení.

• K vyřazování položek s nevypršenou platnosti dochází, jakmile paměť dosáhne horní meze. Podhodnocené množství paměti potřebné pro jednu mezipaměť může ovlivnit všechny mezipaměti v clusteru. Jestliže kvůli nedostatku paměti dojde k vyřazování, proběhne ve všech mezipamětech, přestože nedostatek paměti vznikl pouze v jedné mezipaměti. To lze poněkud zmírnit vytvořením mezipamětí bez vyřazování, přitom je ale třeba postupovat opatrně. Další informace naleznete v tématu Vypršení platnosti a vyřazování.

• Spravovatelnost je do určité míry jednodušší u samostatných clusterů mezipamětí. Zřejmě nechcete spravovat samostatné clustery pro 100 různých mezipamětí. Pro dvě odlišné velké mezipaměti však může být vhodné clustery mezipamětí oddělit, protože je můžete spravovat, škálovat a monitorovat samostatně.

Nakonec je u některých požadavků nutné zohlednit latenci a propustnost. Pokyny a výsledky testů týkající se těchto aspektů naleznete v dokumentu white paper společnosti Grid Dynamics. Požadavky na propustnost clusteru mezipamětí můžete například porovnat s výsledky testů publikovanými v tomto dokumentu. Z této studie můžete zjistit, že pro dosažení cílů propustnosti máte příliš málo serverů. Je důležité vědět, že tato studie se nemusí dokonale shodovat s vašimi typy objektů, velikostmi objektů a fyzickou a logickou infrastrukturou; stále však poskytuje průkazné výsledky testů, které vám pomohou učinit kvalifikované rozhodnutí.

Krok 5: Identifikace příslušných funkcí a konfigurace technologie AppFabric

Tato část celého procesu se zabývá konkrétní konfigurací ukládání do mezipaměti technologie AppFabric a architekturou clusteru mezipamětí technologie AppFabric. Přestože máte shromážděna všechna správná empirická a obchodní data, při ignorování tohoto nastavení mezipaměti technologie AppFabric nemusí být vaše plány naplněny.

Následující tabulka obsahuje různé funkce ukládání do mezipaměti technologie AppFabric a související pokyny pro plánování kapacity.

Oblasti	Je možné vytvořit několik oblastí, každá oblast však existuje v jednom hostiteli mezipaměti. Pro využití výhod distribuované mezipaměti musí aplikace využívat několik oblastí. Všechna volání, ve kterých nejsou určeny oblasti, automaticky interně využívají výchozí oblasti. Každý hostitel mezipaměti v clusteru mezipamětí musí být schopen hostovat maximální velikost největší oblasti.
Oznámení	U mezipamětí lze povolit oznámení, která jsou přijímána klienty mezipaměti. Tato funkce zvýší síťové přenosy a využití procesoru na straně serveru. Účinek závisí na intervalu oznamování a počtu odeslaných oznámení. Velký počet oznámení ve velmi krátkých intervalech může mít vliv na výkon a škálovatelnost. Pro odhad tohoto vlivu neexistují žádná pevná pravidla, takže je nutné jej vypozorovat během testování.
Místní mezipaměť	Místní mezipaměť zvyšuje výkon ukládáním objektů do mezipaměti v klientech a zároveň na serveru. Při použití místní mezipaměti zvažte vliv na paměť v klientských počítačích. Tato funkce nemá žádný vztah k plánování kapacity paměti na straně serveru, protože všechny položky uložené v místní mezipaměti existují také na serveru. Pokud jsou však pro rušení platnosti místní mezipaměti použita oznámení, může být strana serveru ovlivněna zpracováním těchto oznámení.
Návrh a konfigurace aplikace na straně klienta	Návrh aplikace na straně klienta může ovlivnit celkový výkon. Všechny vytvořené objekty DataCacheFactory byste například měli uložit pro opakované použití a nevytvářet je znovu pro každé volání. Může být také výhodné vytvořit jeden objekt DataCacheFactory na každé vlákno. Jestliže je ale jeden objekt DataCacheFactory sdílen několika vlákny, uvažujte o zvýšení nastavení MaxConnectionsToServer. Tím se zvýší počet připojení k serverům mezipaměti na každý objekt DataCacheFactory.
Vysoká dostupnost	Jak už bylo řečeno, mezipaměti s vysokou dostupností vyžadují dvojnásobek vypočtených paměťových nároků. Tato funkce však také vyžaduje nejméně tři servery. Pokud jeden server selže, musí existovat dva zbývající servery pro podporu primárních a sekundárních kopií každé položky po selhání. Tato funkce navíc vyžaduje, aby byl na všech serverech systém Windows Server 2008 Enterprise nebo vyšší.
Pojmenované mezipaměti	Počet pojmenovaných mezipamětí je v současnosti omezen na 128. Pokud máte aplikace vyžadující více než tento počet pojmenovaných mezipamětí, je třeba tuto skutečnost zohlednit při plánování kapacity. V takovém případě potřebujete více než jeden cluster mezipamětí, nebo aplikace musejí být navrženy tak, aby využívaly menší počet mezipamětí. Další strategie spočívá v programovém vytvoření oblastí uvnitř pojmenovaných mezipamětí.
Úložiště konfigurace XML	Pokud pro úložiště konfigurace clusteru mezipamětí používáte sdílené umístění v síti, měl by tento cluster obsahovat alespoň tři servery, které jsou všechny označeny jako hlavní hostitelé. Další informace o důvodech tohoto požadavku naleznete v tématu Aktualizace serverů mezipaměti.

Nemělo by být překvapením, že jedním z nejdůležitějších nastavení, kterému je třeba porozumět, je nastavení paměti u jednotlivých hostitelů mezipaměti. Výchozí nastavení paměti u každého hostitele mezipaměti lze zobrazit pomocí příkazu Get-CacheHostConfig prostředí Windows PowerShell.

Poznámka

Informace o použití příkazů prostředí Windows PowerShell pro práci s mezipamětí naleznete v tématu Obvyklé úlohy správy clusteru mezipamětí.

Následující snímek obrazovky znázorňuje výstup příkazu Get-CacheHostConfig u počítače s 4 GB paměti RAM.

Ve výchozím nastavení je pro mezipaměť na daném serveru vyhrazeno 50 % celkové paměti RAM. V tomto příkladu činí polovina paměti RAM 2 GB. Zbývající paměť je poté k dispozici pro operační systém a služby. Toto výchozí nastavení je doporučeno ponechat i u počítačů s mnohem větší pamětí. Jak už bylo zmíněno, služba ukládání do mezipaměti předpokládá, že běží ve vyhrazeném počítači, a může využívat mnohem více paměti, než je přiděleno pro mezipaměť. Ačkoli se na části těchto paměťových nároků podílí interní návrh služby ukládání do mezipaměti, částečně také souvisí se správou a uvolňováním paměti rozhraní .NET. I když je paměť uvolněna v aplikaci rozhraní .NET, musí počkat na uvolňování paměti, aby byla vyjmuta z paměti procesu. Tento proces vyžaduje fyzickou vyrovnávací paměť, která zohledňuje nedeterministickou povahu uvolňování paměti.

Jakmile poznáte vliv uvolňování paměti, zjistíte, že zatížení s vysokým procentem a frekvencí zápisů bude vyžadovat větší vyrovnávací paměť, aby se počítalo s cykly uvolňování paměti. Pro zatížení, u kterých probíhá převážně pouze čtení, to neplatí. V některých případech byste proto mohli uvažovat o navýšení paměti vyhrazené pro ukládání do mezipaměti. Například u počítače s 16 GB paměti byste mohli rezervovat 12 GB pro nastavení velikosti mezipaměti (namísto výchozí hodnoty 8 GB), což poskytuje 4 GB režie pro operační systém a služby. Předpokládá se, že tento počítač je vyhrazen pro službu ukládání do mezipaměti, což je v současnosti jediná podporovaná konfigurace. V tomto příkladu byste tuto konfiguraci paměti měli testovat s předpokládaným zatížením. Pokud je přidělování paměti příliš agresivní, při testování se tato chyba projeví problémy souvisejícími s pamětí, jako je například vyřazování nebo omezování. Další informace naleznete v tématu Řešení potíží se serverem (ukládání do mezipaměti technologie Windows Server AppFabric). V následujícím příkladu je pomocí příkazu Set-CacheHostConfig nastavena velikost mezipaměti na 12 GB u serveru s názvem Server1:

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

Další důležitou položkou ve výstupu příkazu Get-CacheHostConfig jsou hodnoty mezí. Hodnota dolní meze (LowWatermark) činí ve výchozím nastavení 70 % velikosti mezipaměti. Jakmile paměť mezipaměti dosáhne dolní meze, služba ukládání do mezipaměti začne vyřazovat objekty, jejichž platnost již vypršela. To je v pořádku, protože tyto objekty stejně nejsou přístupné.

Hodnota horní meze (HighWatermark) činí ve výchozím nastavení 90 % velikosti mezipaměti. Při dosažení úrovně horní meze jsou objekty vyřazovány bez ohledu na to, zda jejich platnost vypršela, dokud se paměť nevrátí na úroveň dolní meze. To má samozřejmě potenciálně nepříznivý dopad na výkon a také na práci uživatelů.

Využití mezipaměti doporučujeme naplánovat na úroveň dolní meze, aby nedošlo k možnému dosažení horní meze. Podrobnější popis naleznete v tématu Vypršení platnosti a vyřazování.

Tip

Úplné cykly uvolňování paměti mohou způsobit krátkou prodlevu, během které často dochází k chybám opakování. Z tohoto důvodu doporučujeme, aby měl každý hostitel mezipaměti 16 GB nebo méně paměti. U počítačů s více než 16 GB paměti RAM mohou při úplných cyklech uvolňování paměti vznikat delší prodlevy. Zvětšování paměti u hostitelů mezipaměti však přesto není nijak omezeno. U zatížení s převahou čtení nemusí docházet k úplným cyklům uvolňování paměti tak často. To lze nejlépe určit pomocí testování.

V předchozím příkladu byly vypočteny celkové paměťové nároky na ukládání do mezipaměti ve výši 21,7 GB. Protože je vyžadována vysoká dostupnost, musejí existovat alespoň tři servery. Předpokládejme, že každý server má 16 GB paměti RAM. V tomto příkladu bude na každém serveru zachováno výchozí nastavení velikosti mezipaměti 8 GB. Jak bylo zmíněno dříve, cílovou pamětí dostupnou na všech serverech by měla být dolní mez (70 %). To znamená, že odhad paměti pro každý server mezipaměti činí 5,6 GB. Při započtení těchto faktorů je v následující tabulce znázorněno, že čtyři servery by poskytly 22,4 GB paměti pro mezipaměť a splnily tak nároky 21,7 GB.

Celkové paměťové nároky	21,7 GB
Počáteční paměť (hostitel mezipaměti)	16 GB
Nastavení velikosti mezipaměti (hostitel mezipaměti)	8 GB
Dolní mez (hostitel mezipaměti)	70%
Upravená cílová velikost paměti na každého hostitele mezipaměti	5,6 GB
Celková paměť clusteru mezipamětí (3 počítače)	5,6 GB × 4 servery = 22,4 GB

Nezapomeňte, že pomocí výsledků publikovaných v dokumentu white paper společnosti Grid Dynamics můžete tento odhad ověřit vzhledem k cílovým hodnotám propustnosti a latence. Výsledky těchto testů by vás mohly přimět k mírné změně tohoto prvotního návrhu, například doplněním dalšího serveru mezipaměti. V tomto okamžiku je důležité použít podobné dostupné materiály a učinit kvalifikované rozhodnutí.

Nástroj pro plánování kapacity

Logickým nástrojem pro plánování kapacity popsané v předchozích částech je tabulka. Sestavili jsme ukázkovou tabulku, kterou si můžete stáhnout zde. Údaje označené hvězdičkou jsou položky, které byste měli změnit na základě plánování a prostředků. Zbývající výpočty zajišťuje tato tabulka.

V prvním oddíle tabulky je uvedena konfigurace serveru pro každého hostitele mezipaměti. Tento oddíl můžete v průběhu plánování měnit a pozorovat rozdíly v konečných výpočtech. Tento první oddíl je znázorněn na následující kopii obrazovky.

Důležité

Pokud nepoužíváte výchozí instalační hodnoty, zodpovídáte za nastavení hodnot CacheSize a LowWatermark pomocí příkazu Set-CacheHostConfig na každém hostiteli mezipaměti.

Druhý oddíl umožňuje vyplnit odhady pro různé typy objektů. V této ukázkové tabulce se pro Data aktivity a Referenční data používají pouze dva oddíly. Poté následuje řada prázdných sloupců. Tyto sloupce můžete přejmenovat v závislosti na úrovni členitosti, kterou používáte při plánování (objekt, kategorie, aplikace apod.). Tento druhý oddíl je znázorněn na následující kopii obrazovky.

Ve třetím oddíle jsou uvedeny odhady požadavků na síť. Vyplníte průměrnou velikost objektů čtení a zápisu a maximální počet operací čtení a zápisu za sekundu. Tento oddíl vypočte požadavky na maximální šířku pásma pro daný typ objektu. Získáte tak hrubou představu, zda předpokládané seskupení počítačů a síťových karet toto zatížení zvládne. Jak bylo zmíněno v předchozích částech, je zapotřebí zkontrolovat šířku pásma podél celé síťové trasy. Tento třetí oddíl je znázorněn na následující kopii obrazovky.

V posledním oddíle jsou agregovány požadavky oddílů určených pro paměť a síť. Na základě konfigurace počítače zadané v prvním oddíle jsou pak provedeny výpočty počtu serverů. Pole Additional Servers (Další servery) umožňuje v případě potřeby tento vypočtený celkový počet navýšit. Pokud výsledek výpočtů určí například dva servery, můžete ke konečnému celkovému počtu přidat jeden dodatečný server pro podporu vysoké dostupnosti. Tento poslední oddíl je znázorněn na následující kopii obrazovky.

Poznámka

Na předchozích kopiích obrazovky jsou použita čísla podobná příkladu v tomto dokumentu, namísto čtyř serverů jsou však odhadnuty tři servery. V tabulce je totiž nastavením hodnoty Cache Size Setting(Set-CacheHostConfig) na 12 GB demonstrováno vlastní nastavení. Při změně této hodnoty na 8 GB se výsledky budou podobat hodnotám získaným v předchozích částech tohoto dokumentu.

Další kroky při plánování kapacity

V předchozí části byla představena metodika pro určení prvotního odhadu počtu clusterů mezipamětí, počtu hostitelů mezipaměti v každém clusteru a konfigurace těchto hostitelů mezipaměti. Měli byste si však uvědomit, že jde o odhad, který se může změnit v závislosti na testování a průběžném monitorování.

Pokud se rozhodnete s plány ukládání do mezipaměti technologie AppFabric postoupit do další fáze, můžete pomocí testování konceptu zjistit, jak by ukládání do mezipaměti fungovalo ve vaší situaci. Poté byste mohli nainstalovat testovací cluster mezipamětí a provést testy ve svém prostředí. V závislosti na výsledcích těchto testů byste dalšími změnami konfigurace dosáhli požadavků na kapacitu, výkon a škálovatelnost. Následující část vysvětluje konkrétní průběžné metriky, na které se během testování a provozu můžete zaměřit.

Monitorování průběžných požadavků na kapacitu ukládání do mezipaměti

Plánování kapacity ukládání do mezipaměti rozhodně nepatří mezi exaktní vědy. Mnohá z čísel, která přispívají k závěrům, jsou vlastně odhady. Také využívání aplikace a průběhy se časem mění. Z tohoto důvodu byste měli monitorováním ukazatelů výkonu zajistit, aby cluster mezipamětí splňoval kapacitní požadavky. Úspěšné plánování kapacity je průběžný proces, který pokračuje jak v testovacím, tak v provozním prostředí.

K průběžnému monitorování kapacity se nejlépe hodí nástroj Sledování výkonu. U hostitele mezipaměti je doporučeno monitorovat následující čítače výkonu:

Kategorie sledování	Čítače sledování výkonu
Paměť	Ukládání do mezipaměti technologie AppFabric:Hostitel\Celková velikost dat (bajty) Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet vyřazených objektů Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet spuštění vyřazení Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkové množství vyřazené paměti Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet objektů Paměť .NET CLR(DistributedCacheService)\Počet úklidů 0. generace Paměť .NET CLR(DistributedCacheService)\Počet úklidů 1. generace Paměť .NET CLR(DistributedCacheService)\Počet úklidů 2. generace Paměť .NET CLR(DistributedCacheService)\Počet nepřesunutelných objektů Paměť .NET CLR(DistributedCacheService)\Čas potřebný k úklidu paměti (%) Paměť .NET CLR(DistributedCacheService)\Velikost haldy pro velké objekty Paměť .NET CLR(DistributedCacheService)\Velikost haldy 0. generace Paměť .NET CLR(DistributedCacheService)\Velikost haldy 1. generace Paměť .NET CLR(DistributedCacheService)\Velikost haldy 2. generace Paměť\Počet MB k dispozici
Síť	Rozhraní sítě(*)\Bajty přijaté/s Rozhraní sítě(*)\Bajty odeslané/s Rozhraní sítě(*)\Aktuální šířka pásma
Procesor	Proces(DistributedCacheService)\% času procesoru Proces(DistributedCacheService)\Počet vláken Proces(DistributedCacheService)\Pracovní sada Procesor(_Total)\% času procesoru
Propustnost	Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet žádostí klientů Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet žádostí klientů/s Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet žádostí o načtení Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet žádostí o načtení/s Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet žádostí o načtení Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet žádostí o načtení/s Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet žádostí o načtení a uzamčení Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet žádostí o načtení a uzamčení/s Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet žádostí o čtení Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet žádostí o čtení/s Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet operací zápisu Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet operací zápisu/s
Různé	Ukládání do mezipaměti technologie AppFabric:Hostitel\Procento neúspěšných přístupů do mezipaměti Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet objektů, jejichž platnost vypršela Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet doručených oznámení

Mnoho zde uvedených čítačů výkonu je přímo spjato s plánováním kapacity. Příkladem může být několik čítačů výkonu paměti. Čítač výkonu „Paměť\Počet MB k dispozici“ udává, kolik fyzické paměti v megabajtech zůstává v počítači. Pokud se tento čítač výkonu dostane pod 10 % celkové fyzické paměti, dojde s velkou pravděpodobností k omezování. Další informace naleznete v tématu Řešení potíží s omezováním. Další čítače se týkají funkcí ukládání do mezipaměti. Čítač výkonu „Ukládání do mezipaměti technologie AppFabric:Hostitel\Celkový počet spuštění vyřazení“ udává, jak často je paměť vyřazována. Jakmile paměť překročí horní mez, bude tento ukazatel výkonu udávat spuštění vyřazení, než se paměť vrátí zpět na dolní mez. Podobným způsobem jsou ostatní čítače výkonu spojeny s myšlenkovými pochody při plánování kapacity popsanými v předchozích částech tohoto dokumentu.

U počítače jsou rovněž zaznamenávány čítače výkonu procesu služby DistributedCacheService a čítače výkonu procesoru. Vysoké využití procesoru může negativně ovlivnit výkon clusteru mezipamětí. Pokud zjistíte období vysokého využití procesoru, je důležité identifikovat, zda tato období souvisejí se službou ukládání do mezipaměti (DistributedCacheService.exe) nebo s jiným procesem v počítači.

Kromě nástroje Sledování výkonu můžete použít příkazy prostředí Windows PowerShell, které se instalují s technologií AppFabric. Mnoho z těchto příkazů lze použít k monitorování stavu clusteru mezipamětí. Další informace naleznete v tématech Nástroje pro sledování stavu a Protokolování a čítače výkonu v mezipaměti technologie AppFabric.

Další odkazy

Další prostředky

Instalace technologie Windows Server AppFabric
Dokumentace k ukládání do mezipaměti technologie Windows Server AppFabric na webu MSDN
Příručka programování pro ukládání do mezipaměti technologie AppFabric
Konfigurace zprostředkovatele stavu relace rozhraní ASP.NET
Možnosti úložiště konfigurace clusteru mezipamětí
Příručka pro nasazení a správu ukládání do mezipaměti technologie Windows Server AppFabric
Odkazy a materiály pro technologie Windows Server AppFabric a Windows Azure AppFabric

  2011-12-05