Blob depolama için performans ve ölçeklenebilirlik denetim listesi

Microsoft, Blob depolama ile yüksek performanslı uygulamalar geliştirmek için kanıtlanmış bir dizi uygulama geliştirmiştir. Bu denetim listesi, geliştiricilerin performansı iyileştirmek için izleyebilecekleri önemli 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 hedeflerine sahiptir. Azure Depolama ölçeklenebilirlik hedefleri hakkında daha fazla bilgi için bkz. Standart depolama hesapları için ölçeklenebilirlik ve performans hedefleri ve Blob depolama için ölçeklenebilirlik ve performans hedefleri.

Denetim Listesi

Bu makalede, performans için kanıtlanmış uygulamalar, Blob depolama uygulamanızı geliştirirken izleyebileceğiniz bir denetim listesi halinde düzenlenir.

Bitti Kategori Tasarımda dikkat edilmesi gerekenler
  Ölçeklenebilirlik hedefleri Uygulamanızı en fazla depolama hesabı sayısı kullanacak şekilde tasarlayabilir misiniz?
  Ölçeklenebilirlik hedefleri Kapasiteye ve işlem sınırlarına yaklaşmaktan kaçınıyor musunuz?
  Ölçeklenebilirlik hedefleri Aynı anda tek bir bloba erişen çok sayıda istemci mi var?
  Ölçeklenebilirlik hedefleri Uygulamanız tek bir blob için ölçeklenebilirlik hedeflerinin içinde mi kalıyor?
  Bölümleme Adlandırma kuralınız daha iyi yük dengeleme sağlayacak şekilde mi tasarlandı?
  İstemci tarafı cihazlar, gereken performansı elde etmek için yeterince yüksek bant genişliğine ve düşük gecikme süresine sahip mi?
  İstemci tarafı cihazların yüksek kaliteli ağ bağlantısı var mı?
  İstemci uygulaması depolama hesabıyla aynı bölgede mi?
  Doğrudan istemci erişimi Azure Depolama'ya doğrudan erişimi etkinleştirmek için paylaşılan erişim imzaları (SAS) ve çıkış noktaları arası kaynak paylaşımı (CORS) kullanıyor musunuz?
  Önbelleğe Alma Uygulamanız sık erişilen ve nadiren değiştirilen verileri önbelleğe mi kullanıyor?
  Önbelleğe Alma Uygulamanız güncelleştirmeleri istemcide önbelleğe alıp daha büyük kümelerde karşıya yükleyerek toplu olarak mı yüklüyor?
  .NET yapılandırması En iyi performans için .NET Core 2.1 veya sonraki bir sürümü mü kullanıyorsunuz?
  .NET yapılandırması İstemcinizi yeterli sayıda eşzamanlı bağlantı kullanacak şekilde yapılandırmış mıydınız?
  .NET yapılandırması .NET uygulamaları için, .NET'i yeterli sayıda iş parçacığı kullanacak şekilde yapılandırmış mıydınız?
  Parallelism Paralelliğin uygun şekilde sınırlandığından emin olup istemcinizin özelliklerini aşırı yüklemediğinizden veya ölçeklenebilirlik hedeflerine yaklaşmadığınızdan emin misiniz?
  Araçlar Microsoft tarafından sağlanan istemci kitaplıklarının ve araçlarının en son sürümlerini mi kullanıyorsunuz?
  Yeniden deneme sayısı Azaltma hataları ve zaman aşımları için üstel geri alma ile yeniden deneme ilkesi mi kullanıyorsunuz?
  Yeniden deneme sayısı Uygulamanız yeniden denenemeyen hatalar için yeniden denemelerden kaçınıyor mu?
  Blobları kopyalama Blobları en verimli şekilde mi kopyalayabilirsiniz?
  Blobları kopyalama Toplu kopyalama işlemleri için AzCopy'nin en son sürümünü mü kullanıyorsunuz?
  Blobları kopyalama Büyük hacimli verileri içeri aktarmak için Azure Data Box ailesini mi kullanıyorsunuz?
  İçerik dağıtımı İçerik dağıtımı için CDN mi kullanıyorsunuz?
  Meta verileri kullanma Bloblar hakkında sık kullanılan meta verileri meta verilerinde depoluyor musunuz?
  Performans ayarlama Veri aktarımı performansını iyileştirmek için istemci kitaplığı seçeneklerini proaktif olarak mı ayarlacaksınız?
  Hızlı bir şekilde karşıya yükleme Bir blobu hızla karşıya yüklemeye çalışırken blokları paralel olarak mı karşıya yüklüyorsunuz?
  Hızlı bir şekilde karşıya yükleme Çok sayıda blobu hızla karşıya yüklemeye çalışırken blobları paralel olarak mı karşıya yüklüyorsunuz?
  Blob türü Uygun olduğunda sayfa blobları mı yoksa blok blobları mı kullanıyorsunuz?

