Windows Server AppFabric Önbelleğe Alma Kapasitesini Planlama Kılavuzu

Jason Roth, Rama Ramani, Jaime Alva Bravo

Mart 2011

Bu teknik inceleme Windows Server AppFabric önbelleğe alma kapasite planlaması için kılavuzluk sağlamaktadır.

1. Giriş

2. AppFabric Önbelleğe Alma Performansını Değerlendirme

3. Kapasite Planlama Yöntemi

   1. Birinci Adım: Performans sorunlarını anlama ve önbelleğe alma adaylarını belirleme

   2. İkinci Adım: Mevcut iş yükü düzenlerini değerlendirme

   3. Üçüncü Adım: Fiziksel altyapıyı ve donanım kaynaklarını anlama

   4. Dördüncü Adım: Tüm uygulamalar için gerekli performans SLA'sını sonlandırma

   5. Beşinci Adım: Uygun AppFabric özelliklerini ve yapılandırma ayarlarını belirleme

4. Kapasite Planlama Aracı

5. Kapasite Planlamada Sonraki Adımlar

6. Sürekli Önbelleğe Alma Kapasitesi Gereksinimlerini İzleme

Giriş

Windows Server AppFabric önbelleğe alma özelliği dağıtılmış, belleğe yüklenmiş bir önbellek kümesi sağlar. Bu inceleme, Windows Server AppFabric Önbelleğe Alma'nın dahili dağıtımına yönelik kapasite planlama kılavuzu işlevi görür.

Windows Server AppFabric Önbelleğe Alma mimarisi, bu belgede ayrıntılı bir şekilde açıklanmaktadır. Daha fazla bilgi için bkz. Windows Server AppFabric Önbelleğe Alma Özellikleri. Özetle, bir AppFabric önbellek kümesi bir veya daha fazla önbellek sunucusundan (önbellek konakları olarak da adlandırılır) oluşur. Önbellekler, önbellek konaklarına dağıtılır ve bellek içinde depolanır.

Not

Ayrıca, bulutta önbelleğe alma özelliğini kullanmak için bir Windows Azure AppFabric Önbelleğe Alma sürümünün de olduğunu göz önünde bulundurun. Bu incelemede, bellek gereksinimlerini tahmin etmeyle ilgili bazı adımlar bulut tabanlı çözümler için geçerli olacaktır. Ancak, bu inceleme özellikle dahili önbellek kümesi senaryosuna odaklanmaktadır. Azure AppFabric önbelleğe alma özelliğinin kullanımına ilişkin daha fazla bilgi için bkz. Windows Azure AppFabric Önbelleğe Alma.

Bu incelemede yer alan bilgiler, Microsoft'un müşterileriyle gerçekleştirdiği planlama çalışmasını temel alır. AppFabric önbelleğe alma özelliğini kullanan tüm müşterilerin ortak bir sorusu var: “Senaryom için kaç tane sunucu gerekli?” Bu tür görüşmelerin çoğunda, konuşmamıza şöyle tipik bir yanıtla başlıyoruz: "Duruma göre değişir". Ardından, hızlı bir şekilde çeşitli ayrıntılardan bahsettikten sonra iyi bir başlangıç noktası yakalıyoruz. Bu süreçte, daha spesifik olan diğer sorular ortaya çıkıyor:

• Uygulamalarım için hangi boyutta bir önbellek belleği gerekli?

• Bir önbellek kümesinde kaç tane makine kullanmalıyım?

• Her makinede ne kadar bellek bulunmalı ve bunlar nasıl yapılandırılmalı?

• Ağ bant genişliği önbellek kümesi performansını nasıl etkiler?

Bu teknik incelemenin hedefi, bu tür müşteri görüşmelerinden alınan dersleri, kapasite planlamanız için kullanılabilecek bir yöntem sunmak amacıyla bir araya getirmektir.

Bu incelemeyi okuyorsanız, çeşitli geliştirme aşamalarından birinde olabilirsiniz:

1. Dağıtılmış önbelleğe alma hakkında bilgi almaya yeni başlıyorsunuz ve iş yükü karışımı, performans gereksinimleri veya sunucu dağıtım topolojisi hakkında henüz ayrıntılı bilgiye sahip değilsiniz. Bu noktada, AppFabric önbelleğe alma özelliğine ilişkin bazı performans verilerine bakarak başlangıç yapmak isteyebilirsiniz.

2. Ya da, AppFabric önbelleğe alma özellikleri ve performansı hakkında önceden araştırma yaptınız. Şimdi ise kendi senaryonuzu ve yüksek düzeydeki gereksinimlerinizi yakından incelemek için yardım istiyorsunuz. Kapasite planlamasının ayrıntılarına girdiğiniz yer işte burasıdır.

3. Son olarak, zaten üretim aşamasında olabilirsiniz. Bu aşamada, yeterli kapasiteniz olduğundan emin olmak için performans verilerini nasıl analiz edeceğinizi anlamak istiyorsunuz. Aynı zamanda, AppFabric önbelleğinin çalışma zamanı davranışı temelinde ana göstergeleri ve en iyi uygulamaları bilerek gelecekteki iş yükü artışlarına karşı plan yapmak da istiyorsunuz.

Bu teknik incelemede bu aşamalara sırayla değinilmektedir. Sadece AppFabric performansını değerlendiriyorsanız, iş ortağımız Grid Dynamics tarafından hazırlanan kapsamlı teknik incelemeye bakmanızı öneriyoruz. Burada, bu teknik incelemedeki verileri, değerlendirmenizi kolaylaştırmak ve kapasite planlama işlemi hakkında bilgi vermek üzere basit bir şekilde gruplandıracağız.

Kapasite planlama işlemini incelemeye hazırsanız, senaryonuza uygulayabileceğiniz bir yöntem oluşturmaya yönelik bir grup adım sunacağız.

Önbellek kümesini kullanıyor veya test ediyorsanız, doğru kapasiteye sahip olduğunuzdan emin olmak için ana performans göstergeleri grubuna bakarak kapasite planlama işlemini doğrulayabilirsiniz. Ayrıca, en iyi uygulamalardan bazılarına da yer vereceğiz.

AppFabric Önbelleğe Alma Performansını Değerlendirme

İş ortağımız Grid Dynamics, kısa süre önce AppFabric önbelleğe alma özelliğinin performansına ilişkin bir dizi test gerçekleştirdi. Elde edilen sonuçlar aşağıdaki teknik incelemede yayınlanmıştır: Windows Server AppFabric Önbelleğe Alma: Ayrıntılı bir performans ve ölçeklenebilirlik veri sayfası.

Testlerden her biri, önbellek boyutu veya önbellek kümesindeki sunucu sayısı gibi belirli bir değişken üzerine odaklanmıştır. Grid Dynamics çalışması, AppFabric önbelleğe alma özelliğinin performans ve ölçeklenebilirliğini değerlendirmek için kullanılabilir. Çeşitli sınama senaryolarının ve topolojilerinin üretilen iş ve gecikme sayısını uygulama gereksinimlerinizle karşılaştırabilirsiniz. Tipik olarak, her bir testte performans etkilerine odaklanmak amacıyla yalnızca bir veya iki parametre değiştirilmiştir. Parametre grubunun tamamı şunlardan oluşur:

Yük düzeni	Önbellek kullanma düzeni, ör. 'Get', 'Put', 'BulkGet', 'GetAndLock', 'PutAndUnlock' işlemlerinin yüzdesi
Önbelleğe alınan veri boyutu	Sınama esnasında önbellekte depolanan veri miktarı
Küme boyutu	Önbellek kümesindeki sunucu sayısı
Nesne boyutu	Serileştirmeden sonra önbellekte depolanan nesnelerin boyutu
Tür karmaşıklığı	Byte, string[], vb. gibi önbellekte depolanan farklı .NET nesne türleri
Güvenlik	Önbellek kümesinin güvenlik ayarları

