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

UYGULANANLAR: NoSQL

• Java SDK v4
• Async Java SDK v2
• Java SDK v2'yi eşitleme
• .NET SDK v3
• .NET SDK v2
• Python SDK'sı

Ö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ğlan ion 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. Bağlan ionMode, istemci Bağlan ionPolicy'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 Bağlan ionModes şunlardır:

  • Ağ geçidi (varsayılan)
  • Doğru -dan

  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.

  Bağlan ionMode, DocumentClient örneğinin oluşturulması sırasında Bağlan ionPolicy parametresiyle yapılandırılır.

Zaman uyumsuz 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 istek tarafından alınan yola bağlı olarak istekten isteğe 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.

• Bağlan ionPolicy 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 moda 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önlendirecekleri gösterilmektedir. Doğrudan mod mimarisi, veritabanı çoğaltması başına istemci tarafında en fazla 10 Kanal ayırır. Kanal, 30 istek derinliğinde bir istek arabelleğinden önce gelen bir TCP bağlantısıdır. Bir çoğaltmaya ait kanallar, çoğaltmanın 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 Bağlan ionPolicy 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"
    maxBufferCapacity	8388608
    maxChannelsPerEndpoint	10
    maxRequestsPerChannel	30
    receiveHangDetectionTime	"PT1M5S"
    requestExpiryInterval	"PT5S"
    requestTimeout	"PT1M"
    requestTimerResolution	"PT0.5S"
    sendHangDetectionTime	"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şlemi zorlar 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ğ GÇ'sini Netty yönetmektedir. Netty GÇ iş parçacıklarını engelleyen kodlama desenlerinden kaçınmaya yönelik 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.

  • SetMaxDegreeOfParallelism 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üm) yoğunlaşacağı şekilde bölümlenmişse, sorgunun performansı bu bölümler tarafından performans sorununa neden olur.

  • 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 oluşturma, 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 istek azaltılana kadar yükü artırmanız gerekir. Kısıtlanırsa, istemci uygulamanın sunucu tarafından belirtilen yeniden deneme aralığı için geri çekilmesi gerekir. Geri alma işlemine saygı duymanız, yeniden denemeler arasında beklemeye 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, makinenin CPU veya ağ kullanımına odaklanması nedeniyle istemci uygulaması performans sorununa neden olabilir. Bu noktaya ulaşırsanız istemci uygulamalarınızın ölçeğini birden çok sunucu arasında genişleterek Azure Cosmos DB hesabını daha fazla göndermeye devam edebilirsiniz.

• Ad tabanlı adresleme kullanma

  Bağlantıların, bağlantıyı oluşturmak için kullanılan tüm kaynakların ResourceId'lerini almaktan kaçınma biçimine dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentIdsahip SelfLinks (_self) yerine biçiminde dbs/<database_rid>/colls/<collection_rid>/docs/<document_rid> olduğu ad tabanlı adresleme kullanı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 Zaman Uyumsuz Java SDK'sı v2, GÇ'nin engelini kaldırmak için netty kullanır. SDK, GÇ işlemlerini yürütmek için sabit sayıda GÇ Netty olay döngüsü iş parçacığı (makinenizdeki CPU çekirdeklerinin sayısı kadar) kullanır. API tarafından döndürülen Observable, paylaşılan GÇ olay döngüsü netty 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 önemlidir. GÇ olay döngüsü netty iş parçacığında YOĞUN CPU kullanımı gerektiren iş veya engelleme işlemi yapmak kilitlenmeye neden olabilir veya SDK 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:

  Zaman uyumsuz 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ı, Bağlan ionPolicy ö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.