Ö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 (Sunucu meşgul) veya 500 (İşlem zaman aşımı) hata kodları döndürmeye başlar. Ölçeklenebilirlik hedefleri sınırları içinde kalarak bu hatalardan kaçınmak, uygulamanızın performansını geliştirmenin önemli bir parçasıdır.

Kuyruk hizmeti 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 depolama hesabı sayısı üst sınırına yaklaşıyorsanız senaryonuzu değerlendirin ve aşağıdaki koşullardan herhangi birinin geçerli olup olmadığını belirleyin:

  • Yönetilmeyen diskleri depolamak ve bu diskleri sanal makinelerinize (VM) eklemek için depolama hesaplarını mı kullanıyorsunuz? Bu senaryoda, Microsoft yönetilen disklerin kullanılmasını önerir. Yönetilen diskler sizin için otomatik olarak ve tek tek depolama hesapları oluşturmanıza ve yönetmenize gerek kalmadan ölçeklendirilir. Daha fazla bilgi için bkz . Azure yönetilen disklerine giriş
  • Veri yalıtımı amacıyla müşteri başına bir depolama hesabı mı kullanıyorsunuz? Bu senaryoda Microsoft, depolama hesabının tamamı yerine her müşteri için bir blob kapsayıcısı kullanılmasını önerir. Azure Depolama artık Azure rollerini kapsayıcı başına atamanıza olanak tanır. Daha fazla bilgi için bkz. Blob verilerine erişmek için Azure rolü atama.
  • Saniye başına giriş, çıkış, G/Ç işlemlerini (IOPS) veya kapasiteyi artırmak için parçalama yapmak 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. Daha fazla bilgi için bkz. Daha büyük, daha yüksek ölçekli depolama hesaplarını duyurma.

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:

  • Uygulamanız işlem hedefini belirlerse, yüksek işlem hızları ve düşük ve tutarlı gecikme süresi için iyileştirilmiş blok blobu depolama hesaplarını kullanmayı göz önünde bulundurun. Daha fazla bilgi için bkz. Azure depolama hesabına genel bakış.
  • 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 farklı bir tasarım yapabilir 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ın depolanmış 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'ya 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 sağlar ve ağ performansını iyileştirirken performans üzerinde olumsuz etkilere de neden 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 zorlaştırabileceğini unutmayın.
  • Uygulamanız ölçeklenebilirlik hedeflerine yaklaşıyorsa, yeniden denemeler için üstel geri çekilme kullandığınızdan emin olun. Bu makalede açıklanan önerileri uygulayarak ölçeklenebilirlik hedeflerine ulaşmaktan kaçınmaya çalışmak en iyisidir. Ancak, yeniden denemeler için üstel geri çekilme kullanılması uygulamanızın hızlı bir şekilde yeniden denemesini engeller ve bu da azaltmayı daha da kötü hale getirir. Daha fazla bilgi için Zaman Aşımı ve Sunucu Meşgul hataları başlıklı bölüme bakın.

Tek bir bloba eşzamanlı olarak erişen birden çok istemci

