Kuyruk Depolama için performans ve ölçeklenebilirlik denetim listesi
Microsoft, Kuyruk Depolama ile yüksek performanslı uygulamalar geliştirmeye yönelik birçok kanıtlanmış uygulama geliştirmiştir. Bu denetim listesi, geliştiricilerin performansı iyileştirmek için izleyebilecekleri temel uygulamaları tanımlar. Uygulamanızı tasarlarken ve süreç boyunca bu uygulamaları göz önünde bulundurun.
Azure Depolama kapasite, işlem hızı ve bant genişliği için ölçeklenebilirlik ve performans hedefleri vardır. Azure Depolama ölçeklenebilirlik hedefleri hakkında daha fazla bilgi için bkz. Standart depolama hesapları için ölçeklenebilirlik ve performans hedefleri ve Kuyruk Depolama için ölçeklenebilirlik ve performans hedefleri.
Denetim listesi
Bu makalede, performans için kanıtlanmış uygulamalar, Kuyruk Depolama uygulamanızı geliştirirken izleyebileceğiniz bir denetim listesi halinde düzenlenir.
Ölçeklenebilirlik hedefleri
Uygulamanız ölçeklenebilirlik hedeflerinden herhangi birine yaklaşır veya aşarsa, işlem gecikme sürelerinin artması veya azaltma ile karşılaşabilir. Azure Depolama uygulamanızı kısıtladığında, hizmet 503 (Server Busy) veya 500 (Operation Timeout) hata kodları döndürmeye başlar. Ölçeklenebilirlik hedeflerinin sınırları içinde kalarak bu hatalardan kaçınmak, uygulamanızın performansını geliştirmenin önemli bir parçasıdır.
Kuyruk Depolama için ölçeklenebilirlik hedefleri hakkında daha fazla bilgi için bkz. Azure Depolama ölçeklenebilirlik ve performans hedefleri.
En fazla depolama hesabı sayısı
Belirli bir abonelik/bölge bileşimi için izin verilen en fazla depolama hesabı sayısına yaklaşıyorsanız, giriş, çıkış, G/Ç işlemlerini saniyede (IOPS) veya kapasiteyi artırmak için parçalama için birden çok depolama hesabı mı kullanıyorsunuz? Bu senaryoda Microsoft, mümkünse iş yükünüz için gereken depolama hesabı sayısını azaltmak için depolama hesaplarının artan sınırlarından yararlanmanızı önerir. Depolama hesabınız için daha fazla sınır istemek için Azure Desteği'ne başvurun.
Kapasite ve işlem hedefleri
Uygulamanız tek bir depolama hesabı için ölçeklenebilirlik hedeflerine yaklaşıyorsa aşağıdaki yaklaşımlardan birini benimsemeyi göz önünde bulundurun:
- Kuyruklar için ölçeklenebilirlik hedefleri uygulamanız için yetersizse, birden çok kuyruk kullanın ve iletileri bunlar arasında dağıtın.
- Uygulamanızın ölçeklenebilirlik hedefine yaklaşmasına veya aşmasına neden olan iş yükünü yeniden düşünün. Daha az bant genişliği veya kapasite ya da daha az işlem kullanmak için bunu farklı bir şekilde tasarlayabilir misiniz?
- Uygulamanızın ölçeklenebilirlik hedeflerinden birini aşması gerekiyorsa, birden çok depolama hesabı oluşturun ve uygulama verilerinizi bu birden çok depolama hesabında bölümleyin. Bu düzeni kullanıyorsanız, gelecekte yük dengeleme için daha fazla depolama hesabı ekleyebilmek için uygulamanızı tasarladığınızdan emin olun. Depolama hesapların depolanan veriler, yapılan işlemler veya aktarılan veriler açısından kullanımınızdan başka bir maliyeti yoktur.
- Uygulamanız bant genişliği hedeflerine yaklaşıyorsa verileri Azure Depolama göndermek için gereken bant genişliğini azaltmak için verileri istemci tarafında sıkıştırmayı göz önünde bulundurun. Verileri sıkıştırmak bant genişliğinden tasarruf edebilir ve ağ performansını geliştirebilir ancak performans üzerinde olumsuz etkileri de olabilir. İstemci tarafında veri sıkıştırma ve sıkıştırmayı açma için ek işleme gereksinimlerinin performans etkisini değerlendirin. Sıkıştırılmış verilerin depolanmasının, standart araçları kullanarak verileri görüntülemek daha zor olabileceğinden sorun gidermeyi daha zor hale getirebileceğini unutmayın.
- Uygulamanız ölçeklenebilirlik hedeflerine yaklaşıyorsa, yeniden denemeler için üstel geri alma kullandığınızdan emin olun. Bu makalede açıklanan önerileri uygulayarak ölçeklenebilirlik hedeflerine ulaşmayı önlemeye çalışmak en iyisidir. Ancak, yeniden denemeler için üstel geri alma kullanmak uygulamanızın hızlı bir şekilde yeniden denemesini önler ve bu da azaltmayı daha kötü hale getirir. Daha fazla bilgi için Zaman Aşımı ve Sunucu Meşgul hataları bölümüne bakın.
Ağ
Uygulamanın fiziksel ağ kısıtlamalarının performans üzerinde önemli bir etkisi olabilir. Aşağıdaki bölümlerde kullanıcıların karşılaşabileceği bazı sınırlamalar açıklanmaktadır.
İstemci ağ özelliği
Bant genişliği ve ağ bağlantısının kalitesi, aşağıdaki bölümlerde açıklandığı gibi uygulama performansında önemli roller oynar.
Aktarım hızı
Bant genişliği için sorun genellikle istemcinin özellikleridir. Daha büyük Azure örneklerinde daha fazla kapasiteye sahip NIC'ler olduğundan, tek bir makineden daha yüksek ağ sınırlarına ihtiyacınız varsa daha büyük bir örnek veya daha fazla VM kullanmayı düşünmelisiniz. Şirket içi bir uygulamadan Azure Depolama erişiyorsanız, aynı kural geçerlidir: istemci cihazının ağ özelliklerini ve Azure Depolama konumuna ağ bağlantısını anlayın ve gerektiğinde bunları geliştirin veya uygulamanızı kendi özellikleri içinde çalışacak şekilde tasarlayın.
Bağlantı kalitesi
Tüm ağ kullanımlarında olduğu gibi, hatalara ve paket kaybına neden olan ağ koşullarının etkili aktarım hızını yavaşlattığını unutmayın. Wireshark veya Ağ İzleyicisi'nin kullanılması bu sorunun tanısında yardımcı olabilir.
Konum
Herhangi bir dağıtılmış ortamda istemcinin sunucuya yakın yerleştirilmesi en iyi performansı sunar. Azure Depolama en düşük gecikme süresiyle erişmek için istemciniz için en iyi konum aynı Azure bölgesindedir. Örneğin, Azure Depolama kullanan bir Azure web uygulamanız varsa her ikisini de Batı ABD veya Güneydoğu Asya gibi tek bir bölgede bulun. Tek bir bölgedeki bant genişliği kullanımı ücretsiz olduğundan kaynakların birlikte bulunması gecikme süresini ve maliyeti azaltır.
İstemci uygulamaları Azure Depolama erişiyorsa ancak mobil cihaz uygulamaları veya şirket içi kurumsal hizmetler gibi Azure'da barındırılmadıysa depolama hesabını bu istemcilere yakın bir bölgede bulmak gecikme süresini azaltabilir. İstemcileriniz geniş ölçekte dağıtılmışsa (örneğin, bazıları Kuzey Amerika ve bazıları Avrupa'da), bölge başına bir depolama hesabı kullanmayı düşünün. Uygulamanın depodığı veriler tek tek kullanıcılara özgüyse ve depolama hesapları arasında veri çoğaltılması gerekmiyorsa bu yaklaşımı uygulamak daha kolaydır.
SAS ve CORS
Azure Depolama'daki verilere erişmek için kullanıcının web tarayıcısında veya cep telefonu uygulamasında çalışan JavaScript gibi bir kodu yetkilendirmeniz gerektiğini varsayalım. Bir yaklaşım, ara sunucu işlevi gören bir hizmet uygulaması oluşturmaktır. Kullanıcının cihazı hizmette kimlik doğrulaması yapar ve bu da Azure Depolama kaynaklarına erişim yetkisine sahip olur. Bu şekilde, depolama hesabı anahtarlarınızı güvenli olmayan cihazlarda açığa çıkarmaktan kaçınabilirsiniz. Ancak, kullanıcının cihazı ile Azure Depolama arasında aktarılan tüm verilerin hizmet uygulamasından geçmesi gerektiğinden, bu yaklaşım hizmet uygulamasına önemli bir yük getirir.
Paylaşılan erişim imzaları (SAS) kullanarak Azure Depolama için ara sunucu olarak hizmet uygulamasını kullanmaktan kaçınabilirsiniz. SAS kullanarak, sınırlı erişim belirteci kullanarak kullanıcı cihazınızın doğrudan Azure Depolama istekte bulunmasını sağlayabilirsiniz. Örneğin, bir kullanıcı uygulamanıza fotoğraf yüklemek isterse hizmet uygulamanız bir SAS oluşturabilir ve bunu kullanıcının cihazına gönderebilir. SAS belirteci, belirli bir süre boyunca bir Azure Depolama kaynağına yazma izni verebilir ve bundan sonra SAS belirtecinin süresi dolar. SAS hakkında daha fazla bilgi için bkz. Paylaşılan erişim imzalarını (SAS) kullanarak Azure Depolama kaynaklarına sınırlı erişim verme.
Genellikle, bir web tarayıcısı bir etki alanındaki web sitesi tarafından barındırılan bir sayfada JavaScript'in başka bir etki alanına yazma işlemleri gibi belirli işlemleri gerçekleştirmesine izin vermez. Aynı kaynak ilkesi olarak bilinen bu ilke, bir sayfadaki kötü amaçlı betiğin başka bir web sayfasındaki verilere erişmesini engeller. Ancak, bulutta çözüm oluştururken aynı kaynak ilkesi bir sınırlama olabilir. Çıkış noktaları arası kaynak paylaşımı (CORS), hedef etki alanının kaynak etki alanındaki isteklere güvendiği tarayıcıyla iletişim kurmasını sağlayan bir tarayıcı özelliğidir.
Örneğin, Azure'da çalışan bir web uygulamasının Azure Depolama hesabına bir kaynak isteğinde bulunadığını varsayalım. Web uygulaması kaynak etki alanı, depolama hesabı ise hedef etki alanıdır. Kaynak etki alanından gelen isteklerin Azure Depolama tarafından güvenilen web tarayıcısıyla iletişim kurması için Azure Depolama hizmetlerinden herhangi biri için CORS'yi yapılandırabilirsiniz. CORS hakkında daha fazla bilgi için bkz. Azure Depolama için çıkış noktaları arası kaynak paylaşımı (CORS) desteği.
Hem SAS hem de CORS, web uygulamanızda gereksiz yüklemelerden kaçınmanıza yardımcı olabilir.
.NET yapılandırması
.NET Framework kullanan projeler için bu bölümde, önemli performans geliştirmeleri yapmak için kullanabileceğiniz bazı hızlı yapılandırma ayarları listelenmektedir. .NET dışında bir dil kullanıyorsanız, seçtiğiniz dilde benzer kavramların geçerli olup olmadığını denetleyin.
Varsayılan bağlantı sınırını artırma
Dekont
Bağlantı havuzu ServicePointManager sınıfı tarafından denetlendiği için bu bölüm .NET Framework kullanan projeler için geçerlidir. .NET Core, bağlantı havuzu yönetimiyle ilgili önemli bir değişiklik yaptı. Burada bağlantı havuzu HttpClient düzeyinde gerçekleşir ve havuz boyutu varsayılan olarak sınırlı değildir. Bu, HTTP bağlantılarının iş yükünüzü karşılamak için otomatik olarak ölçeklendirildiğini gösterir. Performans geliştirmelerinden yararlanmak için mümkün olduğunda .NET'in en son sürümünü kullanmanız önerilir.
.NET Framework kullanan projelerde, varsayılan bağlantı sınırını (genellikle istemci ortamında 2 veya sunucu ortamında 10) 100'e yükseltmek için aşağıdaki kodu kullanabilirsiniz. Genellikle, değerini yaklaşık olarak uygulamanız tarafından kullanılan iş parçacığı sayısına ayarlamanız gerekir. Herhangi bir bağlantı açmadan önce bağlantı sınırını ayarlayın.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
.NET Framework'teki bağlantı havuzu sınırları hakkında daha fazla bilgi edinmek için bkz. .NET Framework Bağlan ion Havuzu Sınırları ve .NET için yeni Azure SDK.
Diğer programlama dilleri için bağlantı sınırının nasıl ayarlandığını belirlemek için belgelere bakın.
En az iş parçacığı sayısını artırma
Zaman uyumlu çağrıları zaman uyumsuz görevlerle birlikte kullanıyorsanız, iş parçacığı havuzundaki iş parçacığı sayısını artırmak isteyebilirsiniz:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Daha fazla bilgi için bkz . ThreadPool.SetMinThreads yöntemi.
Sınırsız paralellik
Paralellik performans için harika olsa da, iş parçacığı veya paralel istek sayısı için zorunlu bir sınır olmadığı anlamına gelen, ilişkisiz paralellik kullanma konusunda dikkatli olun. Verileri karşıya yüklemek veya indirmek, aynı depolama hesabındaki birden çok bölüme erişmek veya aynı bölümdeki birden çok öğeye erişmek için paralel istekleri sınırlandırmaya dikkat edin. Paralellik ilişkisizse uygulamanız istemci cihazının özelliklerini veya depolama hesabının ölçeklenebilirlik hedeflerini aşarak daha uzun gecikme sürelerine ve azaltmaya neden olabilir.
İstemci kitaplıkları ve araçları
En iyi performans için her zaman Microsoft tarafından sağlanan en son istemci kitaplıklarını ve araçlarını kullanın. Azure Depolama istemci kitaplıkları çeşitli diller için kullanılabilir. Azure Depolama, PowerShell ve Azure CLI'ı da destekler. Microsoft, performans göz önünde bulundurularak bu istemci kitaplıklarını ve araçlarını etkin bir şekilde geliştirir, en son hizmet sürümleriyle güncel kalmasını sağlar ve kanıtlanmış performans uygulamalarının birçoğunun dahili olarak işlenmesini sağlar. Daha fazla bilgi için Bkz. Azure Depolama başvuru belgeleri.
Hizmet hatalarını işleme
Azure Depolama, hizmet bir isteği işleyemediğinde bir hata döndürür. Belirli bir senaryoda Azure Depolama tarafından döndürülebilecek hataları anlamak performansı iyileştirmeye yardımcı olur.
Zaman aşımı ve Sunucu Meşgul hataları
Azure Depolama, ölçeklenebilirlik sınırlarına yaklaşırsa uygulamanızı kısıtlayabilir. Bazı durumlarda Azure Depolama geçici bir koşul nedeniyle bir isteği işleyemeyebilir. Her iki durumda da hizmet 503 (Server Busy) veya 500 (Timeout) hatası döndürebilir. Bu hatalar, hizmetin daha yüksek aktarım hızı sağlamak için veri bölümlerini yeniden dengelemesi durumunda da oluşabilir. İstemci uygulaması genellikle bu hatalardan birine neden olan işlemi yeniden denemelidir. Ancak Azure Depolama ölçeklenebilirlik hedeflerini aştığı için uygulamanızı daraltıyorsa veya hizmet başka bir nedenle isteğe hizmet veremese bile agresif yeniden denemeler sorunu daha da kötü hale getirebilir. Üstel geri alma yeniden deneme ilkesi kullanılması önerilir ve istemci kitaplıkları varsayılan olarak bu davranışa ayarlanır. Örneğin, uygulamanız 2 saniye, sonra 4 saniye, 10 saniye, sonra 30 saniye sonra yeniden deneyebilir ve sonra tamamen vazgeçebilir. Bu şekilde, uygulamanız hizmet üzerindeki yükünü azaltmaya yol açabilecek davranışı daha da azaltmak yerine önemli ölçüde azaltır.
Bağlan üretkenlik hataları, azaltmanın sonucu olmadığından ve geçici olması beklendiğinden hemen yeniden denenebilir.
Yeniden denenemeyen hatalar
İstemci kitaplıkları yeniden denemeleri, hangi hataların yeniden denenebileceğini ve hangilerinin denenemiyebileceğinin farkında olarak işler. Ancak Azure Depolama REST API'sini doğrudan çağırıyorsanız yeniden denememeniz gereken bazı hatalar vardır. Örneğin, 400 (Bad Request) hatası istemci uygulamasının beklenen biçimde olmadığı için işlenemeyen bir istek gönderdiğini gösterir. Bu isteği yeniden gönderme işlemi her seferinde aynı yanıta neden olduğundan yeniden denemenin bir anlamı yoktur. Azure Depolama REST API'sini doğrudan çağırıyorsanız olası hataları ve bunların yeniden denenip denenmeyeceğini unutmayın.
Azure Depolama hata kodları hakkında daha fazla bilgi için bkz. Durum ve hata kodları.
Nagle algoritmasını devre dışı bırakma
Nagle algoritması, ağ performansını iyileştirmenin bir aracı olarak TCP/IP ağları arasında yaygın olarak uygulanır. Ancak, her koşulda (yüksek oranda etkileşimli ortamlar gibi) en uygun seçenek değildir. Nagle algoritması, Azure Tablo Depolama isteklerin performansını olumsuz etkiler ve mümkünse devre dışı bırakmalısınız.
İleti boyutu
İleti boyutu arttıkça kuyruk performansı ve ölçeklenebilirlik azalır. İletiye yalnızca alıcının ihtiyaç duyduğu bilgileri yerleştirin.
Toplu alma
Bir kuyruktan tek bir işlemde en fazla 32 ileti alabilirsiniz. Toplu alma, istemci uygulamasından gidiş dönüş sayısını azaltabilir. Bu, özellikle mobil cihazlar gibi yüksek gecikme süresine sahip ortamlar için kullanışlıdır.
Kuyruk yoklama aralığı
Çoğu uygulama, bir kuyruktan gelen iletileri yoklar ve bu da bu uygulama için en büyük işlem kaynaklarından biri olabilir. Yoklama aralığınızı akıllıca seçin: çok sık yoklama yapmak uygulamanızın kuyruk için ölçeklenebilirlik hedeflerine yaklaşmasına neden olabilir. Ancak, 0,01 ABD doları karşılığında 200.000 işlemde (yazma sırasında), bir ay boyunca saniyede bir yapılan tek bir işlemci yoklaması 15 sentten daha düşük bir maliyete mal olur, bu nedenle maliyet genellikle yoklama aralığı seçiminizi etkileyen bir faktör değildir.
Güncel maliyet bilgileri için bkz. Azure Depolama fiyatlandırması.
Güncelleştirme iletisi işlemi gerçekleştirme
Görünmezlik zaman aşımını artırmak veya iletinin durum bilgilerini güncelleştirmek için bir güncelleştirme iletisi işlemi gerçekleştirebilirsiniz. Bu yaklaşım, işin her adımı tamamlandıktan sonra bir işi bir kuyruktan diğerine geçiren bir iş akışına sahip olmaktan daha verimli olabilir. Uygulamanız, bir adım her tamamlandığında işin sonraki adımı için iletiyi yeniden sorgulamak yerine iş durumunu iletiye kaydedebilir ve çalışmaya devam edebilir. Her güncelleştirme iletisi işleminin ölçeklenebilirlik hedefine doğru sayıldığını unutmayın.
Uygulama mimarisi
Uygulama mimarinizi ölçeklenebilir hale getirmek için kuyrukları kullanın. Aşağıda, uygulamanızı daha ölçeklenebilir hale getirmek için kuyrukları kullanmanın bazı yolları listelenir:
- Kuyrukları kullanarak uygulamanızdaki iş yüklerini işlemek ve sorunsuz hale getirmek için iş kapsamları oluşturabilirsiniz. Örneğin, karşıya yüklenen görüntüleri yeniden boyutlandırma gibi yoğun işlemci kullanan işleri gerçekleştirmek için kullanıcılardan gelen istekleri kuyruğa ekleyebilirsiniz.
- Kuyrukları kullanarak uygulamanızın bölümlerini birbirinden bağımsız olarak ölçeklendirin. Örneğin, bir web ön ucu daha sonra analiz ve depolama için kullanıcılardan gelen anket sonuçlarını kuyruğa alabilir. Kuyruk verilerini gerektiği gibi işlemek için daha fazla çalışan rolü örneği ekleyebilirsiniz.