Azure Cosmos DB Async Java SDK v2 için performans ipuçları

2024-08-15

UYGULANANLAR: NoSQL

Ö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çeği artırma ve azaltma, 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ğ

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 (varsayılan)
- Dolaysız
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. Ancak performans açısından dezavantaj, Ağ Geçidi modunun veriler Azure Cosmos DB'ye her okunduğu veya yazıldığını her seferinde ek bir ağ atlamasını içermesidir. 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.

Asenkron 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 muhtemelen, istemciden Azure veri merkezi sınırına geçerken istek tarafından izlenen yola bağlı olarak isteklere göre değişiklik 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 Mod Genel Bakış

Doğrudan mod mimarisinin tasviri

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 diyagram, Doğrudan modun istemci isteklerini Azure Cosmos DB arka ucundaki çoğaltmalara nasıl yönlendirdiğini göstermektedir. Doğrudan mod mimarisi, veritabanı çoğaltması başına istemci tarafında en fazla 10 Kanal ayırır. Kanal, 30 isteklik derinlikte bir istek arabelleği ile önceden yapılandırılmış bir TCP bağlantısıdır. Bir çoğaltmaya ait kanallar, gerektiğinde çoğaltmanın Hizmet Uç Noktası tarafından 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ına gönderilmeden ö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
bağlantıZamanAşımı	"PT1M"
Boşta Kanal Zaman Aşımı	"PT0S"
idleEndpointTimeout	"PT1M10S"
maksimum tampon kapasitesi	8388608
Uç nokta başına maksimum kanal sayısı	10
Kanal Başına Maksimum İstek Sayısı	30
askıya alma algılama süresini al	"PT1M5S"
requestExpiryInterval	"PT5S"
requestTimeout	"PT1M"
requestTimerResolution	"PT0.5S"
askı tespit süresi gönder	"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ı-dupleks" işlemi zorlar ve sonraki istekler, önceki isteğin yanıtını beklerken bloke olur.
- 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ğ IO'sunu Netty yönetir. Netty IO iş parçacıklarını engelleyen kod örüntülerinden kaçınmak için bu ipuçlarına bakı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'deki 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.
- Ayarlanan Maksimum Paralellik Derecesi
  
  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. 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şmasına neden olacak şekilde bölümlendirilmişse, bu bölümler sorgunun performansını kısıtlar.
- SetMaxBufferedItemCount ayarlama:
  
  Paralel sorgu, geçerli sonuç toplu işlemi istemci tarafından işlenirken sonuçları önceden işlemek 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.
  
  Önceden getirme, MaxDegreeOfParallelism'den bağımsız olarak aynı şekilde çalışır ve her bir bölümden gelen veriler için tek bir arabellek vardır.
getRetryAfterInMilliseconds aralıklarında gecikmeli yanıt mekanizması uygulayın

Performans testi sırasında, az sayıda istek kısıtlanana kadar yükü artırmanız gerekir. Kısıtlanırsa, istemci uygulama sunucu tarafından belirtilen tekrar deneme süresi boyunca geri çekilmelidir. Geri çekilme stratejisine uymanız, yeniden denemeler arasında bekleme sürenizi en aza indirir.
İ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, makinenin CPU veya ağ kullanımına odaklanması nedeniyle istemci uygulaması performans sorununa neden olabilir. Bu noktaya ulaşırsanız, Azure Cosmos DB hesabınızın kapasitesini artırmak için istemci uygulamalarınızı birden çok sunucuya yayabilirsiniz.
Ad tabanlı adresleme kullanma

Ad tabanlı adreslemeyi kullanın, burada bağlantılar dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentId formatına sahiptir, bağlantıyı oluşturmak için kullanılan tüm kaynakların ResourceId'lerini almak zorunda kalmamak için formatı dbs/<database_rid>/colls/<collection_rid>/docs/<document_rid> olan SelfLinks (_self) yerine bu formatı tercih edin. Ayrıca, bu kaynaklar yeniden oluşturulurken (muhtemelen aynı isimle), önbelleğe almak çok fazla 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 Planlayıcıyı Kullanın (Olay döngüsü G/Ç Netty iş parçacıklarını çalmaktan kaçının)

Azure Cosmos DB Asenkron Java SDK'sı v2, engellemesiz IO için netty kullanır. SDK, G/Ç işlemlerini yürütmek için makinenizdeki CPU çekirdeklerinin sayısı kadar sabit sayıda G/Ç Netty olay döngüsü iş parçacığı kullanır. API tarafından döndürülen Observable, Netty'nin paylaşılan IO olay döngüsü iş parçacıklarından birinde sonucu yayar. Bu nedenle paylaşılan G/Ç olay döngüsü netty iş parçacıklarının engellenmemesi önem taşır. G/Ç olay döngüsü işleyişini yöneten netty iş parçacığı üzerinde yoğun CPU kullanımına ihtiyaç duyan görevler veya engelleme işlemleri yapmak, kilitlenmeye neden olabilir veya SDK veri aktarım hızını önemli ölçüde azaltabilir.

Örneğin, aşağıdaki kod CPU yoğun bir işi olay döngüsü IO Netty iş parçacığında 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 çalışması yapmak istiyorsanız, bunu olay döngüsü GÇ netty iş parçacığında yapmaktan kaçınmalısınız. Bunun yerine, çalışmanızı çalıştırmak için kendi iş parçacığınızı sağlamak üzere kendi Scheduler'ınızı sağlayabilirsiniz.

Zaman uyumsuz 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ırakma

Netty kitaplığı günlük kaydı gevendedir ve ek CPU maliyetlerinden kaçınmak için kapatılması gerekir (yapılandırmada oturum açmayı gizleme yeterli olmayabilir). Hata ayıklama modunda değilseniz netty'nin günlüğünü tamamen devre dışı bırakın. Bu nedenle, netty'den tahakkuk org.apache.log4j.Category.callAppenders() 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);
```
İşletim Sistemi Dosyaları aç Kaynak Sınırı

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 -a
```
Açı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.conf
```
Aşağıdaki satırları ekleyin/değiştirin:
```
* - nofile 100000
```

Dizin Oluşturma İlkesi

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.

Zaman uyumsuz 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.

Aktarım hızı

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.

Zaman uyumsuz Java SDK V2 (Maven com.microsoft.azure::azure-cosmosdb)
```
ResourceResponse<Document> response = asyncClient.createDocument(collectionLink, documentDefinition, null,
                                                 false).toBlocking.single();
response.getRequestCharge();
```
Bu üst bilgide döndürülen istek ü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, izleyen istekleri sınırlamadan önce bu tür iki isteği kabul eder. Daha fazla bilgi için bkz . İstek birimleri ve istek birimi hesaplayıcısı.
İşleme hızı sınırlama/istek hızı çok büyük

İ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 :100
```
SDK'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, özellikle gecikme süresini ölçerken performans karşılaştırmaları yapılırken ortaya çıkabilir. 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üresi artışlarını önlemek için her işlem tarafından döndürülen ücreti ölçün ve isteklerin ayrılmış istek oranının altında çalıştığından emin olun. Daha fazla bilgi için bkz İstek birimleri.
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.

Aracılığıyla paylaş