Aynı anda tek bir bloba erişen çok sayıda istemciniz varsa hem blob başına hem de depolama hesabı başına ölçeklenebilirlik hedeflerini göz önünde bulundurmanız gerekir. Tek bir bloba erişebilen istemcilerin tam sayısı, blobu aynı anda isteyen istemcilerin sayısı, blobun boyutu ve ağ koşulları gibi faktörlere bağlı olarak değişir.

Blob, bir web sitesinden sunulan görüntüler veya videolar gibi bir CDN aracılığıyla dağıtılabiliyorsa CDN kullanabilirsiniz. Daha fazla bilgi için İçerik dağıtımı başlıklı bölüme bakın.

Verilerin gizli olduğu bilimsel simülasyonlar gibi diğer senaryolarda iki seçeneğiniz vardır. Birincisi, iş yükünüzün erişimini kademelendirmek ve bloba bir süre içinde erişilme ve aynı anda erişilme şeklindedir. Alternatif olarak blob başına ve depolama hesapları arasında toplam IOPS sayısını artırmak için blobu geçici olarak birden çok depolama hesabına kopyalayabilirsiniz. Sonuçlar uygulamanızın davranışına bağlı olarak değişir, bu nedenle tasarım sırasında eşzamanlılık desenlerini test edin.

Blob başına bant genişliği ve işlemler

Tek bir blob saniyede en fazla 500 isteği destekler. Aynı blobu okuması gereken birden çok istemciniz varsa ve bu sınırı aşabiliyorsanız blok blobu depolama hesabı kullanmayı göz önünde bulundurun. Blok blob depolama hesabı daha yüksek bir istek oranı veya saniyede G/Ç işlemleri (IOPS) sağlar.

Blob üzerindeki işlemleri dağıtmak için Azure CDN gibi bir içerik teslim ağı (CDN) de kullanabilirsiniz. Azure CDN hakkında daha fazla bilgi için bkz. Azure CDN'ye genel bakış.

Bölümleme

Azure Depolama'nın blob verilerinizi nasıl bölümlere ayırıyor olduğunu anlamak, performansı artırmak için yararlıdır. Azure Depolama, tek bir bölümdeki verileri birden çok bölüme yayılan verilerden daha hızlı bir şekilde sunabilir. Bloblarınızı uygun şekilde adlandırarak okuma isteklerinin verimliliğini artırabilirsiniz.

Blob depolama, ölçeklendirme ve yük dengeleme için aralık tabanlı bir bölümleme şeması kullanır. Her blobun tam blob adından (account+container+blob) oluşan bir bölüm anahtarı vardır. Bölüm anahtarı blob verilerini aralıklara bölmek için kullanılır. Aralıklar daha sonra Blob depolamada yük dengelemesi yapılır.

Aralık tabanlı bölümleme, sözcük temelli sıralama kullanan adlandırma kurallarının (örneğin, mypayroll, myperformance, myemployees vb.) veya zaman damgaları (log20160101, log20160102, log20160102, vb.), artan yük daha küçük aralıklara bölünmelerini gerektirene kadar bölümlerin aynı bölüm sunucusunda birlikte bulunmasına neden olabilir. Blobların aynı bölüm sunucusunda birlikte bulunması performansı artırır, bu nedenle performans geliştirmesinin önemli bir parçası blobları en etkili şekilde düzenleyecek şekilde adlandırmayı içerir.

Örneğin, kapsayıcı içindeki tüm bloblar, bu bloblardaki yük bölüm aralıklarının daha fazla yeniden dengelenmesi gerekene kadar tek bir sunucu tarafından kullanılabilir. Benzer şekilde, adları sözcük düzeninde düzenlenmiş hafifçe yüklenmiş hesaplardan oluşan bir grup, bu hesaplardan birinin veya tümünün yükü birden çok bölüm sunucusuna bölünmesini gerektirene kadar tek bir sunucu tarafından hizmet verebilir.