Grid Dynamics, AppFabric önbelleğe alma özelliğinin performans ve ölçeklenebilirliğini doğrulamanın yanı sıra, sınamaları kendi veri ve iş yüklerinizle tekrarlamanıza olanak tanımak amacıyla sınama donanımı özelliğini sunmaktadır. Bu, kendi senaryonuz için önbelleğe alma performansını değerlendirmek üzere kullanabileceğiniz başka bir seçenektir.

Kesinlikle çalışmanın tamamını ve sonuçlarını görüntülemenizi önersek de, çalışma bulgularından bu incelemenin geri kalanında açıklanan en iyi uygulamalar hakkında bilgi veren birkaçının özetini burada bulabilirsiniz:

• AppFabric önbelleğe alma, önbellek kümesine makine eklendikçe doğrusal bir şekilde ölçeklenir.

• Yüksek bir yazma yüzdesine sahip geniş önbellekler dışında, önbellek boyutunun etkisi düşüktür. Diğer faktörlerin yanı sıra yüksek yazma iş yükleri, yönetilen yığının boyutu büyük olduğunda .NET atık toplama üzerinde daha çok baskı oluşturur.

• Yüksek tür karmaşıklığı, serileştirme nedeniyle yalnızca istemci tarafındaki performansı etkiler.

• Bulk get çağrıları daha iyi ağ kullanımıyla sonuçlanır. Doğrudan önbellek erişimi proxy'lerden (ASP.NET, WCF) daha hızlıdır, ancak bunun nedeni önbelleğe alma performansı değil ara katmanın performansıdır.

• Kötümser ve iyimser kilitleme benzer şekilde gerçekleşir. Bu nedenle, uygulama tasarımınıza en uygun tekniği kullanmanız gerekir. Çakışma oranı azaldığında hem gecikme hem de üretilen iş gelişme gösterir.

• Önbellek kümesi güvenliği performansı azaltır ve varsayılan olarak etkindir. Güvenlik özelliği kapatıldığında en yüksek üretilen iş ve en düşük gecikme elde edilir, ancak verilerin önemliliği ve iş gereksinimleriniz nedeniyle bu seçenek uygun kabul edilmeyebilir.

• Uygulama sunucularıyla önbellek sunucuları arasında ayrılmış ağ kullanılarak ağdaki performans sorunları azaltılır.

Grid Dynamics incelemesinin AppFabric önbelleğe alma özelliğini değerlendirmek için iyi bir başlangıç yeri olduğunu ve kapasite planlama işlemine bilgi sağlamak amacıyla kullanılabilecek işlenmemiş verileri ve gözlemlenen düzenleri içerdiğini göz önünde bulundurun.

Kapasite Planlama Yöntemi

Uygulamanızın dağıtılmış, belleğe yüklenmiş bir önbellekten (AppFabric önbelleğe alma gibi) yararlanabileceğine karar verdiğinizde, kapasite planlama işlemine girmiş olursunuz. AppFabric önbellek kümesine karşı doğrudan sınama yoluyla kapasite planlama adımlarından bazılarını gerçekleştirmeniz mümkün olsa da, bu türde bir sınama yapmadan tahmin oluşturmanız gerekebilir. Bu bölümün odak noktası budur. Aşağıdaki adımlar, AppFabric önbelleğe alma gereksinimleriniz üzerinden sistematik bir düşünme yöntemi sunmaktadır:

1. Performans sorunlarını anlama ve önbelleğe alma adaylarını belirleme

2. Mevcut iş yükü düzenlerini değerlendirme

3. Fiziksel altyapıyı ve donanım kaynaklarını anlama

4. Tüm uygulamalar için gerekli performans SLA'sını sonlandırma

5. Uygun AppFabric özelliklerini ve yapılandırma ayarlarını belirleme

Bu incelemede, örnek bir çevrimiçi mağaza uygulamasının ihtiyaçları incelenerek bu adımlara örnekler verilecektir. Ancak, önbelleğe alma her türlü .NET uygulaması tarafından kullanılabilir ve aynı önbellek kümesine erişim sağlayan birden fazla uygulamanız olabilir. Bu senaryoda, doğru bir kapasite tahmini elde etmek için her uygulamada aşağıdaki adımları gerçekleştirmeniz ve sonuçları toplamanız gerekir.

Birinci Adım: Performans sorunlarını anlama ve önbelleğe alma adaylarını belirleme

Öncelikle önbelleğe almak istediğiniz verileri belirleyin. Bu, SQL Server Profiler, Performans İzleyicisi, Visual Studio sınama ve çok sayıda diğer araç gibi performans çözümleme araçları kullanılarak gerçekleştirilir. Bu araçlar sık erişilen veritabanı nesnelerini veya web hizmetlerine yapılan yavaş çağrıları belirleyebilir. Bu arka uç depolarından döndürülen veri kümeleri, önbelleğe alma için olası adaylardır. Bu verilerin geçici olarak önbellekte depolanması, performansı arttırabilir ve arka uç veri depolarındaki baskıyı azaltabilir.

Olası önbelleğe alma adaylarını belirlediğinizde, bu nesneleri üç ana kategoriden biri altında sınıflandırmanız faydalı bir deneme olacaktır: Etkinlik verisi, Başvuru verisi ve Kaynak verisi. Bunlar en iyi örneklerle açıklanabilir.

• Etkinlik verisi, bireysel bir kullanıcıyla ilgili okuma/yazma verilerini içerir. Örneğin, çevrimiçi bir mağazada kullanıcının alışveriş sepeti bir etkinlik verisidir. Kullanıcının geçerli oturumuna uygulanır ve sıklıkla değişebilir. Alışveriş sepeti için yüksek kullanılabilirliği korumak önemli olsa da, bunlar arka uç veritabanında kalıcı olarak depolanması gerekmeyen verilerdir. Geçici özellikleri nedeniyle, etkinlik verileri önbelleğe alma için mantıklı bir adaydır.

• Başvuru verisi, birden fazla kullanıcı veya birden fazla uygulama örneği tarafından paylaşılan salt okunur verilerdir. Sıklıkla erişim sağlanmalarına rağmen bu veriler sıklıkla değişmez. Örneğin, çevrimiçi mağaza örneğinde, ürün katalogu başvuru verisidir. Bu katalog bir veya birkaç gün boyunca geçerli olmasına rağmen farklı kullanıcılar tarafından binlerce kez erişim sağlanabilir. Bu tür veriler de önbelleğe alma için mükemmel bir adaydır. Herhangi bir türde önbelleğe alma olmadan, ürün katalogunu görüntüleyen her kullanıcının verilere veritabanından erişmesi gerekir. Önbelleğe almanın kullanılması, yarı statik verilere yönelik tekrarlanan istekler için arka uç veritabanındaki baskıyı azaltabilir. Kalıcı özellikleri nedeniyle, bu da önbelleğe alma için mantıklı bir adaydır.

• Kaynak verisi, kullanıcılar tarafından paylaşılan okuma/yazma verileridir. Örneğin, bir destek forumu bu tür verileri içerir. Tüm kullanıcılar forum yazılarına verilen bir yanıtı okuyabilir.

Farklı türlerde önbelleğe alınan veriler farklı kullanım düzenlerine sahip olacağı için, verileri bu kategoriler altında sınıflandırmak faydalı olabilir. Örneğin, bir nesnenin başvuru verisi olarak tanınması, otomatik olarak, ilgili nesnenin daha çok salt okunur bir iş yükü olduğunu belirtir. Ayrıca, daha sık değişen veriler için genellikle daha kısa olan süre sonu ilkelerini belirlemede de yardımcı olabilir. Geliştirme için, bu mantıksal bölümler kodda kapsüllenebilecek alanları belirtebilir.

Her nesne için ayrı bir tahmin oluşturmanız, ardından da bu verileri toplamanız önerilir. Aşağıdaki tabloda bu aşamada toplanan bilgilere bir örnek verilmektedir:

