Azure Cosmos DB ve .NET için performans ipuçları

UYGULANIR: NoSQL

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

Azure Cosmos DB, garantili gecikme süresi ve aktarım hızı düzeyleriyle sorunsuz bir şekilde ölçeklendirilen hızlı, 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çek büyütme ve küçültme, tek bir API çağrısı yapmak kadar kolaydır. Daha fazla bilgi edinmek için kapsayıcı aktarım hızı sağlama veya veritabanı aktarım hızı sağlama bölümlerine bakın.

Azure Cosmos DB'ye ağ çağrıları aracılığıyla erişildiğinden, SQL .NET SDK'sını kullanırken en yüksek performansı elde etmek için istemci tarafı iyileştirmeleri yapabilirsiniz.

Veritabanı performansınızı geliştirmeye çalışıyorsanız, aşağıdaki bölümlerde sunulan seçenekleri göz önünde bulundurun.

Barındırma önerileri

Sunucu tarafı çöp toplamayı aç

Çöp toplama sıklığını azaltmak bazı durumlarda yardımcı olabilir. .NET'te gcServer'ı.

İstemci iş yükünüzün ölçeğini genişletme

Yüksek aktarım hızı düzeylerinde veya saniyede 50.000 İstek Biriminden (RU/sn) daha yüksek hızlarda test ediyorsanız, istemci uygulaması bir iş yükü performans sorununa neden olabilir. Bunun nedeni, makinenin CPU veya ağ kullanımında sınıra ulaşması olabilir. Bu noktaya ulaşırsanız, istemci uygulamalarınızı birden çok sunucuya yayarak Azure Cosmos DB hesabınızı daha da genişletebilirsiniz.

Not

Yüksek CPU kullanımı gecikme süresinin artmasına neden olabilir ve zaman aşımı özel durumları isteyebilir.

Meta veri işlemleri

Performans yolunda ve/veya bir öğe işlemi gerçekleştirilmeden önce veritabanının ve/veya kapsayıcının var olduğunu Create...IfNotExistsAsync ve/veya Read...Async çağırarak doğrulamayın. Doğrulama yalnızca gerekli olduğunda, bunların silinmesini bekliyorsanız (aksi takdirde gerekli değildir) uygulama başlangıcında yapılmalıdır. Bu meta veri işlemleri fazladan uçtan uca gecikme süresi oluşturur, SLA içermez ve veri işlemleri gibi ölçeklendirilmeyen kendi ayrı sınırlamaları vardır.

Günlük Kaydı ve İzleme

Bazı ortamlarda .NET DefaultTraceListener etkindir. DefaultTraceListener, yüksek CPU ve G/Ç performans sorunlarına neden olan üretim ortamlarında performans sorunları oluşturur. Üretim ortamlarında TraceListeners'dan kaldırarak uygulamanız için DefaultTraceListener'ın devre dışı olduğundan emin olun.