Her yük dengeleme işlemi, işlem sırasında depolama çağrılarının gecikme süresini etkileyebilir. Yük dengeleme işlemi devreye girip bölüm anahtarı aralığını yeniden dengeleyene kadar hizmetin bir bölüme yönelik ani trafik artışını işleme özelliği tek bir bölüm sunucusunun ölçeklenebilirliğiyle sınırlıdır.

Bu tür işlemlerin sıklığını azaltmak için bazı en iyi yöntemleri izleyebilirsiniz.

  • Mümkünse standart ve premium depolama hesapları için 256 KiB'den büyük blob veya blok boyutlarını kullanın. Büyük blob veya blok boyutları yüksek aktarım hızına sahip blok bloblarını otomatik olarak etkinleştirir. Yüksek aktarım hızına sahip blok blobları, bölüm adlandırmadan etkilenmeyen yüksek performanslı alma sağlar.

  • Hesaplar, kapsayıcılar, bloblar, tablolar ve kuyruklar için kullandığınız adlandırma kuralını inceleyin. Gereksinimlerinize en uygun karma işlevini kullanarak hesap, kapsayıcı veya blob adlarını üç basamaklı karma ile önek olarak eklemeyi göz önünde bulundurun.

  • Verilerinizi zaman damgaları veya sayısal tanımlayıcılar kullanarak düzenlerseniz, yalnızca ekleme (veya yalnızca ekleme) trafik deseni kullanmadığınızdan emin olun. Bu desenler aralık tabanlı bölümleme sistemi için uygun değildir. Bu desenler tüm trafiğin tek bir bölüme çıkmasına ve sistemin etkili yük dengelemesini sınırlamasına neden olabilir.

    Örneğin, yymmdd gibi bir zaman damgasına sahip bir blob kullanan günlük işlemleriniz varsa, bu günlük işlemin tüm trafiği tek bir bölüm sunucusu tarafından sunulan tek bir bloba yönlendirilir. Blob başına sınırların ve bölüm başına sınırların gereksinimlerinizi karşılayıp karşılamadığını ve gerekirse bu işlemi birden çok bloba bölmeyi göz önünde bulundurun. Benzer şekilde, zaman serisi verilerini tablolarınızda depolarsanız tüm trafik anahtar ad alanının son bölümüne yönlendirilebilir. Sayısal kimlikler kullanıyorsanız, kimliğin önüne üç basamaklı bir karma ekleyin. Zaman damgaları kullanıyorsanız, zaman damgasına ssymmdd gibi saniye değerini ön ek olarak girin. Uygulamanız düzenli olarak listeleme ve sorgulama işlemleri gerçekleştiriyorsa, sorgu sayısını sınırlayacak bir karma işlevi seçin. Bazı durumlarda rastgele bir ön ek yeterli olabilir.

  • Azure Depolama'da kullanılan bölümleme düzeni hakkında daha fazla bilgi için bkz . Azure Depolama: Güçlü Tutarlılığa Sahip Yüksek Oranda Kullanılabilir Bir Bulut Depolama Hizmeti.

Uygulamanın fiziksel ağ kısıtlamaları performans üzerinde önemli bir etkiye sahip 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ı göz önünde bulundurmalısınız. Azure Depolama'ya şirket içi bir uygulamadan 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.

Tüm ağ kullanımlarında olduğu gibi, hatalara ve paket kaybına neden olan ağ koşullarının etkin aktarım hızını yavaşlatacağını unutmayın. WireShark veya NetMon kullanmak bu sorunun tanısında yardımcı olabilir.

Konum