Önbelleğe Alınacak Nesne	Önbelleğe Alma Kategorisi	Kalıcı Depolama Konumu
Alışveriş Sepeti Nesnesi	Etkinlik Verisi	Yok
Kullanıcı Tercihleri Nesnesi	Etkinlik Verisi	Arka Uç Veritabanı
Ürün Katalogu	Başvuru Verisi	Arka Uç Veritabanı
Kullanıcı Forumu Dizisi	Kaynak Verisi	Arka Uç Veritabanı

Önbelleğe alma için aday verileri belirlerken, her kategoride önbelleğe almak üzere veri bulmanız gerekmez. Performans ve ölçeklenebilirliği yalnızca uygulamanızın alışveriş sepetini önbelleğe alarak geliştirebileceğinizi fark edebilirsiniz. Bu adımda önemli olan nokta, önbelleğe almak üzere en iyi öğeleri belirlemek için mevcut verileri kullanmaktır.

İkinci Adım: Mevcut iş yükü düzenlerini değerlendirme

Önbelleğe alınmaya uygun verileri belirledikten sonra, uygulamanın o anda verilere ve ilgili iş yükü düzenlerine nasıl erişim sağladığını anlamanız gerekir. Bu adımın sonunda, önbelleğe alma için bellek gereksinimlerinizin ham bir tahminine ulaşabilmeniz gerekir. Aynı zamanda, verilere nasıl erişildiği ve bu verilerin nasıl kullanıldığını daha iyi anlamanız gerekir. Bu bilgiler, sonraki adımlarda önemli olacaktır.

Örneğin, ürün katalogunuzu önbelleğe alma adayı olarak belirlerseniz, uygulamanın katalog verilerini ne zaman aldığını ve bu isteklerin hangi sıklıkla yapıldığını keşfetmeniz gerekir. Önceki adıma dayanarak bunun başvuru verisi olduğunu, bu nedenle de temelde salt okunur bir iş yükü olduğunu biliyorsunuz. Farklı nesnelerin iş yükü düzenlerinin tam olarak anlaşılması, gelecekteki kapasite kararlarına ışık tutacaktır. Şimdi bu adımın içeriğine daha yakından bakalım.

Mevcut veri erişimi düzenlerinizi daha iyi anlamanızın çeşitli yolları vardır:

1. Verilere nereden erişim sağlandığını ve bu erişimin sıklığını anlamak için kodu baştan sona inceleyin.

2. Yöntem çağrısı sıklığını ve ilişkili performans verilerini sağlayabilecek bir kod profili oluşturucu kullanın.

3. Kodda belirli veri erişim bölümleri etrafında olay oluşturun. Veri erişim denemesini ve ilişkili veri işlemi performansını günlüğe kaydedin.

4. Veritabanı işlemlerinin sayısını ve süresini gözlemlemek için SQL Server Profiler gibi bir veritabanı profili oluşturucu kullanın.

Bu tekniklerin çoğunun, bir önceki adımda önbelleğe alma için hangi verilerin hedef alınacağını belirlemek amacıyla kullanılabileceğini unutmayın. Ancak bu aşamada, gelecekteki kapasite planlama hesaplamalarında kullanılabilecek, daha ayrıntılı sayı bilgisiyle ilgileniyorsunuz.

Bu değerlendirmenin bir parçasını da okuma-yazma oranının anlaşılması oluşturuyor. Okuma/yazma iş yükü, gelecekte kapasiteyle ilgili kararları etkileyebilir. Örneğin, yüksek yazma yüzdesine sahip bir iş yükü daha fazla .NET atık toplama işlemi tetikleyecektir. Bu sonraki bir adımda açıklanmaktadır.

Diğer bir faktör ise en yüksek yük sırasında okuma ve yazmaların sıklığıdır. Aşağıdaki tabloda, örnek alışveriş sepeti nesnesi için bu aşamada toplanan örnek veriler gösterilmektedir.

Çözümlenecek Nesne	Alışveriş Sepeti
Okuma Yüzdesi	%50
Yazma Yüzdesi	%50
Saniye Başına Okuma İşlemi Sayısı (Maks.)	250
Saniye Başına Yazma İşlemi Sayısı (Üst Sınır)	250

Bu çözümlemenin aynısı her nesne türü için yapılmalıdır. Farklı nesne türlerinin yük altında erişim düzenleri ve saniye başına okuma ve yazma sayısı üst sınırları farklı olacaktır.

Önbelleğe alma gereksinimlerini anlamak amacıyla, her tür için belirli bir zamanda önbellekteki etkin nesne sayısı üst sınırını tahmin etmeniz gerekir. Bu tahmin, nesnelerin eklenme sıklığıyla beklenen kullanım ömürleri arasında bir denge içerir. Bu bir örnekle çok daha iyi anlaşılacaktır.

ASP.NET web uygulaması örneğinde, işleme yönelik veriler, en yoğun zamanlarda eşzamanlı 25.000 kullanıcının olduğunu gösterebilir. Her kullanıcı oturum durum bilgisi ister ve bu da 25.000 önbelleğe alınmış nesne anlamına gelir. Ancak, bu nesnelerin sona erme süresi otuz dakika olarak ayarlanabilir. En yoğun zamanlarda, işleme yönelik veriler bir saat içinde 5.000 yeni kullanıcı olduğunu gösterebilir ve bu da otuz dakikalık sona erme süresi içinde 2.500 yeni kullanıcının erişim sağlayabileceği anlamına gelir. Ayrıca, bazı kullanıcılar tarayıcılarını kapatıp yeni bir oturum açabilirler. Kullanıcı aynı olmasına rağmen farklı bir oturum kullanıyor olabilir. Bu nedenle, ek doldurma bu hesaba dahil edilmelidir. Son olarak, sonraki 6-12 ay içinde beklenen büyüme de planlanmalıdır. Sonuçta, önbellekteki etkin nesne sayısının üst sınır hesaplaması şöyle olabilir:

Çözümlenecek Nesne:	Alışveriş Sepeti
En Yüksek Eşzamanlı Kullanıcı Sayısı	25.000
Sona Erme Süresi Dahilindeki Yeni Kullanıcı Sayısı (30 dakika)	2500
Yeni Tarayıcı Oturumu Başlatan Varolan Kullanıcıların Sayısı	250
Gelecekteki Büyüme Tahmini (%25)	6940
Toplam Etkin Nesne Sayısı (Üst Sınır):	Etkin Nesne Sayısı Üst Sınırı ~35000

Girişlerde, örneğin sona erme süresinde herhangi bir değişiklik olduğunda, en yoğun yük sırasında önbellekte yer alan süresi dolmamış nesnelerin sayısı da değişecektir. Bu, yalnızca, düşünme sürecine yönelik bir örnektir. Diğer nesne türlerinde, hesaplamaya dahil edilmesi gereken farklı düzenler ve değişkenler yer alabilir. Örneğin, paylaşılan bir ürün katalogu tüm gün boyunca geçerliyse, gün içinde önbellekte yer alan ürün katalogu sayısının üst sınırı bir olmalıdır.

Ancak, önbellekte yer alan en fazla nesne sayısının bilinmesi, yalnızca ortalama nesne boyutu da bilindiğinde kullanışlı olabilir. Bu da başlı başına güç bir sorundur. Alışveriş sepeti örneğinde, bir kullanıcı sepetine tek bir öğe koyarken diğer bir kullanıcı on veya yirmi öğe koyabilir. Hedef ortalama sayıyı anlamaktır. Bu süreçte yapılan çoğu sayı hesabında da olduğu gibi, mükemmel bir sayıya ulaşılmayacaktır. Ancak, elde edilen sonuç önbellek kümeniz için basit bir tahminden öte iyi düşünülmüş bir başlangıç noktası olacaktır.

