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

Microsoft, Blob depolama ile yüksek performanslı uygulamalar geliştirmeye yönelik bir dizi 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 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ış yöntemler, Blob 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 bunları 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 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 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 en fazla depolama hesabı sayısı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ı mı kullanıyorsunuz? Bu senaryo için Microsoft yönetilen disklerin kullanılmasını önerir. Yönetilen diskler, tek tek depolama hesaplarını oluşturmanıza ve yönetmenize gerek kalmadan sizin için otomatik olarak ö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 senaryo için 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.
• 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:

• Uygulamanız işlem hedefini vurursa, 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 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ı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 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ı başlıklı bölüme bakın.

Aynı anda tek bir bloba 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şebilecek 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. İlki, iş yükünüzün erişimini, bloba bir süre içinde erişilene ve aynı anda erişilene kadar kademelendirmektir. 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şabilirseniz blok blob 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 üzerinde 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ı geliştirmek 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 hizmet verebilir. 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 düzeni 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. Daha sonra aralıklar Blob depolama genelinde 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ı etkiler, bu nedenle performans geliştirmesinin önemli bir parçası blobları en etkili şekilde düzenleyecek şekilde adlandırmayı içerir.

Örneğin, bir kapsayıcı içindeki tüm bloblar, bu bloblardaki yük bölüm aralıklarının daha fazla yeniden dengelenmesine gerek duyana kadar tek bir sunucu tarafından kullanılabilir. Benzer şekilde, adları sözcük düzeninde düzenlenmiş hafif yüklü bir hesap grubu, bu hesaplardan birinin veya tümünün yükü birden çok bölüm sunucusu arasında bölünmesini gerektirene kadar tek bir sunucu tarafından sunulabilir.

Her yük dengeleme işlemi, işlem sırasında depolama çağrılarının gecikme süresini etkileyebilir. Hizmetin bir bölüme yönelik ani trafik artışını işleme özelliği, yük dengeleme işlemi başlatılıp bölüm anahtarı aralığını yeniden dengeleyene kadar 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 etkilenmemiş yüksek performanslı alma sağlar.

• Hesaplar, kapsayıcılar, bloblar, tablolar ve kuyruklar için kullandığınız adlandırma kuralını inceleyin. İhtiyaçlarınıza en uygun karma işlevini kullanarak hesap, kapsayıcı veya blob adlarına üç basamaklı karma ile ön ek uygulamayı 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 etkin 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 sorgularınızın sayısını sınırlayan 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ık ile Yüksek Oranda Kullanılabilir Bir Bulut Depolama Hizmeti.

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'ya 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 NetMon kullanmak 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'ya 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 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ş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.

Blob içeriğinin geniş 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ı hizmette kimlik doğrulaması yapar ve bu da Azure Depolama kaynaklarına erişim yetkisi sağlar. 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ını (SAS) kullanarak Azure Depolama için bir hizmet uygulamasını ara sunucu olarak kullanmaktan kaçınabilirsiniz. SAS kullanarak, sınırlı erişim belirteci kullanarak kullanıcınızın cihazının 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, belirtilen 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, 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 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. CorS'yi, kaynak etki alanından gelen isteklerin Azure Depolama tarafından güvenilen web tarayıcısıyla iletişim kuracak şekilde Azure Depolama hizmetlerinden herhangi biri için 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.

Ö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 almaktan kaçınmanın bir yolu, GET işlemini değiştirme süresi için koşullu ü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şmediğini 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 alma 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 veri parçasını hemen karşıya yüklemek yerine düzenli aralıklarla toplu olarak karşıya 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) karşıya yükleyebilir veya etkinlik ayrıntılarını yerel bir günlük dosyasına kaydedebilir ve ardından tüm etkinlik ayrıntılarını sınırlandırılmış bir dosya olarak bloba düzenli aralıklarla 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ştiricisinin istemci cihazı veya karşıya yükleme hatası olasılığı için tasarlaması gerekir. Etkinlik verilerinin tek bir etkinlik yerine belirli bir süre için indirilmesi gerekiyorsa, Tablo depolama üzerinden Blob depolama kullanılması önerilir.

.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

.NET Framework kullanan projelerde, varsayılan bağlantı sınırını (genellikle istemci ortamında iki veya sunucu ortamında ondur) 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ğlantı 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 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, 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.

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. Yaygın hata kodlarının listesi için bkz . Ortak REST API hata kodları.

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 bir isteği işleyemeyebilir. Her iki durumda da hizmet 503 (Sunucu Meşgul) veya 500 (Zaman Aşımı) 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 veremediyse 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, ardından 4 saniye, ardından 10 saniye, ardından 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ğ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 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 (Hatalı İstek) 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ı.

Blobları kopyalama ve taşıma

Azure Depolama, depolama hesabı içinde, depolama hesapları arasında ve şirket içi sistemler ile bulut arasında blobları kopyalamak ve taşımak için çeşitli çözümler 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ı içindeki 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 aktarımı için basit ve verimli bir seçenektir. AzCopy bu senaryo için en iyi duruma getirilmiştir ve yüksek aktarım hızları elde edebilir. AzCopy sürüm 10, blob verilerini depolama hesapları arasında kopyalamak için bu işlemi 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, Azure Front Door gibi bir Content Delivery Network (CDN) kullanın. Azure Front Door, Microsoft'un kullanıcılarınız ile uygulamalarınızın dünya genelindeki statik ve dinamik web içeriği arasında hızlı, güvenilir ve güvenli erişim sağlayan modern bulut CDN'dir. Azure Front Door, Yüzlerce küresel ve yerel iletişim noktası (POP) ile Microsoft'un genel uç ağını kullanarak Blob Depolama içeriğinizi sunar. CDN genellikle tek bir depolama hesabından çok daha yüksek çıkış sınırlarını destekleyebilir ve diğer bölgelere içerik teslimi için geliştirilmiş gecikme süresi sunar.

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

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 uygulama fotoğrafı karşıya yüklediğinde Exif verilerini blob'un meta verilerinde depolayabilir. Daha sonra meta verilerdeki Exif verilerini yalnızca bir HEAD isteği kullanarak alabilirsiniz. Blobun tam içeriğinin değil yalnızca meta verilerin alınması önemli 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.

Hesap ve kapsayıcı meta veri güncelleştirmeleri

Hesap ve kapsayıcı meta verileri, hesabın bulunduğu bölgedeki depolama hizmetine yayılır. Bu meta verilerin tam olarak yayılması, işleme bağlı olarak 60 saniyeye kadar sürebilir. Örneğin:

• Aynı bölgede aynı hesap adına sahip hesapları hızla oluşturuyor, siliyor ve yeniden oluşturuyorsanız, hesap durumunun tamamen yayılması için 60 saniye beklediğinizden emin olun; aksi takdirde istekleriniz başarısız olabilir.
• Bir kapsayıcıda depolanan erişim ilkesi oluşturduğunuzda, ilkenin etkili olması 30 saniye kadar sürebilir.

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ığı ortama göre istemci kitaplığı aktarım seçeneklerini yapılandırma konusunda 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 karşıya yüklediğinizi 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 kılavuz 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ın ö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 karşıya 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 kullanmaya başlama.

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

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

• Blob depolama için ölçeklenebilirlik ve performans hedefleri
• Standart depolama hesapları için ölçeklenebilirlik ve performans hedefleri
• Durum ve hata kodları