Herhangi bir dağıtılmış ortamda istemcinin sunucuya yakın bir şekilde yerleştirilmesi en iyi performansı sunar. Azure Depolama'ya en düşük gecikme süresiyle erişmek için istemciniz için en iyi konum aynı Azure bölgesinde yer alır. Örneğin, Azure Depolama kullanan bir Azure web uygulamanız varsa, her ikisini de ABD Batı 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'ya erişecekse 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ılıyorsa (örneğin, bazıları Kuzey Amerika ve bazıları Avrupa'da) bölge başına bir depolama hesabı kullanmayı göz önünde bulundurun. Uygulamanın depodığı veriler tek tek kullanıcılara özgüyse ve depolama hesapları arasında verilerin çoğaltılması gerekmediyse bu yaklaşımı uygulamak daha kolaydır.

Blob içeriğinin geniş bir dağıtımı için Azure CDN gibi bir içerik teslim ağı kullanın. Azure CDN hakkında daha fazla bilgi için bkz. Azure CDN.

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ı hizmetle kimlik doğrulaması yapar ve bu da Azure Depolama kaynaklarına erişim yetkisine sahip olur. Bu şekilde, güvenli olmayan cihazlarda depolama hesabı anahtarlarınızı 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ını (SAS) kullanarak Azure Depolama için bir hizmet uygulamasını ara sunucu olarak kullanmaktan kaçınabilirsiniz. SAS kullanarak, kullanıcınızın cihazının sınırlı erişim belirteci kullanarak doğrudan Azure Depolama'ya istek göndermesini 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 bir 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ı bir betiğin başka bir web sayfasındaki verilere erişim elde etmesini 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 Bir Azure Depolama hesabına kaynak isteğinde bulunarak bunu yaptığı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ükten kaçınmanıza yardımcı olabilir.

Önbelleğe Alma

Önbelleğe alma, performansta önemli bir rol oynar. Aşağıdaki bölümlerde önbelleğe alma en iyi yöntemleri açıklanmıştır.

Verileri okuma

Genel olarak, verileri bir kez okumak, iki kez okumak için tercih edilir. Kullanıcıya içerik olarak hizmet vermek için Azure Depolama'dan 50 MiB blob alan bir web uygulaması örneğini düşünün. İdeal olan, uygulamanın blobu yerel olarak diske önbelleğe alması ve ardından sonraki kullanıcı istekleri için önbelleğe alınmış sürümü almasıdır.

Önbelleğe alındıktan sonra değiştirilmemiş bir blobu almayı önlemenin bir yolu, GET işlemini değiştirme süresi için koşullu bir üst bilgiyle nitelemektir. Son değiştirme zamanı blob önbelleğe alındıktan sonraysa blob alınır ve yeniden önbelleğe alınır. Aksi takdirde, önbelleğe alınan blob en iyi performans için alınır.

Ayrıca uygulamanızı, blobu aldıktan sonra kısa bir süre boyunca değişmeden kaldığını varsayacak şekilde tasarlamaya karar vekleyebilirsiniz. Bu durumda uygulamanın blobu bu aralıkta değiştirip değiştirmediğini denetlemesi gerekmez.

Yapılandırma verileri, arama verileri ve uygulama tarafından sık kullanılan diğer veriler önbelleğe almak için iyi adaylardır.

Koşullu üst bilgileri kullanma hakkında daha fazla bilgi için bkz. Blob hizmeti işlemleri için koşullu üst bilgileri belirtme.

Verileri toplu olarak karşıya yükleme

Bazı senaryolarda verileri yerel olarak toplayabilir ve her bir veri parçasını hemen yüklemek yerine düzenli aralıklarla toplu olarak yükleyebilirsiniz. Örneğin, bir web uygulamasının etkinliklerin günlük dosyasını tuttuğunu varsayalım. Uygulama, her etkinliğin ayrıntılarını bir tabloya (birçok depolama işlemi gerektirir) olduğu gibi karşıya yükleyebilir veya etkinlik ayrıntılarını yerel bir günlük dosyasına kaydedebilir ve ardından düzenli aralıklarla tüm etkinlik ayrıntılarını sınırlandırılmış bir dosya olarak bloba yükleyebilir. Her günlük girdisinin boyutu 1 KB ise, tek bir işlemde binlerce girdiyi karşıya yükleyebilirsiniz. Tek bir işlem, boyutu 64 MiB'a kadar olan bir blobun karşıya yüklenmesini destekler. Uygulama geliştiricisi, istemci cihazı veya karşıya yükleme hatası olasılığı için tasarım yapmalıdır. Etkinlik verilerinin tek bir etkinlik yerine belirli bir süre boyunca indirilmesi gerekiyorsa, Tablo depolama üzerinden Blob depolama kullanılması önerilir.

.NET yapılandırması

.NET Framework kullanıyorsanız, bu bölümde önemli performans geliştirmeleri yapmak için kullanabileceğiniz çeşitli hızlı yapılandırma ayarları listelenir. Başka diller kullanıyorsanız, seçtiğiniz dilde benzer kavramların geçerli olup olmadığını denetleyin.

.NET Core kullanma

Performans geliştirmelerinden yararlanmak için .NET Core 2.1 veya üzeri ile Azure Depolama uygulamalarınızı geliştirin. Mümkün olduğunda .NET Core 3.x kullanılması önerilir.

.NET Core'daki performans geliştirmeleri hakkında daha fazla bilgi için aşağıdaki blog gönderilerine bakın:

Varsayılan bağlantı sınırını artırma

.NET'te, aşağıdaki kod varsayılan bağlantı sınırını (genellikle bir istemci ortamında iki veya sunucu ortamında ondur) 100'e yükseltir. Genellikle, değeri yaklaşık olarak uygulamanız tarafından kullanılan iş parçacığı sayısına ayarlamanız gerekir. Bağlantıları açmadan önce bağlantı sınırını ayarlayın.

ServicePointManager.DefaultConnectionLimit = 100; //(Or More)  

Diğer programlama dilleri için bağlantı sınırının nasıl ayarlandığını belirlemek için belgelere bakın.

Daha fazla bilgi için Web Hizmetleri: Eşzamanlı Bağlantılar blog gönderisine bakın.

Minimum 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, ilişkisiz paralellik kullanmaya dikkat edin; başka bir deyişle iş parçacığı veya paralel istek sayısında bir sınır uygulanmaz. 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ırmayı unutmayın. 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 dillerde kullanılabilir. Azure Depolama, PowerShell ve Azure CLI'yı da destekler. Microsoft, performans göz önünde bulundurularak bu istemci kitaplıklarını ve araçlarını etkin bir şekilde geliştirir, bunları en son hizmet sürümleriyle güncel tutar ve kanıtlanmış performans uygulamalarının birçoğunun dahili olarak işlenmesini sağlar.

İpucu

ABFS sürücüsü WASB'nin doğal eksikliklerinin üstesinden gelmek için tasarlanmıştır. ABFS sürücüsü özellikle büyük veri analizi için iyileştirildiğinden Microsoft, WASB sürücüsü üzerinden ABFS sürücüsünün kullanılmasını önerir.

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ıtlar. Bazı durumlarda Azure Depolama geçici bir koşul nedeniyle isteği işleyemeyebilir. Her iki durumda da hizmet 503 (Sunucu Meşgul) veya 500 (Zaman Aşımı) hatası döndürebilir. Bu hatalar, hizmet daha yüksek aktarım hızı sağlamak için veri bölümlerini yeniden dengeliyorsa 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ı kısıtlıyorsa veya hizmet başka bir nedenle isteğe hizmet edemediyse 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ışı kullanır. Örneğin, uygulamanız 2 saniye, sonra 4 saniye, 10 saniye, sonra 30 saniye sonra yeniden deneyebilir ve ardından tamamen vazgeçebilir. Bu şekilde uygulamanız, azaltmaya yol açabilecek davranışları şiddetlendirmek yerine hizmet üzerindeki yükünü önemli ölçüde azaltır.

Bağlantı 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 yeniden denenemeyeceğinin farkında olarak işler. Ancak Azure Depolama REST API'sini doğrudan çağırıyorsanız yeniden denememenizi gerektiren bazı hatalar vardır. Örneğin, 400 (Hatalı İstek) hatası, istemci uygulamasının beklenen biçimde olmadığından işlenemeyen bir istek gönderdiğini gösterir. Bu isteğin yeniden gönderilmesi her seferinde aynı yanıtla sonuçlanır, bu nedenle 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ı.

Blobları kopyalama ve taşıma

Azure Depolama bir depolama hesabı içinde, depolama hesapları arasında ve şirket içi sistemler ile bulut arasında blobları kopyalamaya ve taşımaya yönelik bir dizi çözüm sağlar. Bu bölümde, performans üzerindeki etkileri açısından bu seçeneklerden bazıları açıklanmaktadır. Blob depolamaya veya Blob depolamadan verimli bir şekilde veri aktarma hakkında bilgi için bkz. Veri aktarımı için azure çözümü seçme.

Blob kopyalama API'leri

Blobları depolama hesapları arasında kopyalamak için URL'den Blok Koy işlemini kullanın. Bu işlem verileri herhangi bir URL kaynağından blok blobuna zaman uyumlu olarak kopyalar. İşlemin Put Block from URL kullanılması, verileri depolama hesapları arasında geçirirken gerekli bant genişliğini önemli ölçüde azaltabilir. Kopyalama işlemi hizmet tarafında gerçekleştiğinden, verileri indirip yeniden yüklemeniz gerekmez.

Aynı depolama hesabındaki verileri kopyalamak için Blobu Kopyala işlemini kullanın. Aynı depolama hesabı içindeki verileri kopyalama işlemi genellikle hızlı bir şekilde tamamlanır.

AzCopy’yi kullanma

AzCopy komut satırı yardımcı programı, blobların depolama hesaplarına, buradan ve farklı depolama hesaplarına toplu olarak aktarılması için basit ve verimli bir seçenektir. AzCopy bu senaryo için iyileştirilmiştir ve yüksek aktarım hızları elde edebilir. AzCopy sürüm 10, blob verilerini depolama hesapları arasında kopyalamak için işlemini kullanır Put Block From URL . Daha fazla bilgi için bkz. AzCopy v10 kullanarak verileri Azure Depolama'ya kopyalama veya taşıma.

Azure Data Box kullanma

Büyük hacimli verileri Blob depolamaya aktarmak için çevrimdışı aktarımlar için Azure Data Box ailesini kullanmayı göz önünde bulundurun. Microsoft tarafından sağlanan Data Box cihazları, zaman, ağ kullanılabilirliği veya maliyetlerle sınırlı olduğunuzda büyük miktarda veriyi Azure'a taşımak için iyi bir seçimdir. Daha fazla bilgi için bkz. Azure DataBox Belgeleri.

İçerik dağıtımı

Bazen bir uygulamanın aynı veya birden çok bölgede bulunan birçok kullanıcıya (örneğin, bir web sitesinin giriş sayfasında kullanılan bir ürün tanıtım videosu) aynı içeriği sunması gerekir. Bu senaryoda, blob içeriğini coğrafi olarak dağıtmak için Azure CDN gibi bir Content Delivery Network (CDN) kullanın. Tek bir bölgede bulunan ve diğer bölgelere düşük gecikme süresiyle içerik teslim emeyen bir Azure Depolama hesabından farklı olarak, Azure CDN dünyanın dört bir yanındaki birden çok veri merkezinde bulunan sunucuları kullanır. Buna ek olarak, CDN genellikle tek bir depolama hesabından çok daha yüksek çıkış sınırlarını destekleyebilir.

Azure CDN hakkında daha fazla bilgi için bkz. Azure CDN.

Meta verileri kullanma

Blob hizmeti, blob özelliklerini veya meta verileri içerebilen HEAD isteklerini destekler. Örneğin, uygulamanızın bir fotoğraftan Exif (değiştirilebilir görüntü biçimi) verilerine ihtiyacı varsa, fotoğrafı alabilir ve ayıklayabilir. Bant genişliğinden tasarruf etmek ve performansı artırmak için uygulamanız fotoğrafı karşıya yüklediğinde Exif verilerini blob'un meta verilerinde depolayabilir. Daha sonra yalnızca bir HEAD isteği kullanarak meta verilerdeki Exif verilerini alabilirsiniz. Blobun tam içeriğinin değil yalnızca meta verilerin alınması önemli bir bant genişliği tasarrufu sağlar ve Exif verilerini ayıklamak için gereken işlem süresini azaltır. Blob başına 8 KiB meta veri depolanabileceğini unutmayın.

Veri aktarımları için performans ayarlama

Bir uygulama Azure Depolama istemci kitaplığını kullanarak veri aktardığında hızı, bellek kullanımını ve hatta isteğin başarısını veya başarısızlığını etkileyebilecek çeşitli faktörler vardır. Veri aktarımlarında performansı ve güvenilirliği en üst düzeye çıkarmak için, uygulamanızın çalıştırılacağı ortama göre istemci kitaplığı aktarım seçeneklerini yapılandırmada proaktif olmak önemlidir. Daha fazla bilgi edinmek için bkz. Karşıya yüklemeler ve indirmeler için performans ayarlama.

Blobları hızla karşıya yükleme

Blobları hızlı bir şekilde karşıya yüklemek için önce bir blob mu yoksa çok mu yükleneceğini belirleyin. Senaryonuza bağlı olarak kullanılacak doğru yöntemi belirlemek için aşağıdaki kılavuzu kullanın. Veri aktarımları için Azure Depolama istemci kitaplığını kullanıyorsanız daha fazla rehberlik için bkz. Veri aktarımları için performans ayarlama .

Büyük bir blobu hızla karşıya yükleme

Tek bir büyük blobu hızla karşıya yüklemek için istemci uygulaması bloklarını veya sayfalarını paralel olarak karşıya yükleyebilir ve tek tek bloblar için ölçeklenebilirlik hedeflerine ve bir bütün olarak depolama hesabına dikkat edebilir. Azure Depolama istemci kitaplıkları paralel olarak karşıya yüklemeyi destekler. Desteklenen diğer diller için istemci kitaplıkları benzer seçenekler sağlar.

Çok sayıda blobu hızla karşıya yükleme

Çok sayıda blobu hızla yüklemek için blobları paralel olarak karşıya yükleyin. Paralel olarak karşıya yükleme, tek blobları paralel blok karşıya yüklemeleri ile aynı anda karşıya yüklemekten daha hızlıdır çünkü karşıya yükleme işlemi depolama hizmetinin birden çok bölümüne yayılır. AzCopy, yüklemeleri varsayılan olarak paralel olarak gerçekleştirir ve bu senaryo için önerilir. Daha fazla bilgi için bkz. AzCopy'yi kullanmaya başlama.

Doğru blob türünü seçme

Azure Depolama blok bloblarını, ekleme bloblarını ve sayfa bloblarını destekler. Belirli bir kullanım senaryosunda blob türü seçiminiz çözümünüzün performansını ve ölçeklenebilirliğini etkiler.

Büyük miktarda veriyi verimli bir şekilde karşıya yüklemek istediğinizde blok blobları uygundur. Örneğin, Blob depolamaya fotoğraf veya video yükleyen bir istemci uygulaması blok bloblarını hedeflemektedir.

Ekleme blobları, bloklardan oluşan blok bloblarına benzer. Ekleme blobunu değiştirdiğinizde bloklar yalnızca blobun sonuna eklenir. Ekleme blobları, bir uygulamanın mevcut bloba veri eklemesi gerektiğinde günlüğe kaydetme gibi senaryolar için kullanışlıdır.

Uygulamanın veriler üzerinde rastgele yazma işlemleri gerçekleştirmesi gerekiyorsa sayfa blobları uygundur. Örneğin, Azure sanal makine diskleri sayfa blobları olarak depolanır. Daha fazla bilgi için bkz. Blok bloblarını, ekleme bloblarını ve sayfa bloblarını anlama.

Sonraki adımlar