Nesneler önbellekte seri halde depolanır. Bu nedenle, ortalama nesne boyutunu anlamak için, seri hale getirilmiş ortalama nesne boyutunu hesaplamalısınız. AppFabric, öğeleri önbellekte depolamadan önce seri hale getirme için NetDataContractSerializer sınıfını kullanır. Ortalama nesne boyutunu belirlemek için, uygulamanıza nesnelerinizi seri hale getiren ve onların seri hale getirilmiş boyutlarını kaydeden bir araç kodu ekleyin.

Aşağıdaki kod örneği, tek bir nesnenin ortalama boyutunu tahmin etmeyi dener. Seri hale getirilen nesnenin adı: obj. Uzunluğu kaydetmek için length değişkeni kullanılır. NetDataContractSerializer ile boyutu elde etmede herhangi bir sorun yaşarsanız, onun yerine BinaryFormatter kullanın. Kullanımı kolaylaştırmak için bunu bir yöntemde birleştirebilirsiniz. Bu durumda, obj parametre olarak iletilir ve yöntemden length elde edilir.

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

Not

Sınama önbellek kümesi kurulumunuz varsa önbelleğe öğe ekleyebileceğinizi ve önbelleğe eklenen bir veya daha fazla nesnenin boyutunu bulmak için Windows PowerShell komutunu, Get-CacheStatistics, kullanabileceğinizi göz önünde bulundurun. Ya da önbellekteki birden fazla nesnenin boyutunu önbellekteki nesne sayısına bölebilirsiniz. Tahminleri kodla veya sınama yoluyla toplama seçeneklerinden birini belirlemelisiniz.

Oturum durumu için AppFabric önbelleğe alma özelliğini kullanmayı planlıyorsanız, ASP.NET oturum durumu için SQL Server sağlayıcısının her zaman NetDataContractSerializer yerine BinaryFormatter kullandığını bilmeniz önemlidir. Bazen, NetDataContractSerializer sınıfıyla seri hale getirilmiş nesneler, BinaryFormatter kullanan seri hale getirilmiş nesnelerin boyutundan birkaç kat büyük olabilir. SQL Server'daki oturum durumu nesnelerinin boyutuna bakıyorsanız bu önemlidir; çünkü, bu boyutu temel alarak önbellekteki boyutun da aynı olacağını varsayamazsınız. Kaba bir tahmin elde etmek için bu boyutu altıyla çarpabilirsiniz. Daha iyi bir tahmin elde etmek için, oturum durumunda depolanan nesnelerde yukarıda açıklanan kodu kullanın. Bu noktaya kadar toplanan verilerle toplam bellek gereksinimlerini formüle edebilirsiniz. Bu adım aşağıdaki alt görevleri içerir:

1. Bir nesne türüne odaklanın (örneğin, Alışveriş Sepeti nesnesi).

2. Bu nesne için öncelikle seri hale getirilmiş ortalama nesne boyutunu alın.

3. Ardından, önbelleğe alma ek yükü için ortalama boyuta 500 bayt ekleyin.

4. Bu boyutu, etkin nesne sayısı üst sınırıyla çarpın. Bu size ilgili nesne türü için önbelleğe alma için toplam bellek gereksinimini verir.

5. Dahili önbelleğe alma yapıları için tahmini bir ek yükü ekleyin (%5).

6. Bu adımları, belirlenen her nesne türü için tekrarlayın.

7. Önbelleğe alma için toplam bellek gereksinimini hesaplamak amacıyla sonuçları toplayın.

Bu işlemde, tahmin boyutlarına her nesne için yaklaşık 0,5 KB boyutunda bir ek yükü eklemeniz gerektiğini unutmayın. Ayrıca, önbellekte bellek gerektiren başka dahili veri yapıları da vardır. Bölgeler, etiketler ve bildirimlerin tamamı yönetilmesi gereken ek bir bellek gerektirir. Örnek hesaplamalarımızda, bu dahili yapıları da hesaba katmak için toplam boyutun %5'ini ekliyoruz. Ancak, bu yüzde bu önbelleğe alma özelliklerini kullanma boyutunuza bağlı olarak daha az veya daha çok olabilir.

Bu noktada, belirli bir AppFabric önbelleğe alma özelliğinin, yüksek kullanılabilirlik özelliğinin etkisini düşünmeniz gerekir. Bu özellik, ikincil sunucularda, önbelleğe alınan öğelerin kopyalarını oluşturur. Bu da tek bir önbellek sunucusu çalışamaz duruma geldiğinde, ikinci önbellek sunucusunun uygulamayı devraldığı ve verilerin kaybolmadığı anlamına gelir. Yüksek kullanılabilirliği kullanmayı seçtiğinizde, bellek tahminlerini ikiye katlamanız gerekir. Ayrıca, Windows Server 2008 Enterprise sürümünü veya üstünü kullanmanız gerekir. Yüksek kullanılabilirlik özelliğinin adlandırılmış önbellek düzeyinde yapıldığını unutmayın. Bu, aynı kümede adlandırılmış iki önbellek oluşturmanız durumunda her önbellek için yüksek kullanılabilirliği kullanmanızın gerekmediği anlamına gelir. Uygulama bazı öğeleri adlandırılmış önbelleğe yüksek kullanılabilirlikle, bazılarını ise yüksek kullanılabilirlik olmadan yerleştirir. Bu, bellek kaynaklarınızı en iyi şekilde kullanmanıza yardımcı olabilir. Bu nedenle, yüksek kullanılabilirliği kullanan önbelleklerde bellek gereksinimleri iki katına çıktığı için, bu özellikle ilgili vereceğiniz kararı bilmeniz önemlidir.

Örnek olarak burada aynı uygulamadaki Etkinlik verisi ve Başvuru verisi gereksinimlerini değerlendirdiğimiz bir tabloyu sunuyoruz. Senaryonuza bağlı olarak, bu tahmini nesne veya uygulama düzeyinde gerçekleştirmeyi seçebilirsiniz. Tek yapmanız gereken, bu örneğe daha fazla sütun eklemek ve bu sütunları uygun şekilde etiketlemektir.

Çözümlenecek Nesne:	Etkinlik Verisi	Başvuru Verisi
Seri Hale Getirilmiş Ortalama Nesne Boyutu:	250 KB	60 KB
Nesne Başına Önbellek Kümesi Ek Yükü:	0,5 KB	0,5 KB
Ayarlanan Seri Hale Getirilmiş Ortalama Nesne Boyutu:	250,5 KB	60,5 KB
Etkin Nesne Sayısı Üst Sınırı:	~35000	~68000
Önbelleğe Alma Bellek Gereksinimleri:	8,4 GB	3,9 GB
Yüksek Kullanılabilirlik Etkin Mi?	16,8 GB	Hayır
Dahili Veri Yapıları Ek Yükü (%5):	0,8 GB	0,2 GB
Toplam Bellek Gereksinimleri:	17,6 GB	4,1 GB

Bu tahminlerin toplamı, önbellek kümesi için ilk bellek gereksinimlerini oluşturur. Bu örnekte toplam boyut 21,7 GB'dir. Bu tahminden yola çıkarak, fiziksel altyapı, SLA gereksinimleri ve AppFabric önbellek yapılandırma ayarları dahil olmak üzere diğer noktaları incelemeye başlayabilirsiniz.

Üçüncü Adım: Fiziksel altyapıyı ve donanım kaynaklarını anlama

Fiziksel altyapınızı ve kaynakların kullanılabilirliğini anlamanız önemlidir. Yaygın sorulardan bazıları şunlardır:

1. Fiziksel makineleri veya sanal makineleri hazırlayabilecek misiniz?

2. Mevcut bir donanımınız varsa, makine yapılandırmaları nelerdir (örneğin, 8 GB RAM, Dört Çekirdekli)?

3. Önbellek kümesi uygulama sunucularıyla aynı veri merkezinde bulunacak mı?

4. Ağ özellikleri nelerdir?