En son SDK sürümleri (3.23.0'dan büyük) algıladığında otomatik olarak kaldırır, eski sürümlerle şunları yaparak kaldırabilirsiniz:

.NET 6 / .NET Core

if (!Debugger.IsAttached)
{
    Type defaultTrace = Type.GetType("Microsoft.Azure.Cosmos.Core.Trace.DefaultTrace,Microsoft.Azure.Cosmos.Direct");
    TraceSource traceSource = (TraceSource)defaultTrace.GetProperty("TraceSource").GetValue(null);
    traceSource.Listeners.Remove("Default");
    // Add your own trace listeners
}

.NET Framework

app.config veya web.config dosyalarınızı düzenleyin.

<configuration>
  <system.diagnostics>
    <sources>
      <source name="DocDBTrace" switchName="SourceSwitch" switchType="System.Diagnostics.SourceSwitch" >
        <listeners>
          <remove name="Default" />
          <!--Add your own trace listeners-->
          <add name="myListener" ... />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>
<configuration>

Yüksek kullanılabilirlik

Azure Cosmos DB'de yüksek kullanılabilirliği yapılandırma hakkında genel yönergeler için bkz . Azure Cosmos DB'de yüksek kullanılabilirlik.

Veritabanı platformunda iyi bir temel kuruluma ek olarak, kesinti senaryolarında yardımcı olabilecek .NET SDK'sının kendisinde uygulanabilecek belirli teknikler vardır. Eşik tabanlı kullanılabilirlik stratejisi ve bölüm düzeyi devre kesici iki önemli stratejidir.

Eşik tabanlı kullanılabilirlik stratejisi

Eşik tabanlı kullanılabilirlik stratejisi, ikincil bölgelere paralel okuma istekleri göndererek (içinde ApplicationPreferredRegionstanımlandığı gibi) ve en hızlı yanıtı kabul ederek kuyruk gecikme süresini ve kullanılabilirliğini geliştirebilir. Bu yaklaşım, bölgesel kesintilerin veya yüksek gecikme süresi koşullarının uygulama performansı üzerindeki etkisini önemli ölçüde azaltabilir.

Örnek yapılandırma:

Bunu yapılandırmak için CosmosClientBuilder kullanılabilir.

CosmosClient client = new CosmosClientBuilder("connection string")
    .WithApplicationPreferredRegions(
        new List<string> { "East US", "East US 2", "West US" } )
    .WithAvailabilityStrategy(
        AvailabilityStrategy.CrossRegionHedgingStrategy(
        threshold: TimeSpan.FromMilliseconds(500),
        thresholdStep: TimeSpan.FromMilliseconds(100)
     ))
    .Build();

Ya da seçenekleri yapılandırarak ve bu seçenekleri 'ye CosmosClientekleyerek:

CosmosClientOptions options = new CosmosClientOptions()
{
    AvailabilityStrategy
     = AvailabilityStrategy.CrossRegionHedgingStrategy(
        threshold: TimeSpan.FromMilliseconds(500),
        thresholdStep: TimeSpan.FromMilliseconds(100)
     )
      ApplicationPreferredRegions = new List<string>() { "East US", "East US 2", "West US"},
};

CosmosClient client = new CosmosClient(
    accountEndpoint: "account endpoint",
    authKeyOrResourceToken: "auth key or resource token",
    clientOptions: options);

Nasıl çalışır:

1. İlk İstek: T1 zamanında, birincil bölgeye (örneğin, Doğu ABD) bir okuma isteği yapılır. SDK, 500 milisaniyeye ( threshold değer) kadar yanıt bekler.

2. İkinci İstek: Birincil bölgeden 500 milisaniye içinde yanıt alınmazsa, bir sonraki tercih edilen bölgeye paralel istek gönderilir (örneğin, Doğu ABD 2).

3. Üçüncü İstek: Birincil veya ikincil bölge 600 milisaniye (500ms + 100ms, thresholdStep değer) içinde yanıt vermezse SDK, tercih edilen üçüncü bölgeye (örneğin, Batı ABD) başka bir paralel istek gönderir.

4. En Hızlı Yanıt Kazanır: İlk olarak hangi bölge yanıt verirse yanıt kabul edilir ve diğer paralel istekler yoksayılır.

Not

İlk tercih edilen bölge geçici olmayan bir hata durum kodu (örneğin, belge bulunamadı, yetkilendirme hatası, çakışma vb.) döndürürse, kullanılabilirlik stratejisinin bu senaryoda herhangi bir avantajı olmadığından işlemin kendisi hızlı başarısız olur.

Bölüm düzeyi devre kesici

Bölüm düzeyi devre kesici (PPCB), .NET SDK'sında iyi durumda olmayan fiziksel bölümleri izleyerek kullanılabilirliği ve gecikme süresini geliştiren bir özelliktir. Etkinleştirildiğinde, isteklerin daha sağlıklı bölgelere yönlendirilmesine yardımcı olur ve bölgesel veya bölüme özgü sorunlardan kaynaklanan art arda hataları önler. Bu özellik arka uç tarafından tetiklenen yük devretmeden bağımsızdır ve ortam değişkenleri aracılığıyla denetlenmektedir.

Bu özellik varsayılan olarak devre dışıdır, ancak bölüm düzeyi yük devretme etkinleştirildiğinde otomatik olarak etkinleştirilir .

Nasıl çalışır?

1. Hata Algılama: , 408 Request Timeoutveya iptal belirteçleri gibi 503 Service Unavailablebelirli hatalar gözlemlendiğinde, SDK bir bölüm için ardışık hataları sayar.
2. Yük Devretmenin Tetiklenmesi: Ardışık hata eşiği yapılandırıldıktan sonra SDK, GlobalPartitionEndpointManagerCore.TryMarkEndpointUnavailableForPartitionKeyRange kullanarak bu bölüm anahtarı aralığına yönelik istekleri bir sonraki tercih edilen bölgeye yönlendirir.
3. Arka Plan Kurtarma: Yük devretme sırasında, dört çoğaltmanın tümüne bağlanmaya çalışılarak başarısız bölümün sistem durumunu düzenli aralıklarla yeniden değerlendirmek için bir arka plan görevi başlatılır. SDK, sağlıklı duruma geri döndüğünde devre dışı bırakmayı kaldırır ve birincil bölgeye geri döner.

Hesap türüne göre davranış

• Tek bölgeli yazma (tek ana öğe): Yalnızca okuma istekleri PPCB yük devretme mantığına katılır.
• Çok bölgeli yazma (çoklu ana makine):Hem okuma hem de yazma istekleri PPCB yük devretme mantığını kullanır.

Yapılandırma seçenekleri

PPCB'yi yapılandırmak için aşağıdaki ortam değişkenlerini kullanın:

Ortam değişkeni	Açıklama	Varsayılan
AZURE_COSMOS_CIRCUIT_BREAKER_ENABLED	PPCB özelliğini etkinleştirir/devre dışı bırakır.	false
AZURE_COSMOS_PPCB_CONSECUTIVE_FAILURE_COUNT_FOR_READS	Yük devretmeyi tetikleyen ardışık okuma hataları.	10
AZURE_COSMOS_PPCB_CONSECUTIVE_FAILURE_COUNT_FOR_WRITES	Arka arkaya yazma hataları, yedekleme işlemini tetikler.	5
AZURE_COSMOS_PPCB_ALLOWED_PARTITION_UNAVAILABILITY_DURATION_IN_SECONDS	Bölüm durumunu yeniden değerlendirmeden önceki süre.	5 Saniye
AZURE_COSMOS_PPCB_STALE_PARTITION_UNAVAILABILITY_REFRESH_INTERVAL_IN_SECONDS	Bölüm durumunun arka plan yenileme aralığı.	60 Saniye

Not

SDK şu anda okumalar için güvenilir bir geri dönüş tetikleyicisine sahip değildir. Bunun yerine, arka plan sağlık kontrol sistemi, dört replikanın da yanıt verdiği durumda orijinal bölgeyi kademeli olarak yeniden etkinleştirmeyi dener.

Kullanılabilirlik iyileştirmelerini karşılaştırma

• Eşik tabanlı kullanılabilirlik stratejisi:

  • Avantaj: İkincil bölgelere paralel okuma istekleri göndererek kuyruk gecikme süresini azaltır ve ağ zaman aşımlarına neden olacak istekleri önceden başlatarak kullanılabilirliği artırır.
  • Trade-off: Ek paralel bölgeler arası istekler nedeniyle (ancak eşikler aşıldığında) circuit breaker'a kıyasla ek RU (İstek Birimleri) maliyetlerine neden olur.
  • Kullanım Örneği: Gecikme süresini azaltmanın kritik öneme sahip olduğu ve bazı ek maliyetlerin (HEM RU ücreti hem de istemci CPU baskısı açısından) kabul edilebilir olduğu okuma yoğunluklu iş yükleri için idealdir. İdempotent olmayan yazma yeniden deneme politikası tercih edilirse ve hesapta çok bölgeli yazmalar varsa, yazma işlemleri de yararlı olabilir.

• Bölüm düzeyi devre kesici:

  • Avantaj: İyi durumda olmayan bölümlerden kaçınarak isteklerin daha sağlıklı bölgelere yönlendirilmesini sağlayarak kullanılabilirliği ve gecikme süresini artırır.
  • Denge: Daha fazla RU maliyetine neden olmaz, ancak yine de ağ zaman aşımlarına neden olabilecek istekler için başlangıçta kullanılabilirlik kaybına izin verebilir.
  • Kullanım Örneği: Özellikle aralıklı olarak iyi durumda olmayan bölümlerle ilgilenirken tutarlı performansın önemli olduğu yoğun yazma veya karma iş yükleri için idealdir.

Okuma ve yazma kullanılabilirliğini geliştirmek ve kuyruk gecikme süresini azaltmak için her iki strateji de birlikte kullanılabilir. Bölüm Düzeyi Devre Kesici, paralel istekler yapmaya gerek kalmadan, çoğaltmaların yavaş çalışmasına neden olabilecekler de dahil olmak üzere çeşitli geçici hata durumlarını yönetebilir. Ek olarak, Ek RU maliyeti kabul edilebilirse Eşik Tabanlı Kullanılabilirlik Stratejisi eklemek kuyruk gecikme süresini daha da en aza indirir ve kullanılabilirlik kaybını ortadan kaldırır.

Geliştiriciler bu stratejileri uygulayarak uygulamalarının dayanıklı kalmasını, yüksek performansı korumasını ve bölgesel kesintiler veya yüksek gecikme süresi koşulları sırasında bile daha iyi bir kullanıcı deneyimi sunmasını sağlayabilir.

Ağ

Bağlantı ilkesi: Doğrudan bağlantı modunu kullanma

.NET V3 SDK varsayılan bağlantı modu TCP protokolü ile doğrudan yapılır. Bağlantı modunu CosmosClient örneğini CosmosClientOptions içinde oluştururken yapılandırırsınız. Farklı bağlantı seçenekleri hakkında daha fazla bilgi edinmek için bağlantı modları makalesine bakın.

CosmosClient client = new CosmosClient(
  "<nosql-account-endpoint>",
  tokenCredential
  new CosmosClientOptions
  {
      ConnectionMode = ConnectionMode.Gateway // ConnectionMode.Direct is the default
  }
);

Geçici port tükenmesi

Örneklerinizde yüksek bağlantı hacmi veya yüksek bağlantı noktası kullanımı görürseniz, önce istemci örneklerinizin tekil olduğunu doğrulayın. Başka bir deyişle, istemci örnekleri uygulamanın ömrü boyunca benzersiz olmalıdır.

TCP protokolünde çalışırken istemci, uzun süreli bağlantıları kullanarak gecikme süresi için iyileştirmeler gerçekleştirir. Bu, iki dakika etkinlik dışı kalma süresinden sonra bağlantıları sonlandıran HTTPS protokolünün aksinedir.

Seyrek erişime sahip olduğunuz senaryolarda ve Ağ Geçidi modu erişimine kıyasla daha yüksek bir bağlantı sayısı fark ederseniz şunları yapabilirsiniz:

• CosmosClientOptions.PortReuseMode özelliğini olarak PrivatePortPool yapılandırın (çerçeve sürümleri 4.6.1 ve üzeri ve .NET Core sürüm 2.0 ve üzeri ile etkindir). Bu özellik, SDK'nın çeşitli Azure Cosmos DB hedef uç noktaları için kısa ömürlü bağlantı noktalarının küçük bir havuzunu kullanmasına olanak tanır.
• CosmosClientOptions.IdleTcpConnectionTimeout özelliğini 10 dakikadan büyük veya buna eşit olarak yapılandırın. Önerilen değerler 20 dakika ile 24 saat arasındadır.

Performans için istemcileri aynı Azure bölgesinde birlikte yerleştirin

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: Aynı bölge içindeki Azure Cosmos DB çağrıları 1 milisaniye (ms) ile 2 ms arasında tamamlanır, ancak ABD'nin Batı ve Doğu kıyısı arasındaki gecikme süresi 50 ms'den fazladır. 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 olarak mümkün olan en düşük gecikme süresini alabilirsiniz. Kullanılabilir bölgelerin listesi için bkz . Azure bölgeleri.

İş parçacığı/görev sayısını artırma

Azure Cosmos DB'ye yapılan çağrılar ağ üzerinden yapıldığından, istemci uygulamasının istekler arasında beklemeye en az zaman harcaması için isteklerinizin eşzamanlılık derecesini değiştirmeniz gerekebilir. Örneğin, .NET Görev Paralel Kitaplığı'nı kullanıyorsanız, Azure Cosmos DB'den okunan veya Azure Cosmos DB'ye yazılan yüzlerce görev sırasına göre oluşturun.

Gecikme süresini ve CPU değişimlerini azaltmak için hızlandırılmış ağı etkinleştirme

Performansı en üst düzeye çıkarmak için Windows(yönergeler için tıklayın) veya Linux (yönergeler için tıklayın) Azure VM'nizde Hızlandırılmış Ağ'ı etkinleştirmek için yönergeleri izlemeniz önerilir.

Hızlandırılmış ağ olmadan, Azure VM'nizle diğer Azure kaynakları arasında geçiş yapan G/Ç, VM ile ağ kartı arasında yer alan bir konak ve sanal anahtar üzerinden gereksiz yere yönlendirilebilir. Ana bilgisayar ve sanal anahtarın veri yolunda satır içinde yer alması, yalnızca iletişim kanalındaki gecikmeyi ve dalgalanmayı artırmakla kalmaz, aynı zamanda VM'den CPU döngülerini de çalar. Hızlandırılmış ağ ile VM, aracı olmadan doğrudan NIC ile arabirim oluşturur; Konak ve sanal anahtar tarafından işlenen tüm ağ ilkesi ayrıntıları artık NIC'deki donanımda işlenir; konak ve sanal anahtar atlanır. Genellikle daha düşük gecikme süresi ve daha yüksek aktarım hızının yanı sıra hızlandırılmış ağı etkinleştirdiğinizde daha tutarlı gecikme süresi ve daha az CPU kullanımı bekleyebilirsiniz.

Sınırlamalar: Hızlandırılmış ağ VM işletim sisteminde desteklenmeli ve yalnızca VM durdurulduğunda ve serbest bırakıldığında etkinleştirilebilir. VM, Azure Resource Manager ile dağıtılamaz. App Service'de hızlandırılmış ağ etkinleştirilmedi.

Daha fazla ayrıntı için lütfen Windows ve Linux yönergelerine bakın.

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 bkz . Azure Cosmos DB SDK'sı.

Akış API'lerini kullanma

.NET SDK V3 , seri hale getirmeden veri alabilen ve döndürebilen akış API'leri içerir.

Doğrudan SDK'dan gelen yanıtları kullanmayan ancak bunları diğer uygulama katmanlarına aktaran orta katman uygulamalar, akış API'lerinden yararlanabilir. Akış işleme örnekleri için bkz . öğe yönetimi örnekleri.

Uygulamanızın ömrü boyunca tek bir Azure Cosmos DB istemcisi kullanma

Her CosmosClient örnek iş parçacığı açısından güvenlidir ve Doğrudan modda çalışırken verimli bağlantı yönetimi ve adres önbelleğe alma işlemi gerçekleştirir. Verimli bağlantı yönetimine ve daha iyi SDK istemci performansına izin vermek için, uygulamanızın etkileşimde bulunduğu her hesap için uygulamanın kullanım ömrü boyunca tek AppDomain bir örnek kullanmanızı öneririz.

Birden çok hesabı işleyen çok kiracılı uygulamalar için ilgili en iyi yöntemlere bakın.

Azure İşlevleri üzerinde çalışırken örneklerin de mevcut yönergeleri izlemesi ve tek bir örneği koruması gerekir.

Aramaları engellemekten kaçının

Azure Cosmos DB SDK'sı, birçok isteği aynı anda işlenecek şekilde tasarlanmalıdır. Asenkron API'ler, bloklama çağrılarını beklemeyerek küçük bir iş parçacığı havuzunun binlerce eşzamanlı isteği işlemesine olanak sağlar. İş parçacığı, uzun süre çalışan bir eşzamanlı görevin tamamlanmasını beklemek yerine başka bir isteğe çalışabilir.

Azure Cosmos DB SDK'sını kullanan uygulamalarda sık karşılaşılan bir performans sorunu, zaman uyumsuz olabilecek çağrıları engelliyor. Birçok zaman uyumlu engelleme çağrısı, İş Parçacığı Havuzu aç kalmasına ve yanıt sürelerinin düşmesine yol açar.

Aşağıdakileri yapma:

• Task.Wait veya Task.Result çağrısı yaparak zaman uyumsuz yürütmeyi engelleyin.
• Zaman uyumlu API'yi zaman uyumsuz yapmak için Task.Run kullanın.
• Ortak kod yollarında kilitleri al. Azure Cosmos DB .NET SDK'sı, kod paralel olarak çalıştırılacak şekilde tasarlandığında en yüksek performansı gösterir.
• Task.Run'ı çağırıp hemen beklemeye devam edin. ASP.NET Core, uygulama kodunu normal İş Parçacığı Havuzu iş parçacıklarında zaten çalıştırdığından Task.Run çağrısı yalnızca gereksiz İş Parçacığı Havuzu zamanlaması sağlar. Zamanlanan kod bir iş parçacığını engellese bile, Task.Run bunu önlemez.
• Engelleme çağrılarını kullanarak sorguyu senkronize bir şekilde boşaltan Container.GetItemLinqQueryable<T>() üzerinde ToList() kullanmayın. Sorguyu zaman uyumsuz olarak boşaltmak için ToFeedIterator() kullanın.

Yap:

• Azure Cosmos DB .NET API'lerini zaman uyumsuz olarak çağırın.
• Async/await desenlerinden yararlanmak amacıyla çağrı yığınının tamamı zaman uyumsuz şekilde çalışır.

PerfView gibi bir profil oluşturucu, İş Parçacığı Havuzuna sık sık eklenen iş parçacıklarını bulmak için kullanılabilir. Microsoft-Windows-DotNETRuntime/ThreadPoolWorkerThread/Start olayı, iş parçacığı havuzuna eklenen bir iş parçacığını belirtir.

Yazma işlemlerinde içerik yanıtlarını devre dışı bırakma

Oluşturma yükleri fazla olan iş yükleri için EnableContentResponseOnWrite istek seçeneğini false olarak ayarlayın. Hizmet artık oluşturulan veya güncelleştirilmiş kaynağı SDK'ya döndürmez. Normalde, uygulama oluşturulan nesneye sahip olduğundan, hizmetin nesneyi geri döndürmesine gerek yoktur. Başlık değerleri, istek ücreti gibi bilgilere hâlâ erişilebilir. SDK artık bellek ayırmak veya yanıtın gövdesini serileştirmek zorunda kalmayacağı için içerik yanıtını devre dışı bırakmak performansın geliştirilmesine yardımcı olabilir. Ayrıca performansa daha fazla yardımcı olmak için ağ bant genişliği kullanımını azaltır.

ItemRequestOptions requestOptions = new ItemRequestOptions() { EnableContentResponseOnWrite = false };
ItemResponse<Book> itemResponse = await this.container.CreateItemAsync<Book>(book, new PartitionKey(book.pk), requestOptions);
// Resource will be null
itemResponse.Resource

Gecikme yerine aktarım hızını iyileştirmek için Toplu'yu etkinleştir

İş yükünün büyük miktarda aktarım hızı gerektirdiği ve gecikme süresinin o kadar önemli olmadığı senaryolar için Toplu modunu etkinleştirin. Toplu özelliğini etkinleştirme hakkında daha fazla bilgi edinmek ve hangi senaryolar için kullanılması gerektiğini öğrenmek için bkz Toplu Desteğe Giriş.

Gateway modunu kullanırken her ana bilgisayar için System.Net Maksimum Bağlantılar artırma

Azure Cosmos DB istekleri, Ağ Geçidi modunu kullandığınızda HTTPS/REST üzerinden yapılır. Ana bilgisayar adı veya IP adresi başına varsayılan bağlantı sınırına tabidir. İstemci kitaplığının Azure Cosmos DB'ye birden çok eşzamanlı bağlantı kullanabilmesi için daha yüksek bir değere (100 ile 1.000 arasında) ayarlamanız MaxConnections gerekebilir. .NET SDK 1.8.0 ve sonraki sürümlerinde, ServicePointManager.DefaultConnectionLimit için varsayılan değer 50'dir. Değeri değiştirmek için daha yüksek bir değere ayarlayabilirsiniz Documents.Client.ConnectionPolicy.MaxConnectionLimit .

İş parçacığı/görev sayısını artırma

Bu makalenin Ağ oluşturma bölümünde bulunan İş parçacığı/görev sayısını artırma kısmına bakın.

Sorgu işlemleri

Sorgu işlemleri için sorgular için performans ipuçlarına bakın.

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 dizin oluşturma ilkesi, dizin oluşturma yollarını (IndexingPolicy.IncludedPaths ve IndexingPolicy.ExcludedPaths) kullanarak hangi belge yollarının dizine ekleneceğini veya dizin oluşturmanın dışında tutulacağını belirtmenize de olanak tanır.

Yalnızca ihtiyacınız olan yolları dizine eklemek yazma performansını artırabilir, yazma işlemlerinde RU ücretlerini azaltabilir ve sorgu desenlerinin önceden bilindiği senaryolar için dizin depolama alanını azaltabilir. Bunun nedeni, dizin oluşturma maliyetlerinin doğrudan dizine alınan benzersiz yol sayısıyla bağıntılı olmasıdır. Örneğin, aşağıdaki kodda "*" joker karakteri kullanılarak belgelerin (alt ağaç) bir bölümünün tamamının dizin oluşturma işleminin dışında tutulması gösterilmektedir:

var containerProperties = new ContainerProperties(id: "excludedPathCollection", partitionKeyPath: "/pk" );
containerProperties.IndexingPolicy.IncludedPaths.Add(new IncludedPath { Path = "/*" });
containerProperties.IndexingPolicy.ExcludedPaths.Add(new ExcludedPath { Path = "/nonIndexedContent/*");
Container container = await this.cosmosDatabase.CreateContainerAsync(containerProperties);

Daha fazla bilgi için bkz . Azure Cosmos DB dizin oluşturma ilkeleri.

Aktarım hızı

Daha düşük RU/sn kullanımı için ölçme ve ayarlama

Azure Cosmos DB zengin bir veritabanı işlemleri kümesi sunar. Bu işlemler kullanıcı tanımlı işlevler (UDF' ler), saklı yordamlar ve tetikleyiciler içeren ilişkisel ve hiyerarşik sorguları içerir ve bunların tümü bir veritabanı koleksiyonundaki belgeler üzerinde çalışır.

Bu işlemlerin her biriyle ilişkili maliyetler, işlemi tamamlamak için gereken CPU, GÇ ve belleğe bağlı olarak değişir. Donanım kaynaklarını düşünmek ve yönetmek yerine, bir İstek Birimi'ni ç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 İstek Birimi sayısına göre sağlanır. İstek Birimi tüketimi saniye başına birim oranı olarak değerlendirilir. Kapsayıcıları için sağlanan İstek 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 İstek Birimleri sağlayarak aktarım hızınızı artırabilirsiniz.

Bir sorgunun karmaşıklık düzeyi, işlem için kullanılan istek birimi sayısını etkiler. Koşulların sayısı, koşulların yapısı, UDF dosyalarının sayısı ve kaynak veri kümesinin boyutu sorgu işlemlerinin maliyetini etkiler.

Herhangi bir işlemin (oluşturma, güncelleştirme veya silme) yükünü ölçmek için x-ms-request-chargeişlemler tarafından kullanılan İstek Birimi sayısını ölçün:

// Measure the performance (Request Units) of writes
ItemResponse<Book> response = await container.CreateItemAsync<Book>(myBook, new PartitionKey(myBook.PkValue));
Console.WriteLine("Insert of item consumed {0} request units", response.RequestCharge);
// Measure the performance (Request Units) of queries
FeedIterator<Book> queryable = container.GetItemQueryIterator<ToDoActivity>(queryString);
while (queryable.HasMoreResults)
    {
        FeedResponse<Book> queryResponse = await queryable.ExecuteNextAsync<Book>();
        Console.WriteLine("Query batch consumed {0} request units", queryResponse.RequestCharge);
    }

Bu üst bilgide döndürülen istek ücreti, sağlanan aktarım hızınızın (yani 2.000 RU/sn) bir bölümüdür. Örneğin, önceki sorgu 1.000 1 KB belge döndürürse, işlemin maliyeti 1.000'dir. Bu nedenle, sunucu bir saniye içinde, daha sonraki istekleri sınırlamadan önce bu tür iki isteği kabul eder. Daha fazla bilgi için bkz . İstek Birimleri ve İstek 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 sona erdirir. Kullanıcının isteği yeniden denemeden önce beklemesi gereken süreyi milisaniye cinsinden belirten bir x-ms-retry-after-ms üst bilgisi 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, şu anda istemci tarafından dahili olarak 9 olarak ayarlanmış olan varsayılan yeniden deneme sayısı yeterli olmayabilir. Bu durumda istemci, uygulamaya durum kodu 429 olan bir CosmosException oluşturur.

Varsayılan yeniden deneme sayısını, RetryOptions örneğindeki CosmosClientOptions ayarını yaparak değiştirebilirsiniz. Varsayılan olarak, istek istek hızının üzerinde çalışmaya devam ederse 30 saniyelik bir kümülatif bekleme süresinden sonra durum kodu 429 olan CosmosException döndürülür. Geçerli yeniden deneme sayısı, varsayılan değer olan 9 veya kullanıcı tanımlı bir değer olsa bile, maksimum yeniden deneme sayısından az olduğunda bu hata döndürülür.

Otomatik yeniden deneme davranışı, çoğu uygulama için dayanıklılığı ve kullanılabilirliği geliştirmeye yardımcı olur. Ancak bu, özellikle gecikme süresini ölçerken performans karşılaştırmaları yaparken en iyi davranış olmayabilir. 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 testleri sırasında gecikme süresi artışlarını önlemek için her işlemde dönen yükü ölçün ve isteklerin belirlenmiş 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 için tasarım

Belirtilen işlemin istek ücreti (yani istek işleme maliyeti), doğrudan belgenin boyutuyla ilişkilendirilir. Büyük belgelerdeki işlemler, küçük belgelerdeki işlemlerden daha pahalıdır.

Sonraki adımlar

Azure Cosmos DB'yi birkaç istemci makinesinde yüksek performanslı senaryolar için değerlendirmek için kullanılan örnek bir uygulama için bkz . Azure Cosmos DB ile performans ve ölçek testi.

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.