Aracılığıyla paylaş

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

  • Şunlara uygulanır: ✅ NoSQL

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çek büyütme ve küçültme, tek bir API çağrısı yapmak kadar kolaydır. Daha fazla bilgi edinmek için bkz. Kapsayıcı aktarım hızını sağlama veya veritabanı aktarım hızı sağlama. Ancak 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.

Bu nedenle, veritabanınızın performansını geliştirmeye çalışıyorsanız şu seçenekleri göz önünde bulundurun:

.NET V3 SDK'sına yükseltme

.NET v3 SDK'sı yayınlanır. .NET v3 SDK'sını kullanıyorsanız, aşağıdaki bilgiler için .NET v3 performans kılavuzuna bakın:

  • Varsayılan olarak Doğrudan TCP moduna geçer
  • Stream API desteği
  • System.Text.JSON kullanımına izin vermek için özel seri hale getiriciyi destekleme
  • Tümleşik toplu iş ve yığın destek

Barındırma önerileri

Sunucu tarafı çöp toplamayı (GC) açın

Çö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 (50.000 RU/sn'den fazla) test ediyorsanız, makinenin CPU veya ağ kullanımı sınırına ulaşması nedeniyle istemci uygulaması darboğaz olabilir. Bu noktaya ulaşırsanız, istemci uygulamalarınızı birden çok sunucuya yayarak Azure Cosmos DB hesabınızı daha da genişletebilirsiniz.

Uyarı

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

Meta veri işlemleri

Sık erişim yolunda ve/veya bir öğe işlemi gerçekleştirmeden önce veritabanının ve/veya Koleksiyonun mevcut olduğunu Create...IfNotExistsAsync ve/veya Read...Async çağrısı yaparak 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.

Loglama ve izleme

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 (2.16.2'den büyük) algıladığında otomatik olarak kaldırır, eski sürümlerle şu şekilde kaldırabilirsiniz:

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

Ağ Kurma

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

.NET V2 SDK varsayılan bağlantı modu ağ geçididir. DocumentClient örneğinin oluşturulması sırasında ConnectionPolicy parametresini kullanarak bağlantı modunu yapılandırabilirsiniz. Doğrudan modu kullanıyorsanız, Protocol ayarını ConnectionPolicy parametresini kullanarak yapmanız gerekir. Farklı bağlantı seçenekleri hakkında daha fazla bilgi edinmek için bağlantı modları makalesine bakın.

Uri serviceEndpoint = new Uri("https://contoso.documents.net");
string authKey = "your authKey from the Azure portal";
DocumentClient client = new DocumentClient(serviceEndpoint, authKey,
new ConnectionPolicy
{
   ConnectionMode = ConnectionMode.Direct, // ConnectionMode.Gateway is the default
   ConnectionProtocol = Protocol.Tcp
});

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ıştırılırken istemci, HTTPS protokolü yerine uzun süreli bağlantıları kullanarak gecikme süresini iyileştirir ve bu da bağlantıları 2 dakika etkinlik dışı kaldıktan sonra sonlandırır.

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:

  • ConnectionPolicy.PortReuseMode özelliğini olarak PrivatePortPool yapılandırın (çerçeve sürümü>= 4.6.1 ve .NET core sürüm >= 2.0 ile geçerlidir): Bu özellik SDK'nın farklı Azure Cosmos DB hedef uç noktaları için kısa ömürlü bağlantı noktaları havuzunu kullanmasına olanak tanır.
  • ConnectionPolicy.IdleConnectionTimeout özelliğinin 10 dakikadan büyük veya buna eşit olması gerekir. Önerilen değerler 20 dakika ile 24 saat arasındadır.

İlk istekte başlatma gecikmesini önlemek için OpenAsync'i çağır

Varsayılan olarak, adres yönlendirme tablosunu getirmesi gerektiğinden ilk istek daha yüksek gecikme süresine sahiptir. SDK V2 kullandığınızda, ilk istekte bu başlatma gecikmesini önlemek için başlatma sırasında bir kez arayınOpenAsync(). Çağrı şöyle görünür: await client.OpenAsync();

Uyarı

OpenAsync , hesaptaki tüm kapsayıcılar için adres yönlendirme tablosunu almak için istekler oluşturur. Birçok kapsayıcıya sahip ancak uygulamalarının yalnızca belirli bir alt kümesine erişen hesaplar için, OpenAsync, gereksiz miktarda trafik oluşturarak başlatmanın yavaşlamasına neden olabilir. Bu nedenle, uygulama başlatmayı yavaşlattığı için kullanmak OpenAsync bu senaryoda yararlı olmayabilir.

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çinde Azure Cosmos DB'ye yapılan çağrılar 1 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ğıran 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.

Azure Cosmos DB bağlantı ilkesi

İş 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 paralellik 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.

Hızlandırılmış ağı etkinleştirme

Gecikme süresini ve CPU değişimini azaltmak için, istemci sanal makinelerinde hızlandırılmış ağı etkinleştirmenizi öneririz. Bkz. Hızlandırılmış ağ ile Windows sanal makinesi oluşturma veya Hızlandırılmış ağ ile Linux sanal makinesi oluşturma.

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 SDK sayfalarına bakın.

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

Her DocumentClient ö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ın kullanım ömrü boyunca tek AppDomain bir örnek kullanmanızı öneririz.

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 senkronize engelleme çağrısı iş parçacığı havuzu tükenmesine 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 engellemez.
  • Sorguyu senkronize bir şekilde boşaltmak için engelleme çağrılarını kullanan DocumentClient.CreateDocumentQuery(...) üzerinde ToList() kullanın. Sorguyu zaman uyumsuz olarak boşaltmak için AsDocumentQuery() kullanın.

Yap:

  • Azure Cosmos DB .NET API'lerini zaman uyumsuz olarak çağırın.
  • Tüm çağrı yığını async/await desenlerinden yararlanmak için eşzamanlı ç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.

Ağ geçidi modu kullanılırken konak başına System.Net MaxConnections'ı artırın

Ağ geçidi modunu kullandığınızda Azure Cosmos DB istekleri HTTPS/REST üzerinden yapılır. Ana bilgisayar adı veya IP adresi başına varsayılan bağlantı sınırına tabi tutulurlar. İstemci kitaplığının Azure Cosmos DB'ye birden çok eşzamanlı bağlantı kullanabilmesi için daha yüksek bir değere (100 - 1.000) 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 Documents.Client.ConnectionPolicy.MaxConnectionLimit değerini daha yüksek bir değere ayarlayabilirsiniz.

RetryAfter aralıklarında geri çekilme uygula

Performans testi sırasında, az sayıda istek azaltılana kadar yükü artırmanız gerekir. İstekler kısıtlanırsa istemci uygulaması, sunucu tarafından belirtilen yeniden deneme aralığı için kısıtlamayı geri çekmelidir. Geri çekilme süresine saygı göstermeniz, yeniden denemeler arasında en az süre beklemenizi sağlar.

Yeniden deneme ilkesi desteği şu SDK'lara dahildir:

Daha fazla bilgi için bkz. RetryAfter.

.NET SDK'sının 1.19 ve sonraki sürümlerinde, aşağıdaki örnekte gösterildiği gibi ek tanılama bilgilerini kaydetmek ve gecikme sorunlarını gidermek için bir mekanizma vardır. Okuma gecikmesi daha yüksek olan istekler için tanılama dizesini günlüğe kaydedebilirsiniz. Yakalanan tanılama dizesi, belirli bir istek için kaç kez 429 hata aldığınızı anlamanıza yardımcı olur.

ResourceResponse<Document> readDocument = await this.readClient.ReadDocumentAsync(oldDocuments[i].SelfLink);
readDocument.RequestDiagnosticsString

Daha düşük okuma gecikmesi için belge URI'lerini önbelleğe alma

En iyi okuma performansı için mümkün olduğunca belge URI'lerini önbelleğe alın. Kaynak oluştururken kaynak kimliğini önbelleğe almak için mantık tanımlamanız gerekir. Kaynak kimliklerini temel alan aramalar ad tabanlı aramalardan daha hızlıdır, bu nedenle bu değerleri önbelleğe almak performansı artırır.

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

Makalenin ağ bölümündeki İş parçacığı/görev sayısını artırma konusuna 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 dizin oluşturmada hangi belge yollarının ekleneceğini veya dizin oluşturmanın dışında tutulacağını belirtmenize de olanak tanır. Dizin oluşturma yolları, sorgu desenlerinin önceden bilindiği senaryolar için yazma performansını geliştirebilir ve 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, bu kod "*" joker karakteri kullanılarak belgelerin (bir alt ağaç) tüm bölümünün dizin oluşturmadan nasıl dışlandığını gösterir:

var collection = new DocumentCollection { Id = "excludedPathCollection" };
collection.IndexingPolicy.IncludedPaths.Add(new IncludedPath { Path = "/*" });
collection.IndexingPolicy.ExcludedPaths.Add(new ExcludedPath { Path = "/nonIndexedContent/*");
collection = await client.CreateDocumentCollectionAsync(UriFactory.CreateDatabaseUri("db"), collection);

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

Throughput

Daha düşük İstek Birimleri/saniye kullanımı için ölçme ve ayarlama

Azure Cosmos DB zengin bir veritabanı işlemleri kümesi sunar. Bu işlemler arasında UDF'ler, saklı yordamlar ve tetikleyiciler içeren ilişkisel ve hiyerarşik sorgular bulunur ve bunların tümü bir veritabanı koleksiyonundaki belgeler üzerinde çalışır. Bu işlemlerin her biriyle ilişkili maliyet, 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 (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 İstek 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 İ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.

Sorgunun karmaşıklığı, bir işlem için kaç İstek 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 (oluşturma, güncelleştirme veya silme) yükünü ölçmek için x-ms-request-charge üst bilgisini (veya .NET SDK'sında RequestCharge veya ResourceResponse\<T> içindeki eşdeğer FeedResponse\<T> özelliği) inceleyerek işlemler tarafından kullanılan İstek Birimi sayısını ölçün:

// Measure the performance (Request Units) of writes
ResourceResponse<Document> response = await client.CreateDocumentAsync(collectionSelfLink, myDocument);
Console.WriteLine("Insert of document consumed {0} request units", response.RequestCharge);
// Measure the performance (Request Units) of queries
IDocumentQuery<dynamic> queryable = client.CreateDocumentQuery(collectionSelfLink, queryString).AsDocumentQuery();
while (queryable.HasMoreResults)
    {
        FeedResponse<dynamic> queryResponse = await queryable.ExecuteNextAsync<dynamic>();
        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 / saniye) 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, sonraki istekleri sınırlamadan önce bir saniye içinde 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 sonlandıracaktır. 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, istemcinin dahili olarak varsayılan yeniden deneme sayısını şu anda 9 olarak ayarlaması yeterli olmayabilir. Bu durumda istemci, uygulamaya 429 durum koduna sahip bir DocumentClientException oluşturur.

Varsayılan yeniden deneme sayısını, RetryOptions örneğindeki ConnectionPolicy ayarını yaparak değiştirebilirsiniz. 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 hata, geçerli yeniden deneme sayısı en yüksek yeniden deneme sayısı değerinden küçük olsa bile (geçerli değerin varsayılan değer olarak 9 veya kullanıcı tanımlı bir değer olması fark etmeksizin) döndürü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 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 bkz İstek Birimleri.

Daha yüksek aktarım hızı için, daha küçük belgeler için tasarım

Belirli bir 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.

  • Last updated on