Önbellek sunucuları için sanal makineler kullanmayı planlıyorsanız, dikkat etmeniz gereken çeşitli noktalar vardır. Örneğin, aynı fiziksel makinede birden fazla sanal makine bulunmasının etkisini düşünmeniz gerekir. Birden fazla sanal makine aynı ağ kartını paylaşabilir, bu da ağda performans sorunlarıyla karşılaşma ihtimalini arttırır. Ayrıca, aynı fiziksel makinede sanal makine olan birincil ve ikincil önbellek konağı arasında yüksek kullanılabilirlik özelliği ayarlanabilir. Bu fiziksel makine çalışamaz duruma gelirse, verilerin kopyası bulunmaz. Daha fazla bilgi için bkz. Sanal Makinede AppFabric Önbelleği çalıştırmaya ilişkin kılavuz.

Varolan makineler için önerilen herhangi bir belirtim yoktur. Ancak, büyük önbellek kümeleri için 16 GB RAM, Dört Çekirdekli makinelerin iyi çalıştığı gözlemlenmiştir. Genellikle, doğru fiziksel bellek ve ağ yükü miktarı için planlama yapmak dikkat edilmesi gereken en önemli noktalardır.

Hem fiziksel hem de sanal makinelerde, önbellek kümesinin önbelleği kullanan uygulama veya web sunucularına olan konumuna dikkat etmeniz gerekir. Farklı veri merkezlerinde bulunuyorlarsa, bu veri merkezleri arasındaki gecikmenin performansınızı olumsuz yönde etkilemeyeceğinden emin olun. Bu aşamada, önbellek sunucularınız için uygulamanızı veya web sunucularınızı kullanmak size cazip görünebilir. Bu mümkün olmasına rağmen desteklenmez. Öncelikle, bu makinelerde IIS gibi hizmetler nedeniyle kaynak kullanımındaki herhangi bir ani değişim önbellek kümesini etkileyebilir. İkinci olarak, önbelleğe alma hizmeti ayrılmış bir sunucuda olduğunu varsayar ve belirttiğinizden çok daha fazla bellek kullanma olasılığına sahiptir.

Ağ özellikleri için, beklenen ağ yükünüzü değerlendirmeniz ve altyapınızla karşılaştırmanız gerekir. Öncelikle, her önbellek sunucusundan ne kadar veri işlemesi beklendiğini ve ağ kartı özelliklerinin yeterli olup olmadığını bilmeniz gerekir. Yeterli değilse, daha fazla önbellek sunucusu isteyebilirsiniz. Örneğin, önbelleğe alınan ortalama nesne boyutunun 500,5 KB olduğu ve önbellek sunucusunda saniye başına 240 işlemin bulunduğu bir senaryoyu ele alalım. Tek bir önbellek konağı kullanıldığında elde edilen sonuçlar şöyledir:

Saniye başına nesne okuma/yazma sayısı:	240
Önbellek kümesindeki makine sayısı:	1
Makine başına saniyedeki önbellek işlemi sayısı:	240
Ortalama nesne boyutu:	500,5 KB
Saniye başına iletilen veri boyutu:	240 * 500,5 = 117,3 MB/sn

Her makinede 1 Gb/sn'lik bir ağ kartı varsa, üretilen maksimum iş yaklaşık 119 MB/sn'dir. Hesaplanan 117,3 MB/sn değeri muhtemelen tek sunucu için fazla gelecektir. Bu da ağda performans sorunu yaşama olasılığını arttıracaktır. Bunun yerine önbellek kümesinde üç makine kullanılsaydı, önbellek istekleri eşit bir şekilde dağıtıldığında her sunucuya bu yükün 1/3'ü düşecekti.

Ayrıca, önbellek kümesine erişim sağlayan uygulama sunucularının ağ kullanımını da göz önünde bulundurun. Diğer sistemlerle büyük hacimli veri değişiminde bulunuyorlarsa, uygulama sunucularıyla önbellek kümesi arasında ayrılmış bir ağ oluşturmayı düşünmeniz gerekir. Bu da bu amaçla her uygulama sunucusuna ek bir ağ kartı takılmasını gerektirir.”

Ağla ilgili düşünülmesi gereken son nokta, ağın tüm yol boyunca istenen yükü kaldırıp kaldıramayacağıdır. Her önbellek sunucusunda yalnızca 1 Gb/sn'lik ağ kartının bulunması yeterli değildir. Anahtarın ve ağ üzerindeki diğer noktaların da yükü kaldırabilmesi gerekir. Bu gereksinimi karşılamaya yönelik işlemler üzerinde çalışın.

Dördüncü Adım: Tüm uygulamalar için gerekli performans SLA'sını sonlandırma

