Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Önemli
Bu, Azure Cosmos DB için en son Java SDK'sı değildir ! Projenizi Azure Cosmos DB Java SDK v4'e yükseltmeniz ve ardından Azure Cosmos DB Java SDK v4 performans ipuçları kılavuzunu okumanız gerekir. Yükseltmek için Azure Cosmos DB Java SDK v4'e geçiş kılavuzu ve Reactor vs RxJava kılavuzundaki yönergeleri izleyin.
Bu makaledeki performans ipuçları yalnızca Azure Cosmos DB Async Java SDK v2 içindir. Daha fazla bilgi için Bkz. Azure Cosmos DB Async Java SDK v2 Sürüm notları, Maven deposu ve Azure Cosmos DB Async Java SDK v2 sorun giderme kılavuzu .
Önemli
31 Ağustos 2024'te Azure Cosmos DB Zaman Uyumsuz Java SDK'sı v2.x kullanımdan kaldırılacak; SDK ve SDK kullanan tüm uygulamalar çalışmaya devam eder; Azure Cosmos DB, bu SDK için daha fazla bakım ve destek sağlamayı durduracaktır. Azure Cosmos DB Java SDK v4'e geçiş yapmak için yukarıdaki yönergelerin izlenmesini öneririz.
Azure Cosmos DB, garantili gecikme süresi ve aktarım hızı ile sorunsuz bir şekilde ölçeklendirilen hızlı ve esnek bir dağıtılmış veritabanıdır. Azure Cosmos DB ile veritabanınızı ölçeklendirmek için büyük mimari değişiklikleri yapmanız veya karmaşık kod yazmanız gerekmez. Ölçeklendirmeyi artırmak veya azaltmak, tek bir API çağrısı veya SDK yöntem çağrısı yapmak kadar kolaydır. Ancak Azure Cosmos DB'ye ağ çağrıları aracılığıyla erişildiğinden , Azure Cosmos DB Async Java SDK v2 kullanırken en yüksek performansı elde etmek için istemci tarafı iyileştirmeleri yapabilirsiniz.
Bu nedenle "Veritabanımın performansını nasıl geliştirebilirim?" sorusunu soruyorsanız aşağıdaki seçenekleri göz önünde bulundurun:
Ağ Kurma
Bağlantı modu: Doğrudan modu kullanma
İstemcinin Azure Cosmos DB'ye nasıl bağlandığı, özellikle istemci tarafı gecikme süresi açısından performans üzerinde önemli etkilere sahiptir. ConnectionMode, istemci ConnectionPolicy'yi yapılandırmak için kullanılabilen önemli bir yapılandırma ayarıdır. Azure Cosmos DB Async Java SDK v2 için iki kullanılabilir ConnectionModes şunlardır:
Ağ geçidi modu tüm SDK platformlarında desteklenir ve varsayılan olarak yapılandırılan seçenektir. Uygulamalarınız katı güvenlik duvarı kısıtlamalarıyla bir şirket ağı içinde çalıştırılıyorsa ağ geçidi modu, standart HTTPS bağlantı noktası ve tek uç nokta kullandığından en iyi seçenektir. Azure Cosmos DB'ye veri okuma veya yazma işlemi her gerçekleştiğinde, Ağ Geçidi modu nedeniyle ek bir ağ atlaması meydana gelmesi bir performans dezavantajıdır. Bu nedenle, Direct modu daha az ağ atlamaları nedeniyle daha iyi performans sunar.
ConnectionMode, ConnectionPolicy parametresiyle DocumentClient örneğinin oluşturulması sırasında yapılandırılır.
Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)
public ConnectionPolicy getConnectionPolicy() {
ConnectionPolicy policy = new ConnectionPolicy();
policy.setConnectionMode(ConnectionMode.Direct);
policy.setMaxPoolSize(1000);
return policy;
}
ConnectionPolicy connectionPolicy = new ConnectionPolicy();
DocumentClient client = new DocumentClient(HOST, MASTER_KEY, connectionPolicy, null);
Performans için aynı Azure bölgesindeki istemcileri birlikte dağıtma
Mümkün olduğunda, Azure Cosmos DB'yi çağıran tüm uygulamaları Azure Cosmos DB veritabanıyla aynı bölgeye yerleştirin. Yaklaşık bir karşılaştırma için, aynı bölge içindeki Azure Cosmos DB çağrıları 1-2 ms içinde tamamlanır, ancak ABD'nin Batı ve Doğu kıyısı arasındaki gecikme süresi 50 ms'dir >. Bu gecikme süresi, istemciden Azure veri merkezi sınırına geçerken talebin izlediği güzergaha bağlı olarak bir talepten diğerine farklılık gösterebilir. Çağrı yapan uygulamanın sağlanan Azure Cosmos DB uç noktasıyla aynı Azure bölgesinde bulunduğundan emin olunarak mümkün olan en düşük gecikme süresi elde edilir. Kullanılabilir bölgelerin listesi için bkz . Azure Bölgeleri.
SDK Kullanımı
En son SDK'sını yükleme
Azure Cosmos DB SDK'ları en iyi performansı sağlayacak şekilde sürekli geliştirilmektedir. En son SDK'yı belirlemek ve iyileştirmeleri gözden geçirmek için Azure Cosmos DB Zaman Uyumsuz Java SDK v2 Sürüm Notları sayfalarına bakın.
Uygulamanızın ömrü boyunca tek bir Azure Cosmos DB istemcisi kullanma
Her AsyncDocumentClient örneği iş parçacığı açısından güvenlidir ve verimli bağlantı yönetimi ve adres önbelleğe alma işlemi gerçekleştirir. AsyncDocumentClient tarafından verimli bağlantı yönetimine ve daha iyi performansa izin vermek için uygulamanın ömrü boyunca AppDomain başına tek bir AsyncDocumentClient örneği kullanılması önerilir.
ConnectionPolicy'yi Ayarlama
Varsayılan olarak, Azure Cosmos DB Async Java SDK v2 kullanılırken Doğrudan mod Azure Cosmos DB istekleri TCP üzerinden yapılır. SDK, ağ kaynaklarını dinamik olarak yönetmek ve en iyi performansı elde etmek için özel bir Doğrudan mod mimarisi kullanır.
Azure Cosmos DB Zaman Uyumsuz Java SDK v2'de, çoğu iş yüküyle veritabanı performansını geliştirmek için en iyi seçenek Doğrudan modudur.
- Doğrudan modun genel bakışı
Doğrudan modda kullanılan istemci tarafı mimarisi, Azure Cosmos DB çoğaltmalarına tahmin edilebilir ağ kullanımı ve çoklu erişim sağlar. Yukarıdaki diyagramda, Doğrudan modun istemci isteklerini Azure Cosmos DB arka uçtaki çoğaltmalara nasıl yönlendirdiği gösterilmektedir. Doğrudan mod mimarisi, istemci tarafında her DB replikası için en fazla 10 Kanal ayırır. Bir Kanal, 30 istek derinliğinde bir istek arabelleği tarafından önceden oluşturulmuş bir TCP bağlantısıdır. Bir replikaya ait Kanallar, replikadaki Hizmet Uç Noktası tarafından gerektiğinde dinamik olarak ayrılır. Kullanıcı Doğrudan modunda bir istek yayınladığında, TransportClient isteği bölüm anahtarına göre uygun hizmet uç noktasına yönlendirir. İstek Kuyruğu, istekleri Hizmet Uç Noktasından önce arabelleğe alır.
Doğrudan mod için ConnectionPolicy Yapılandırma seçenekleri
İlk adım olarak aşağıdaki önerilen yapılandırma ayarlarını kullanın. Bu konuda sorunlarla karşılaşırsanız Azure Cosmos DB ekibine başvurun.
Azure Cosmos DB'yi başvuru veritabanı olarak kullanıyorsanız (başka bir ifadeyle, veritabanı birçok nokta okuma işlemi ve birkaç yazma işlemi için kullanılır), idleEndpointTimeout değerini 0 olarak ayarlamak (yani zaman aşımı yoktur) kabul edilebilir.
Yapılandırma seçeneği Varsayılan bufferPageSize 8192 connectionTimeout "PT1M" idleChannelTimeout "PT0S" idleEndpointTimeout "PT1M10S" maksimum Arabellek Kapasitesi 8388608 maxChannelsPerEndpoint 10 KanalBaşınaMaksimumİstekSayısı 30 receiveHangDetectionTime "PT1M5S" requestExpiryInterval "PT5S" requestTimeout "PT1M" requestTimerResolution "PT0.5S" sendHangDetectionTime süresi gönderme "PT10S" shutdownTimeout "PT15S"
Doğrudan mod için programlama ipuçları
SDK sorunlarını çözmek için temel olarak Azure Cosmos DB Zaman Uyumsuz Java SDK v2 Sorun Giderme makalesini gözden geçirin.
Doğrudan modu kullanırken bazı önemli programlama ipuçları:
Verimli TCP veri aktarımı için uygulamanızda çoklu iş parçacığı kullanımı - İstekte bulunduktan sonra uygulamanızın başka bir iş parçacığındaki verileri almak için abone olması gerekir. Bunun yapılmaması, istenmeyen "yarı çift yönlü" işlemeye neden olur ve sonraki istekler, önceki isteğin yanıtını beklerken engellenir.
Ayrılmış bir iş parçacığında işlem yoğunluklu iş yükleri gerçekleştirme - Önceki ipucuna benzer nedenlerle, karmaşık veri işleme gibi işlemler en iyi şekilde ayrı bir iş parçacığına yerleştirilir. Başka bir veri deposundan veri çeken bir istek (örneğin iş parçacığı Azure Cosmos DB ve Spark veri depolarını aynı anda kullanıyorsa) gecikme süresi artabilir ve diğer veri deposundan yanıt bekleyen ek bir iş parçacığı oluşturmanız önerilir.
- Azure Cosmos DB Async Java SDK v2'deki temel ağ giriş/çıkış işlemlerini Netty yönetmektedir. Netty IO iş parçacıklarını engelleyen kodlama desenlerinden kaçınmak için bu ipuçlarına göz atın.
Veri modelleme - Azure Cosmos DB SLA'sı, belge boyutunun 1 KB'tan az olduğunu varsayar. Veri modelinizi ve programlamanızı daha küçük belge boyutunu tercih edecek şekilde en iyi duruma getirmek genellikle gecikme süresinin azalmasına neden olur. 1 KB'tan büyük belgelerin depolanmasına ve alınmasına ihtiyacınız olacaksa, önerilen yaklaşım belgelerin Azure Blob Depolama'daki verilere bağlanmasıdır.
Bölümlenmiş koleksiyonlar için paralel sorguları ayarlama
Azure Cosmos DB Async Java SDK v2, bölümlenmiş bir koleksiyonu paralel olarak sorgulamanızı sağlayan paralel sorguları destekler. Daha fazla bilgi için bkz. SDK'larla çalışmayla ilgili kod örnekleri . Paralel sorgular, seri karşıtlarına göre sorgu gecikme süresini ve aktarım hızını geliştirmek için tasarlanmıştır.
Maksimum Paralellik Derecesini Ayarlama:
Paralel sorgular, birden çok bölümü paralel olarak sorgulayarak çalışır. Ancak, tek bir bölümlenmiş koleksiyondaki veriler sorguya göre seri olarak getirilir. Bu nedenle, setMaxDegreeOfParallelism kullanarak diğer tüm sistem koşullarının aynı kalması koşuluyla en yüksek performansa sahip sorguya ulaşma şansı en yüksek olan bölüm sayısını ayarlayın. Bölüm sayısını bilmiyorsanız, setMaxDegreeOfParallelism kullanarak yüksek bir sayı ayarlayabilirsiniz ve sistem en düşük (bölüm sayısı, kullanıcı tarafından sağlanan giriş) paralellik en yüksek derecesi olarak seçer.
Veriler sorguya göre tüm bölümlere eşit olarak dağıtılıyorsa, paralel sorguların en iyi avantajları sağladığını unutmayın. Bölümlenmiş koleksiyon, sorgu tarafından döndürülen verilerin tümünün veya çoğunun birkaç bölümde (en kötü durumda bir bölümde) yoğunlaşacak şekilde bölümlenmişse, sorgunun performansı bu bölümler tarafından sınırlanır.
setMaxBufferedItemCount değerini ayarlama:
Paralel sorgu, geçerli sonuç kümesi istemci tarafından işlenirken sonuçları önceden getirmek için tasarlanmıştır. Ön işlem, bir sorgunun genel gecikme süresi iyileştirmesine yardımcı olur. setMaxBufferedItemCount, önceden oluşturulmuş sonuçların sayısını sınırlar. setMaxBufferedItemCount değerinin beklenen sonuç sayısına (veya daha yüksek bir sayıya) ayarlanması, sorgunun ön işlemden en yüksek avantajı almasını sağlar.
Ön yükleme, MaxDegreeOfParallelism'den bağımsız olarak aynı şekilde çalışır ve tüm bölümlerdeki veriler için tek bir arabellek vardır.
getRetryAfterInMilliseconds aralıklarında geri alma uygulama
Performans testi sırasında, az sayıda isteğin kısıtlanmasına kadar yükü artırmalısınız. Kısıtlanırsa, istemci uygulamanın sunucu tarafından belirtilen yeniden deneme aralığı için geri çekilmesi gerekir. Geri çekilme stratejisine uyum sağlamak, yeniden denemeler arasında beklemek için en az zamanı harcamanızı sağlar.
İstemci iş yükünüzün ölçeğini genişletme
Yüksek aktarım hızı düzeylerinde (>50.000 RU/sn) test ediyorsanız, istemci uygulaması, makinenin CPU veya ağ kullanım limitine ulaşması nedeniyle darboğaz oluşturabilir. Bu noktaya ulaşırsanız, istemci uygulamalarınızı birden çok sunucuya yayarak Azure Cosmos DB hesabınızı daha da genişletebilirsiniz.
Ad tabanlı adresleme kullanma
Ad tabanlı adreslemeyi kullanarak, bağlantıları oluşturmak için kullanılan tüm kaynakların ResourceId'lerini almaktan kaçınmak amacıyla
dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentIdformatındaki bağlantılar yerinedbs/<database_rid>/colls/<collection_rid>/docs/<document_rid>formatındaki SelfLinks (_self) bağlantılarını kullanmayın. Ayrıca, bu kaynaklar yeniden oluşturulurken (büyük olasılıkla aynı ada sahip), önbelleğe almak yardımcı olmayabilir.Daha iyi performans için sorgular/okuma akışları için sayfa boyutunu ayarlama
Okuma akışı işlevselliğini kullanarak (örneğin, readDocuments) belgelerin toplu okumasını gerçekleştirirken veya bir SQL sorgusu gönderirken, sonuç kümesi çok büyükse sonuçlar kesimli bir şekilde döndürülür. Varsayılan olarak, sonuçlar 100 öğe veya 1 MB'lık öbekler halinde döndürülür(hangisi önce sınıra isabet edilirse).
Geçerli tüm sonuçları almak için gereken ağ gidiş dönüşlerinin sayısını azaltmak için , x-ms-max-item-count istek üst bilgisini kullanarak sayfa boyutunu 1000'e kadar artırabilirsiniz. Yalnızca birkaç sonuç görüntülemeniz gereken durumlarda, örneğin kullanıcı arabiriminiz veya uygulama API'niz bir kerede yalnızca 10 sonuç döndürüyorsa, okumalar ve sorgular için kullanılan aktarım hızını azaltmak için sayfa boyutunu da 10'a düşürebilirsiniz.
Sayfa boyutunu setMaxItemCount yöntemini kullanarak da ayarlayabilirsiniz.
Uygun Zamanlayıcıyı Kullan (Olay döngüsü GÇ Netty iş parçacıklarını çalmaktan kaçının)
Azure Cosmos DB Asenkron Java SDK'sı v2, engellemesiz GÇ için netty kullanır. SDK, Girdi/Çıktı işlemlerini yürütmek için, makinenizdeki CPU çekirdeklerinin sayısı kadar sabit sayıda Netty olay döngüsü iş parçacığı kullanır. API tarafından döndürülen Observable, paylaşılan IO olay döngüsü netty iş parçacıklarından birinde sonucu yayımlar. Bu nedenle paylaşılan Girdi/Çıktı olay döngüsündeki Netty iş parçacıklarının engellenmemesi önemlidir. IO olay döngüsü netty iş parçacığında CPU yoğunluklu çalışma veya engelleyici işlem yapmak kilitlenmeye neden olabilir veya SDK'nin aktarım hızını önemli ölçüde azaltabilir.
Örneğin aşağıdaki kod, olay döngüsü GÇ netty iş parçacığında yoğun cpu kullanan bir iş yürütür:
Asenkron Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)
Observable<ResourceResponse<Document>> createDocObs = asyncDocumentClient.createDocument( collectionLink, document, null, true); createDocObs.subscribe( resourceResponse -> { //this is executed on eventloop IO netty thread. //the eventloop thread is shared and is meant to return back quickly. // // DON'T do this on eventloop IO netty thread. veryCpuIntensiveWork(); });Sonuç alındıktan sonra, sonuç üzerinde yoğun CPU işlemleri yapmak istiyorsanız, bunu olay döngüsü IO netty iş parçacığında yapmaktan kaçınmalısınız. Bunun yerine, çalışmanızı yürütmek için kendi iş parçacığınızı tahsis edecek bir Zamanlayıcı sağlayabilirsiniz.
Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)
import rx.schedulers; Observable<ResourceResponse<Document>> createDocObs = asyncDocumentClient.createDocument( collectionLink, document, null, true); createDocObs.subscribeOn(Schedulers.computation()) subscribe( resourceResponse -> { // this is executed on threads provided by Scheduler.computation() // Schedulers.computation() should be used only when: // 1. The work is cpu intensive // 2. You are not doing blocking IO, thread sleep, etc. in this thread against other resources. veryCpuIntensiveWork(); });Çalışmanızın türüne bağlı olarak, çalışmanız için uygun mevcut RxJava Scheduler'ı kullanmanız gerekir. Burayı
Schedulersokuyun.Daha fazla bilgi için lütfen Azure Cosmos DB Async Java SDK v2 için GitHub sayfasına bakın.
Netty'nin günlüğünü devre dışı bırakın
Netty kütüphanesinin günlük kaydı çok konuşkandır ve ek CPU maliyetlerinden kaçınmak için kapatılması gerekir (konfigürasyonda günlük seviyesi azaltmak yeterli olmayabilir). Hata ayıklama modunda değilseniz netty'nin günlüğünü tamamen devre dışı bırakın. Bu nedenle,
org.apache.log4j.Category.callAppenders()ile netty üzerinden tahakkuk eden ek CPU maliyetlerini kaldırmak için log4j kullanıyorsanız, kod tabanınıza aşağıdaki satırı ekleyin:org.apache.log4j.Logger.getLogger("io.netty").setLevel(org.apache.log4j.Level.OFF);OS Açık Dosya Kaynak Limiti
Bazı Linux sistemleri (Red Hat gibi) açık dosya sayısı ve dolayısıyla toplam bağlantı sayısı üzerinde üst sınıra sahiptir. Geçerli sınırları görüntülemek için aşağıdakileri çalıştırın:
ulimit -aAçık dosya (nofile) sayısının, yapılandırılmış bağlantı havuzu boyutunuz ve işletim sistemi tarafından diğer açık dosyalar için yeterli alan olacak kadar büyük olması gerekir. Daha büyük bir bağlantı havuzu boyutuna izin verecek şekilde değiştirilebilir.
limits.conf dosyasını açın:
vim /etc/security/limits.confAşağıdaki satırları ekleyin/değiştirin:
* - nofile 100000
Dizin oluşturma ilkesi
Daha hızlı yazma işlemleri için, kullanılmayan yolları dizin oluşturmanın dışında bırakma
Azure Cosmos DB'nin dizin oluşturma ilkesi, Dizin Oluşturma Yollarını (setIncludedPaths ve setExcludedPaths) kullanarak hangi belge yollarının dizine ekleneceğini veya dizin oluşturmanın dışında tutulacağını belirtmenize olanak tanır. Dizin oluşturma maliyetlerinin dizine alınan benzersiz yol sayısıyla doğrudan bağıntılı olması nedeniyle, dizin oluşturma yollarının kullanımı, sorgu desenlerinin önceden bilindiği senaryolar için gelişmiş yazma performansı ve daha düşük dizin depolaması sunabilir. Örneğin, aşağıdaki kod belgelerin bir bölümünün tamamının (alt ağaç olarak da bilinir) "*" joker karakteri kullanılarak dizin oluşturmadan nasıl dışlandığını gösterir.
Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)
Index numberIndex = Index.Range(DataType.Number); numberIndex.set("precision", -1); indexes.add(numberIndex); includedPath.setIndexes(indexes); includedPaths.add(includedPath); indexingPolicy.setIncludedPaths(includedPaths); collectionDefinition.setIndexingPolicy(indexingPolicy);Daha fazla bilgi için bkz . Azure Cosmos DB dizin oluşturma ilkeleri.
Throughput
Daha düşük istek birimleri/saniye kullanımı için ölçme ve ayarlama
Azure Cosmos DB, UDF'ler, saklı yordamlar ve tetikleyiciler içeren ilişkisel ve hiyerarşik sorgular da dahil olmak üzere zengin bir veritabanı işlemleri kümesi sunar. Bunların tümü bir veritabanı koleksiyonundaki belgeler üzerinde çalışır. Bu işlemlerden her biriyle ilişkilendirilmiş maliyet, işlemi tamamlamak için gereken CPU, GÇ ve belleğe göre değişiklik gösterir. Donanım kaynaklarını düşünmek ve yönetmek yerine, bir istek birimini (RU) çeşitli veritabanı işlemlerini gerçekleştirmek ve bir uygulama isteğine hizmet vermek için gereken kaynaklar için tek bir ölçü olarak düşünebilirsiniz.
Aktarım hızı, her kapsayıcı için ayarlanan istek birimi sayısına göre sağlanır. İstek birimi tüketimi saniye başına hız olarak değerlendirilir. Kapsayıcıları için sağlanan istek birimi hızını aşan uygulamalar, hız kapsayıcı için sağlanan düzeyin altına düşene kadar sınırlıdır. Uygulamanız daha yüksek bir aktarım hızı düzeyi gerektiriyorsa, ek istek birimleri sağlayarak aktarım hızınızı artırabilirsiniz.
Sorgunun karmaşıklığı, bir işlem için kaç istek biriminin tüketilmiş olduğunu etkiler. Koşul sayısı, koşulların yapısı, UDF sayısı ve kaynak veri kümesinin boyutu, sorgu işlemlerinin maliyetini etkiler.
Herhangi bir işlemin yükünü ölçmek için (oluşturma, güncelleştirme veya silme), x-ms-request-charge üst bilgisini inceleyerek bu işlemler tarafından kullanılan istek birimi sayısını ölçün. ResourceResponse T veya FeedResponse<>T<> içindeki eşdeğer RequestCharge özelliğine de bakabilirsiniz.
Async Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)
ResourceResponse<Document> response = asyncClient.createDocument(collectionLink, documentDefinition, null, false).toBlocking.single(); response.getRequestCharge();Bu başlıkta döndürülen talep ücreti, sağlanan aktarım hızınızın bir bölümüdür. Örneğin, sağlanan 2000 RU/sn'niz varsa ve yukarıdaki sorgu 1.000 1 KB belge döndürüyorsa, işlemin maliyeti 1000'dir. Bu nedenle, sunucu bir saniye içinde yalnızca iki isteği kabul eder ve daha sonraki istekleri hız sınırlandırmasına tabi tutar. Daha fazla bilgi için bkz . İstek birimleri ve istek birimi hesaplayıcısı.
Hız sınırlamasını yönet/istek hızı çok yüksek
İstemci bir hesap için ayrılmış aktarım hızını aşmaya çalıştığında, sunucuda performans düşüşü olmaz ve ayrılmış düzeyin ötesinde aktarım hızı kapasitesi kullanılamaz. Sunucu isteği RequestRateTooLarge (HTTP durum kodu 429) ile önceden sonlandıracak ve kullanıcının isteği yeniden başlatmadan önce beklemesi gereken süreyi milisaniye cinsinden belirten x-ms-retry-after-ms üst bilgisini döndürür.
HTTP Status 429, Status Line: RequestRateTooLarge x-ms-retry-after-ms :100SDK'ların tümü bu yanıtı örtük olarak yakalar, sunucuda belirtilen retry-after üst bilgisine saygı gösterir ve isteği yeniden dener. Hesabınıza birden çok istemci tarafından eşzamanlı olarak erişilmediği sürece sonraki yeniden deneme başarılı olur.
İstek oranının üzerinde tutarlı bir şekilde çalışan birden fazla istemciniz varsa, istemci tarafından şu anda dahili olarak 9 olarak ayarlanmış varsayılan yeniden deneme sayısı yeterli olmayabilir; bu durumda istemci, uygulamaya 429 durum koduna sahip bir DocumentClientException oluşturur. Varsayılan yeniden deneme sayısı ConnectionPolicy örneğinde setRetryOptions kullanılarak değiştirilebilir. Varsayılan olarak, istek istek hızının üzerinde çalışmaya devam ederse 30 saniyelik bir toplu bekleme süresinden sonra durum kodu 429 olan DocumentClientException döndürülür. Bu durum, geçerli yeniden deneme sayısı varsayılan olarak 9 veya kullanıcı tanımlı bir değer olması durumunda maksimum yeniden deneme sayısı'nın altında olsa bile oluşur.
Otomatik yeniden deneme davranışı çoğu uygulama için dayanıklılığı ve kullanılabilirliği artırmaya yardımcı olsa da, performans değerlendirme testleri sırasında, özellikle de gecikme süresini ölçerken, bazen çelişkilere yol açabilir. Deneme sunucu kısıtlamasına isabet ederse ve istemci SDK'sının sessizce yeniden denemesine neden olursa istemci tarafından gözlemlenen gecikme süresi artar. Performans denemeleri sırasında gecikme sürelerinde ani artışları önlemek için her işlemin döndürdüğü yükü ölçün ve isteklerin ayrılmış istek oranının altında çalıştığından emin olun. Daha fazla bilgi için İstek birimleri bölümüne bakın.
Daha yüksek aktarım hızı için daha küçük belgeler tasarlama
Belirli bir işlemin istek ücreti (istek işleme maliyeti), belgenin boyutuyla doğrudan ilişkilendirilir. Büyük belgelerdeki işlemler, küçük belgeler için yapılan işlemlerden daha pahalıdır.
Sonraki Adımlar
Uygulamanızı ölçeklendirme ve yüksek performans için tasarlama hakkında daha fazla bilgi edinmek için bkz . Azure Cosmos DB'de bölümleme ve ölçeklendirme.