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

  • Makale

UYGULANANLAR: NoSQL

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çeği artırma ve azaltma, tek bir API çağrısı yapmak kadar kolaydır. Daha fazla bilgi edinmek için bkz . Kapsayıcı aktarım hızı sağlama veya veritabanı aktarım hızı sağlama.

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çma

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

İ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ına göre sınıra ulaşmış olmasıdır. 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.

Not

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

Meta veri işlemleri

Ve/veya sık erişimli yolda ve/veya öğe işlemi yapmadan önce veritabanının Create...IfNotExistsAsync ve/veya Read...Async Kapsayıcının var olduğunu 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üğe kaydetme 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ışı bırakıldığından 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:

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
}

Ağ

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

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

string connectionString = "<your-account-connection-string>";
CosmosClient client = new CosmosClient(connectionString,
new CosmosClientOptions
{
    ConnectionMode = ConnectionMode.Gateway // ConnectionMode.Direct is the default
});

Kısa ömürlü bağlantı noktası 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.IdleTcp Bağlan ionTimeout ö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.

aynı bölgedeki istemcileri birlikte yerleştirin.

İş 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ş yapılan 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 yolu içinde satır içinde olması yalnızca iletişim kanalındaki gecikmeyi ve değişim süresini artırmakla kalır, 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'in hızlandırılmış ağı yoktur.

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. Zaman uyumsuz API'ler, küçük bir iş parçacığı havuzunun çağrıları engellemeyi beklemeyerek binlerce eşzamanlı isteği işlemesine olanak sağlar. İş parçacığı, uzun süre çalışan bir zaman uyumlu görevin tamamlanmasını beklemek yerine başka bir istekte ç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 alma. 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 zaman uyumlu bir şekilde boşaltmak için engelleme çağrılarını kullanan ToList() Container.GetItemLinqQueryable<T>() 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.
  • Zaman uyumsuz/await desenlerinden yararlanmak için çağrı yığınının tamamı zaman uyumsuzdur.

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

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

Yükü yoğun olan iş yükleri için istek seçeneğini olarak falseayarlayınEnableContentResponseOnWrite. Hizmet artık oluşturulan veya güncelleştirilmiş kaynağı SDK'ya döndürmez. Normalde, uygulama oluşturulan nesneye sahip olduğundan, hizmetin döndürmesi gerekmez. Üst bilgi değerlerine istek ücreti gibi yine erişilebilir. SDK'nın artık bellek ayırması veya yanıtın gövdesini seri hale getirmesi gerekmeyen 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 süresi yerine aktarım hızını iyileştirmek için Toplu'nun etkinleştirilmesi

İş 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'yi 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ş.

Ağ Geçidi modunu kullanırken konak başına en fazla System.Net Bağlan sayısını artırın

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.Default Bağlan ionLimit 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ündeki İş parçacığı/görev sayısını artırma bölümüne 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 arasında evrensel disk biçimi (UDF) dosyalarıyla ilişkisel ve hiyerarşik sorgular, saklı yordamlar ve tetikleyiciler bulunur 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-charge üst bilgisini (veya .NET SDK'sında ResourceResponse<T> veya FeedResponse<T> içindeki eşdeğer RequestCharge özelliği) inceleyerek iş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ı.

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

Örneğini ayarlayarak RetryOptionsCosmosClientOptions varsayılan yeniden deneme sayısını 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, 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 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 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.