Son yapılandırmaya karar vermeden önce, performans ve güvenilirlik hizmet düzeyi anlaşmaları (SLA'lar) dahil olmak üzere tüm iş gereksinimlerini anlamanız gerekir. Pratikte bu adım, önbellek kümelerinin sayısı ve her kümedeki önbellek konaklarının sayısına ilişkin kararı etkiler.

Örneğin, önbellek kümesi kullanan görev kritik bir uygulamanız varsa, bu önbellek kümesini diğer düşük öncelikli uygulamalardan ayırmak isteyebilirsiniz. Düşük öncelikli uygulamalar muhtemelen daha fazla bellek, ağ veya CPU kaynağı kullanır ve bu da görev kritik uygulamayı olumsuz yönde etkiler.

Özellikle bu kararı etkileyen faktörler şunlardır:

• Güvenlik önbellek kümesi düzeyinde korunur. Kullanıcının önbellek kümesine erişimi varsa, bu kullanıcı muhtemelen önbellek kümesindeki tüm verilere erişebilir (kullanıcının istekte bulunmak için önbellek adını ve anahtarını bildiği varsayıldığında). Farklı türde veriler için farklı güvenlik ayarlarına ihtiyacınız varsa, ayrı önbellek kümeleri sizin için ideal olabilir. Daha fazla bilgi için bkz. Güvenlik Yönetimi.

• Bellek üst eşik düzeyine ulaştığında, süresi dolmamış öğeler çıkarılır. Bir önbellek için gerekli olan bellek miktarının düşük olarak hesaplanması, kümedeki tüm önbellekleri etkileyebilir. Bellek sıkıntısı nedeniyle çıkarma işlemi gerçekleşirse, bellek sıkıntısına neden olan tek bir önbellek olsa da bu tüm önbelleklerde gerçekleşir. Bu durum, çıkarılabilir olmayan önbellekler oluşturularak bir şekilde azaltılabilir, ancak bunun da dikkatle yapılması gerekir. Daha fazla bilgi için bkz. Süre Sonu ve Çıkarma.

• Ayrı önbellek kümelerinin yönetilebilirliği bir dereceye kadar daha kolay olabilir. 100 farklı önbellek için ayrı kümeleri yönetmek istemeyebilirsiniz. Ancak, 2 farklı büyük önbellek için ayrı önbellek kümelerine sahip olmanız, bunları ayrı şekilde yönetebileceğiniz, ölçekleyebileceğiniz ve izleyebileceğiniz için kullanışlı olabilir.

Son olarak, bazı gereksinimler gecikmeyle ve üretilen işle ilgili dikkat edilmesi gereken noktalar içerebilir. Bu kararla ilgili bilgi almak üzere hem kılavuz hem de sınama sonuçları için bkz. Grid Dynamics teknik incelemesi. Örneğin, her önbellek kümesi için üretilen iş gereksinimlerinizi Grid Dynamics incelemesinden elde edilen, yayınlanmış sınama sonuçlarıyla karşılaştırabilirsiniz. Bu çalışma, üretilen iş hedefleriniz için yeterli olmayacak kadar az sunucunuz olduğunu gösterebilir. Bu çalışmanın nesne türlerinizle, nesne boyutlarınızla, fiziksel ve mantıksal altyapılarınızla birebir eşleşmeyeceğini göz önünde bulundurmanız önemlidir. Yine de, bilinçli bir karar vermenize yardımcı olabilecek, kanıtlanmış test sonuçlarını sağlamaktadır.

Beşinci Adım: Uygun AppFabric özelliklerini ve yapılandırma ayarlarını belirleme

Sürecin bu kısmında, hem AppFabric önbelleğe alma özelliğine ilişkin spesifik yapılandırma ayarları hem de AppFabric önbellek kümesinin mimarisi ele alınmaktadır. Toplanan tüm doğru deney ve iş verileriyle bile, bu AppFabric önbelleğe alma ayarlarını göz ardı ettiğinizde yanlış planlama yapabilirsiniz.

Aşağıdaki tabloda, çeşitli AppFabric önbelleğe alma özellikleri ve kapasite planlamasına ilişkin önemli noktalar listelenmiştir.

Bölgeler	Birden fazla bölge oluşturabilirsiniz, ancak her bölge tek bir önbellek konağında bulunur. Dağıtılmış önbellekten yararlanmak için uygulamaların birden fazla bölge kullanması gerekir. Bölgeleri otomatik olarak belirtmeyen tüm çağrıların, dahili olarak varsayılan bölgeleri kullandığını unutmayın. Önbellek kümesindeki her önbellek konağı, en büyük bölgenin maksimum boyutunu barındırabilmelidir.
Bildirimler	Önbellekler bildirimde bulunabilir ve önbellek istemcileri bu bildirimleri alabilir. Bu, sunucu tarafı için ek ağ trafiği ve işlemci kullanımı anlamına gelir. Bunun etkisi, bildirim aralığına ve gönderilen bildirim sayısına bağlı olarak değişir. Çok kısa aralıklarla gönderilen yüksek sayıda bildirim, performans ve ölçeklenebilirliği etkileyebilir. Bu etkiyi tahmin etmek üzere belirli yönergeler olmadığı için etkinin sınama esnasında gözlemlenmesi gerekir.
Yerel Önbellek	Yerel önbellek, hem istemcilerdeki hem de sunucudaki nesneleri önbelleğe alarak performansı arttırır. Yerel önbelleği kullanmanızın istemci makinelerindeki bellek etkisini düşünün. Yerel olarak önbelleğe alınan tüm öğeler aynı zamanda sunucuda da bulunduğu için, bu özellik sunucu tarafında bellekle ilgili kapasite planlamasını etkilemez. Ancak, yerel önbellekte geçersiz kılma için bildirimler kullanılıyorsa, bildirim işlemesi sunucu tarafını etkileyebilir.
İstemci Tarafı Uygulama Tasarımı ve Yapılandırması	İstemci tarafı uygulama tasarımı genel performansınızı etkileyebilir. Örneğin, oluşturduğunuz tüm DataCacheFactory nesnelerini her çağrıda yeniden oluşturmak yerine yeniden kullanılmak üzere depolamanız gerekir. Ayrıca, her iş parçacığı için bir DataCacheFactory nesnesi oluşturmanız da yararlı olabilir. Ya da, birden fazla iş parçacığında tek bir DataCacheFactory nesnesini paylaşıyorsanız, MaxConnectionsToServer ayarını yükseltmeyi düşünebilirsiniz. Bu, her DataCacheFactory için önbellek sunucularıyla kurulan bağlantı sayısını arttırır.
Yüksek Kullanılabilirlik	Daha önce de belirtildiği gibi Yüksek Kullanılabilirlik özelliğini kullanan önbelleklerde, hesaplanan bellek gereksiniminin ikiyle çarpılması gerekir. Ancak bu özellik aynı zamanda minimum üç sunucu gerektirir. Bir sunucu çalışamaz duruma geldiğinde, arızadan sonra her öğrenin birincil ve ikincil kopyalarını desteklemek için iki sunucu daha olması gerekir. Ayrıca, bu özelliğin tüm sunucularda Windows Server 2008 Enterprise sürümü veya üstünü gerektirdiğini unutmayın.
Adlandırılmış Önbellekler	Şu anda, adlandırılmış önbellek sayısı 128 ile sınırlıdır. Bu sayıdan daha fazla adlandırılmış önbellek gerektiren uygulamalarınızın olması bir kapasite planlama kararı teşkil eder. Bu noktada birden fazla önbellek kümesine ihtiyacınız vardır veya uygulamalarınız daha az önbellek kullanacak şekilde tasarlanmalıdır. Diğer bir yöntem de, adlandırılmış önbellekler içinde programlı bir şekilde bölgeler oluşturmaktır.
XML Yapılandırma Deposu	Önbellek kümesi yapılandırma deponuz için paylaşılan bir ağ konumu kullandığınızda, kümede her biri Temel Konak olarak belirlenmiş en az üç sunucunuz olmalıdır. Bunun nedenleri hakkında daha fazla bilgi için bkz. Önbellek Sunucularını Güncelleştirme.

Anlaşılması gereken en önemli ayarlar arasında her önbellek konağındaki bellek ayarlarının olması şaşırtıcı değildir. Windows PowerShell komutunu, Get-CacheHostConfig, kullanarak her bellek konağında varsayılan bellek ayarlarını görüntüleyebilirsiniz.

Not

Önbelleğe alma Windows PowerShell komutlarının nasıl kullanılacağına ilişkin bilgi için bkz. Sık Gerçekleştirilen Önbellek Kümesi Yönetimi Görevleri.

Aşağıdaki ekran görüntüsünde, 4 GB RAM'i olan bir makinede Get-CacheHostConfig komutuyla elde edilen çıktı gösterilmektedir.

Varsayılan olarak, belirli bir sunucuda önbellek için ayrılan bellek miktarı toplam RAM boyutunun %50'sidir. Bu örnekte RAM boyutunun yarısı 2 GB'dir. Böylece, kalan bellek işletim sistemi ve hizmetleri için kullanılabilir. Daha fazla belleğe sahip makinelerde bile, bu varsayılan ayarın korunması önerilir. Önceden de belirtildiği gibi, önbelleğe alma hizmeti ayrılmış bir makinede çalıştığını varsayar ve önbellek için ayrılmış bellekten çok daha fazlasını kullanabilir. Bu bellek kullanımının bir kısmı önbelleğe alma hizmetinin dahili tasarımı nedeniyle olsa da, diğer bir kısmı .NET bellek yönetimi ve atık toplamasıyla ilgilidir. Bellek NET uygulamasında yayımlanmış olsa da, işlem belleğinden çıkarılmak için atık toplamasını beklemelidir. Bu işlemde, atık toplamasının belirleyici olmayan yapısını hesaba katmak için fiziksel belleğin arabelleğe alınması gereklidir.

Atık toplamasının etkisini anladıktan sonra, yüksek bir yazma yüzdesine ve sıklığına sahip iş yüklerinde atık toplama döngülerini hesaba katmak için belleğin arabelleğe daha çok alınması gerektiğini görebilirsiniz. Çoğunlukla salt okunur olan iş yüklerinde bu önemli değildir. Bu nedenle, bazı durumlarda önbelleğe alma için ayrılmış bellek miktarını yükseltmeyi düşünebilirsiniz. Örneğin, 16 GB'lik bir makinede önbellek Boyut ayarı için 12 GB ayırmayı (varsayılan ayar 8 GB yerine) düşünebilirsiniz. Bu da, işletim sistemi ve hizmetleri için 4 GB'lik bir ek yük anlamına gelir. Burada makinenin, şu anda desteklenen tek yapılandırma olan önbelleğe alma hizmeti için ayrıldığı varsayılır. Bu örnekte, bu bellek yapılandırmasını beklediğiniz yükle sınamanız gerekir. Bellek ayırma çok kısıtlayıcıysa, bu hata, sınama sırasında çıkarma veya kısıtlama gibi bellekle ilgili sorunlarla kendini gösterecektir. Daha fazla bilgi için bkz. Sunucu Sorunlarını Giderme (Windows Server AppFabric Önbelleğe Alma). Aşağıdaki örnekte, Server1 olarak adlandırılmış bir sunucuda önbellek boyutunu 12 GB olarak ayarlamak için Set-CacheHostConfig komutu kullanılmaktadır:

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

Get-CacheHostConfig çıktısında gözlemlenecek diğer bir öğe de eşik değerleridir. LowWatermark değeri, varsayılan olarak önbellek Boyut ayarının %70'ine sahiptir. Önbelleğe alınan bellek LowWatermark değerine ulaştığında, Önbelleğe Alma hizmeti süresi dolmuş olan nesneleri çıkarmaya başlar. Bu nesnelere zaten erişim sağlanamadığı için bu herhangi bir sorun teşkil etmez.

HighWatermark değeri, varsayılan olarak önbellek Boyut ayarının %90'ına sahiptir. HighWatermark düzeyinde nesneler, bellek LowWatermark düzeyine dönünceye kadar süreleri dolmuş olsa da olmasa da çıkarılırlar. Görüldüğü üzere bu performansı düşürebilir ve muhtemelen kötü bir kullanıcı deneyimiyle sonuçlanır.

HighWatermark değerini geçme ihtimalinden kaçınmak amacıyla önbellek kullanımınızı LowWatermark düzeyinde planlamanızı öneririz. Daha ayrıntılı bir açıklama için bkz. Süre Sonu ve Çıkarma.

İpucu

Tam atık toplama döngüleri kısa bir gecikmeye neden olabilir ve bu da sıklıkla yeniden deneme hatalarında görünür. Bu nedenle, her önbellek konağında 16 GB boyutunda veya daha az bellek bulundurmanızı öneririz. 16 GB RAM'den fazlasına sahip makinelerde, tam atık toplama döngülerinde daha uzun duraklamalar yaşanabilir. Bununla birlikte, her önbellek konağında daha fazla bellek kullanımına ilişkin herhangi bir kısıtlama yoktur. Daha çok salt okunur olan bir iş yükünde, tam atık toplama döngüleri sıklıkla yaşanmayabilir. Bunu en iyi yük sınama yöntemiyle belirleyebilirsiniz.

Önceki bir örnekte, önbelleğe alma için toplam bellek gereksinimimizi tahmini 21,7 GB olarak hesaplamıştık. Yüksek kullanılabilirlik istediğimiz için, en az üç sunucumuz olmalıdır. Her sunucuda 16 GB'lik RAM olduğunu varsayalım. Bu örnekte, her sunucuda varsayılan önbellek Boyut ayarını 8 GB olarak bırakacağız. Önceden de belirtildiği gibi, LowWatermark (%70) her sunucuda hedeflenen kullanılabilir bellek olmalıdır. Bu da her önbellek sunucusunda tahmini 5,6 GB bellek olduğu anlamına gelir. Bu faktörler göz önünde bulundurulduğunda, aşağıdaki tabloda dört sunucunun 22,4 GB'lik bir önbelleğe alma belleği sağlayacağı ve 21,7 GB gereksinimini karşılayacağı gösterilir.

Toplam Bellek Gereksinimi	21,7 GB
İlk Bellek (Önbellek Konağı)	16 GB
Önbellek Boyutu ayarı (Önbellek Konağı)	8 GB
Alt Eşik (Önbellek Konağı)	70%
Önbellek Konağı Başına Ayarlanan Bellek Hedefi	5,6 GB
Önbellek Kümesindeki Toplam Bellek (3 makine)	,6 GB * 4 Sunucu = 22,4

Bu tahmini, üretilen iş ve gecikme hedeflerini göz önünde bulundurarak doğrulamak için Grid Dynamics teknik incelemesinde yayımlanan sonuçları da kullanabileceğinizi tekrar hatırlatmak isteriz. Bu sınama sonuçları, örneğin ek bir önbellek sunucusu ekleyerek başlangıç tahmininizde ufak değişiklikler yapmanızı sağlayabilir. Burada önemli olan nokta, bilinçli bir karara varmak için bu gibi kullanılabilir kaynaklardan yararlanmaktır.

Kapasite Planlama Aracı

Elektronik tablo, önceki bölümlerde yer alan kapasite planlama adımları için uygun bir araçtır. Buradan yükleyebileceğiniz örnek bir elektronik tablo oluşturduk. Yıldız işaretine sahip girişler, planlamanıza ve kaynaklarınıza bağlı olarak değiştirmeniz gereken öğeleri temsil eder. Geri kalan hesaplamalar elektronik tablo tarafından yapılır.

Elektronik tablonun ilk kısmı, her önbellek konağı için sunucu yapılandırmasını belirtir. Bunu planlama sürecinin bir parçası olarak değiştirebileceğinizi ve son hesaplamalardaki farklılıkları gözlemleyebileceğinizi unutmayın. Aşağıdaki ekran görüntüsünde bu ilk bölüm gösterilmiştir.

Önemli

Varsayılan kurulum değerlerini kullanmadığınız sürece, her önbellek konağında CacheSize ve LowWatermark ayarlarını uygulamak için Set-CacheHostConfig komutunu kullanmanız gerekir.

İkinci bölüm, farklı nesne türleri için tahminleri girmenize olanak tanır. Örnek elektronik tabloda, “Etkinlik Verisi” ve “Başvuru Verisi” için yalnızca iki bölüm kullanılır. Ardından, bir dizi boş sütun verilmiştir. Bu sütunları, planlamanızda kullandığınız ayrıntı düzeyine bağlı olarak (nesne, kategori, uygulama, vb.) yeniden adlandırabilirsiniz. Aşağıdaki ekran görüntüsünde bu ikinci bölüm gösterilmiştir.

Üçüncü bölümde ağ gereksinimleri tahmini olarak hesaplanır. Ortalama okuma/yazma nesnesi boyutlarını ve saniye başına okuma/yazma işlemi sayısı üst sınırını girersiniz. Bu bölümde, ilgili nesne türü için maksimum ağ bant genişliği gereksinimleriniz hesaplanır. Bu, makine ve ağ kartı gruplandırmalarınızın yükü kaldırıp kaldıramayacağına ilişkin genel bir fikir edinmek için kullanılabilir. Önceki bölümlerde açıklandığı gibi, ağ yolundaki bant genişliğine bakmak da isteyebilirsiniz. Aşağıdaki ekran görüntüsünde bu üçüncü bölüm gösterilmiştir.

Son bölümde, bellek ve ağ bölümlerindeki gereksinimler toplanmaktadır. Daha sonra, sunucu sayısını hesaplamak için ilk bölümde belirtilen makine yapılandırması kullanılır. “Ek Sunucular” alanı, gerekirse, hesaplanmış olan bu toplam sayıyı arttırmanıza olanak tanır. Örneğin, hesaplamalar sonucu yalnızca iki sunucunun gerekli olduğu sonucuna varılırsa, yüksek kullanılabilirliği uygun şekilde desteklemek için nihai toplam sayıya ek bir sunucu ekleyebilirsiniz. Aşağıdaki ekran görüntüsünde bu son bölüm gösterilmiştir.

Not

Yukarıdaki ekran görüntülerinde bu incelemedeki örneğe benzer sayılar kullanılmaktadır, ancak tahmin edilen sunucu sayısı dört yerine üçtür. Bunun nedeni, elektronik tablonun bu özel ayarı göstermek amacıyla Cache Size Setting(Set-CacheHostConfig) değerini 12 GB olarak ayarlamasıdır. Bu değerin 8 GB olarak değiştirilmesi, bu incelemenin önceki bölümlerinde görülen sonuçlara benzer sonuçlar verecektir.

Kapasite Planlamada Sonraki Adımlar

Önceki bölümde, önbellek kümelerinin sayısına, her kümedeki önbellek konaklarının sayısına ve bu önbellek konaklarının yapılandırılmasına ilişkin bir başlangıç tahmini elde etmeye yönelik bir yöntem sunulmuştur. Ancak, bunun sınamaya ve sürekli izlemeye bağlı olarak değişebilecek bir tahmin olduğunu göz önünde bulundurmalısınız.

AppFabric önbelleğe alma özelliğini kullanmaya ilişkin planlarla ilerlemeye karar verirseniz, AppFabric önbelleğe almanın çözümünüzde nasıl çalışacağına ilişkin bir fikir edinmek amacıyla kavram kanıtı oluşturabilirsiniz. Bunun ardından, sınamaları ortamınızda yürütmek amacıyla bir sınama önbellek kümesi kurulumu isteyebilirsiniz. Sınama sonuçlarına dayalı olarak kapasite, performans ve ölçeklenebilirlik gereksinimlerine ulaşmak amacıyla yapılandırmanızda daha fazla değişiklik yapabilirsiniz. Aşağıdaki bölümde, hem sınama hem de üretim sırasında göz önünde bulundurabileceğiniz belirli sürekli ölçümler ele alınmaktadır.

Sürekli Önbelleğe Alma Kapasitesi Gereksinimlerini İzleme

Önbelleğe alma kapasitesini planlama, kesinlikle tamamen bilimsel değildir. Sonuçlara dahil edilen sayıların çoğu da tahmin edilen sayılardır. Ayrıca, uygulama kullanımı ve düzenleri de zaman içinde değişebilir. Bu nedenle, önbellek kümesinin kapasite gereksinimlerini karşıladığından emin olmak için performans göstergelerini izlemeniz gerekir. Başarılı bir kapasite planlaması, hem test hem de üretim ortamlarında devam eden kesintisiz bir süreçtir.

Performans İzleyicisi aracı, kapasiteyi sürekli olarak izlemenin en iyi yoludur. Her önbellek konağında aşağıdaki sayaçları izlemeniz önerilir:

İzleme Kategorisi	Performans İzleyicisi Sayaçları
Bellek	AppFabric Önbelleğe Alma:Konak\Toplam Veri Boyutu (Bayt) AppFabric Önbelleğe Alma:Konak\Çıkarılan Toplam Nesne Sayısı AppFabric Önbelleğe Alma:Konak\Toplam Çıkarma İşlemi Çalıştırma Sayısı AppFabric Önbelleğe Alma:Konak\Çıkarılan Toplam Bellek AppFabric Önbelleğe Alma:Konak\Toplam Nesne Sayısı .NET CLR Belleği(DistributedCacheService)\Gen 0 Toplama Sayısı .NET CLR Belleği(DistributedCacheService)\Gen 1 Toplama Sayısı .NET CLR Belleği(DistributedCacheService)\Gen 2 Toplama Sayısı .NET CLR Belleği(DistributedCacheService)\Sabitlenmiş Nesne Sayısı .NET CLR Belleği(DistributedCacheService)\GC'deki Süre Yüzdesi .NET CLR Belleği(DistributedCacheService)\Büyük Nesne Yığını boyutu .NET CLR Belleği(DistributedCacheService)\Gen 0 yığın boyutu .NET CLR Belleği(DistributedCacheService)\Gen 1 yığın boyutu .NET CLR Belleği(DistributedCacheService)\Gen 2 yığın boyutu Bellek\Kullanılabilen Megabaytlar
Ağ	Ağ arabirimi(*)\Alınan Baytlar/sn. Ağ arabirimi(*)\Alınan Baytlar/sn. Ağ Arabirimi(*)\Mevcut Bant Genişliği
CPU	İşlem(DistributedCacheService)\İşlemci Süresi Yüzdesi İşlem(DistributedCacheService)\İş Parçacığı Sayısı İşlem(DistributedCacheService)\Çalışma Kümesi İşlemci(_Total)\İşlemci Süresi Yüzdesi
Üretilen İş	AppFabric Önbelleğe Alma:Konak\Toplam İstemci İsteği Sayısı AppFabric Önbelleğe Alma:Konak\Toplam İstemci İsteği Sayısı /sn. AppFabric Önbelleğe Alma:Konak\Toplam Get İsteği Sayısı AppFabric Önbelleğe Alma:Konak\Toplam Get İsteği Sayısı /sn. AppFabric Önbelleğe Alma:Konak\Toplam Get İsteği Sayısı AppFabric Önbelleğe Alma:Konak\Toplam Get İsteği Sayısı /sn. AppFabric Önbelleğe Alma:Konak\Toplam GetAndLock İsteği Sayısı AppFabric Önbelleğe Alma:Konak\Toplam GetAndLock İsteği Sayısı /sn. AppFabric Önbelleğe Alma:Konak\Toplam Okuma İsteği Sayısı AppFabric Önbelleğe Alma:Konak\Toplam Okuma İsteği Sayısı /sn. AppFabric Önbelleğe Alma:Konak\Toplam Yazma İşlemi Sayısı AppFabric Önbelleğe Alma:Konak\Toplam Yazma İşlemi Sayısı /sn.
Çeşitli	AppFabric Önbelleğe Alma:Konak\İsabetsiz Önbellek Okuması Yüzdesi AppFabric Önbelleğe Alma:Konak\Süresi Dolan Toplam Nesne Sayısı AppFabric Önbelleğe Alma:Konak\Toplam Teslim Edilen Bildirim Sayısı

Burada listelenen sayaçların çoğu kapasite planlama işlemine doğrudan bağlıdır. Örneğin, çeşitli bellek sayaçları vardır. “Bellek\Kullanılabilir Mbayt”, makinede ne kadar kullanılabilir fiziksel bellek kaldığını megabayt cinsinden gösterir. Bu sayaç toplam fiziksel belleğin %10'unun altına düşerse, önemli bir kısıtlama olasılığı vardır. Daha fazla bilgi için bkz. Kısıtlama Sorunlarını Giderme. Diğer sayaçlar önbelleğe alma özelliklerine özgüdür. “AppFabric Önbelleğe Alma:Konak\Toplam Çıkarma İşlemi Çalıştırma Sayısı”, bellekten hangi sıklıkta çıkarma yapıldığını gösterir. Bellek düzeyleri üst eşiği geçtiğinde bu sayaç, çıkarma işleminin bellek alt eşiğe dönünceye kadar gerçekleşeceğini gösterir. Benzer şekilde, diğer sayaçlar bu incelemenin önceki bölümlerinde yer alan kapasite planlamasına ilişkin düşünme süreciyle ilişkilidir.

DistributedCacheService hizmetinin işlem sayaçları ve makinenin İşlemci sayacının da yakalandığını göz önünde bulundurun. Yüksek işlemci kullanımı, önbellek kümesi performansını olumsuz yönde etkileyebilir. Yüksek işlemci kullanımının olduğu dönemler belirlerseniz, bunun Önbelleğe Alma hizmetiyle mi (DistributedCacheService.exe) yoksa makinedeki başka bir işlemle mi ilgili olduğunu belirlemeniz önemlidir.

Performans İzleyicisi aracının yanı sıra, AppFabric ile birlikte yüklenen Windows PowerShell komutlarını da kullanabilirsiniz. Bu komutların çoğu, Önbellek Kümesinin sistem durumunu izlemek için kullanılabilir. Daha fazla bilgi için bkz. Sistem Durumunu İzleme Araçları ve AppFabric Önbelleği'nde Günlük Tutma ve Sayaçlar.

Ayrıca bkz.

Diğer Kaynaklar

Windows Server AppFabric'i Yükleme
MSDN Windows Server AppFabric önbelleğe alma belgeleri
AppFabric önbelleğe alma Programlama Kılavuzu
ASP.NET Oturum Durumu Sağlayıcısı Yapılandırma
Önbellek kümesi yapılandırma deposu seçenekleri
Windows Server AppFabric Önbelleğe Alma Dağıtım ve Yönetim Kılavuzu
Windows Server AppFabric ve Windows Azure AppFabric Bağlantı ve Kaynakları

  2011-12-05