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

UYGULANDıĞı YER: SQL API

Azure Cosmos DB, garantili gecikme ve verimlilik ile sorunsuz bir şekilde ölçeklenen hızlı ve esnek bir dağıtılmış veritabanıdır. veritabanınızı Azure Cosmos DB ölçeklendirmek için önemli mimari değişiklikler 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ı verimini sağlama veya veritabanı verimini sağlama. ancak Azure Cosmos DB ağ çağrıları üzerinden erişildiği için, SQL .net SDK 'sınıkullandığınızda en yüksek performansa ulaşmak için kullanabileceğiniz istemci tarafı iyileştirmeler vardır.

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

.NET v3 SDK 'ya yükseltme

.Net v3 SDK yayımlandı. .NET v3 SDK kullanıyorsanız, aşağıdaki bilgiler için .net v3 performans Kılavuzu 'na bakın:

• Varsayılan olarak doğrudan TCP modu
• Akış API 'SI desteği
• Kullanım System.Text.JSizin vermek için özel seri hale getirici desteği
• Tümleşik toplu iş ve toplu destek

Barındırma önerileri

sorgu yoğunluklu iş yükleri için Linux veya Windows 32 bit konak işleme yerine Windows 64-bit kullanın

iyileştirilmiş performans için Windows 64 bit ana bilgisayar işlemeyi öneririz. SQL SDK, sorguları yerel olarak ayrıştırmak ve iyileştirmek için yerel bir ServiceInterop.dll içerir. ServiceInterop.dll yalnızca Windows x64 platformunda desteklenir. ServiceInterop.dll kullanılamadığı Linux ve diğer desteklenmeyen platformlar için, iyileştirilmiş sorguyu almak üzere ağ geçidine ek bir ağ çağrısı yapılır. Aşağıdaki uygulama türleri varsayılan olarak 32 bitlik ana bilgisayar işlemeyi kullanır. Ana bilgisayar işlemesini 64-bit işleme olarak değiştirmek için, uygulamanızın türüne göre aşağıdaki adımları izleyin:

• yürütülebilir uygulamalar için, yapı sekmesindeki Project özellikler penceresinde, platform hedefini x64 olarak ayarlayarak ana bilgisayar işlemesini değiştirebilirsiniz.

• vstest tabanlı test projeleri için, > Visual Studio test menüsünde X64 olarak test test Ayarlar > varsayılan işlemci mimarisini seçerek konak işlemeyi değiştirebilirsiniz.

• yerel olarak dağıtılan ASP.NET web uygulamaları için, araçlar seçenekler projeler ve çözümler web projeleri altındaki web siteleri ve projeler için IIS Express 64 bit sürümünü kullan ' ı seçerek konak işlemeyi değiştirebilirsiniz > > > .

• Azure 'da dağıtılan ASP.NET web uygulamaları için, Azure portal uygulama ayarlarında 64 bitlik platformu seçerek konak işlemeyi değiştirebilirsiniz.

Sunucu tarafı atık toplamayı aç (GC)

Çöp toplamanın sıklığını azaltmak bazı durumlarda yardımcı olabilir. .NET sürümünde gcServer olarak ayarlayın true .

İstemci iş yükünüzü ölçeklendirin

Yüksek aktarım hızı düzeylerinde (50.000 RU/sn 'den fazla) test ediyorsanız, istemci uygulaması makine CPU veya ağ kullanımında kullanıma hazır hale geldiği için performans sorunlarına neden olabilir. bu noktaya ulaştığınızda, istemci uygulamalarınızı birden çok sunucu arasında ölçeklendirerek Azure Cosmos DB hesabını daha fazla göndermeye devam edebilirsiniz.

İşlemleri

Bağlantı ilkesi: doğrudan bağlantı modunu kullan

.NET v2 SDK varsayılan bağlantı modu ağ geçididir. Parametresini kullanarak, örneği oluşturma sırasında bağlantı modunu yapılandırırsınız DocumentClient ConnectionPolicy . Doğrudan modu kullanırsanız, parametresini kullanarak da ayarlamanız gerekir Protocol ConnectionPolicy . 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
});

Kısa ömürlü bağlantı noktası tükenmesi

Örneklerinizi üzerinde yüksek bir bağlantı birimi veya yüksek bağlantı noktası kullanımı görürseniz, önce istemci örneklerinizin tekton olduğunu doğrulayın. Diğer bir deyişle, istemci örneklerinin uygulamanın ömrü için benzersiz olması gerekir.

TCP protokolünde çalışırken, istemci, uzun süreli bağlantıları kullanarak gecikme süresini en iyi duruma getirir ve bu da, 2 dakikadan sonra bağlantıları sonlandırır.

Seyrek erişiminizin olduğu senaryolarda ve ağ geçidi modu erişimiyle karşılaştırıldığında daha yüksek bir bağlantı sayısı fark ederseniz şunları yapabilirsiniz:

• connectionpolicy. portreusemode özelliğini ' e yapılandırın PrivatePortPool (framework sürümü>= 4.6.1 ve .net core sürümü >= 2,0): bu özellik SDK 'nın farklı Azure Cosmos DB hedef uç noktaları için kısa ömürlü bağlantı noktası havuzu kullanmasına izin verir.
• Connectionpolicy. ıdıdconnectiontimeout özelliği 10 dakikadan büyük veya buna eşit olmalıdır. Önerilen değerler 20 dakika ile 24 saat arasında.

İlk istekte başlangıç gecikmesini önlemek için OpenAsync çağrısı yapın

Varsayılan olarak, ilk isteğin, adres yönlendirme tablosunu getirmesi gerektiğinden gecikme süresi daha yüksektir. SDK v2'yi kullandığınızda, OpenAsync() ilk istekte bu başlangıç gecikmesini önlemek için başlatma sırasında bir kez çağrı yapın. Çağrı şöyle görünür: await client.OpenAsync();

Performans için aynı Azure bölgesindeki istemcileri birlikte bulun

mümkün olduğunda, Azure Cosmos DB veritabanıyla aynı bölgedeki Azure Cosmos DB çağıran tüm uygulamaları yerleştirin. işte yaklaşık bir karşılaştırma: aynı bölgedeki Azure Cosmos DB için yapılan çağrılar 1 ms ile 2 ms arasında tamamlanır, ancak abd 'nin batı ve doğu yakası arasındaki gecikme 50 ms 'den fazla olur. Bu gecikme, istemciden Azure veri merkezi sınırına geçerken istek tarafından alınan yola bağlı olarak istek üzerine değişiklik gösterebilir. çağıran uygulamanın, sağlanan Azure Cosmos DB uç noktası ile aynı Azure bölgesinde yer almasını sağlayarak olası en düşük gecikme süresini sağlayabilirsiniz. Kullanılabilir bölgelerin listesi için bkz. Azure bölgeleri.

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

Azure Cosmos DB çağrıları ağ üzerinden yapıldığından, istemci uygulamanın istekler arasında en az zaman harcamasını sağlamak için isteklerinizin paralellik derecesini değiştirmeniz gerekebilir. örneğin, .net görev paralel kitaplığıkullanıyorsanız, Azure Cosmos DB okuyan veya üzerine yazılan yüzlerce görev sırasını oluşturun.

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

Gecikme süresi ve CPU değişimi azaltmak için istemci sanal makinelerinde hızlandırılmış ağı etkinleştirmenizi öneririz. bkz. hızlandırılmış ağlarla Windows sanal makine oluşturma veya hızlandırılmış ağ ile Linux sanal makinesi oluşturma.

SDK kullanımı

En son SDK 'Yı yükler

Azure Cosmos DB sdk 'ları, en iyi performansı sağlamak için sürekli geliştirilmiştir. en son sdk 'yı öğrenmek ve geliş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 kullanın

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ği gerçekleştirir. Etkili bağlantı yönetimine ve daha iyi SDK istemci performansına izin vermek için, AppDomain uygulamanın kullanım ömrü boyunca tek bir örnek kullanmanızı öneririz.

Çağrı engellemeyi önleyin

Cosmos DB SDK, birçok isteği aynı anda işleyecek şekilde tasarlanmalıdır. Zaman uyumsuz API 'Ler, blok çağrılarını beklemeden binlerce eşzamanlı isteği işlemek için küçük bir iş parçacığı havuzuna izin verir. Uzun süre çalışan bir zaman uyumlu görevin tamamlanmasını beklemek yerine, iş parçacığı başka bir istek üzerinde çalışabilir.

Cosmos DB SDK kullanan uygulamalarda yaygın bir performans sorunu, zaman uyumsuz olabilecek çağrıları engelliyor. Birçok zaman uyumlu engelleme çağrısı, Iş parçacığı havuzu ve azaltılmış yanıt sürelerinin oluşmasına yol açabilir.

Şunları yapın:

• Task. Wait veya Task. Resultçağırarak zaman uyumsuz yürütmeyi engelleyin.
• Zaman uyumlu bir API zaman uyumsuz yapmak için Task. Run kullanın.
• Ortak kod yollarındaki kilitleri alın. Cosmos DB .NET SDK, kodu paralel olarak çalıştırmak için tasarlanmış olduğunda en iyi performansı sağlar.
• Task. Run çağırın ve hemen bekler. ASP.NET Core, uygulama kodunu normal iş parçacığı havuzu iş parçacıklarında zaten çalıştırıyor, bu nedenle görevi çağırıyor. yalnızca ek gereksiz iş parçacığı havuzu zamanlaması ile sonuçları çalıştırın. Zamanlanan kod bir iş parçacığını engelleyebilse bile, Task. Run bunu engellemez.
• DocumentClient.CreateDocumentQuery(...)Sorguyu zaman uyumlu olarak boşaltma için engelleme çağrılarını kullanan ToList () kullanmayın. Sorguyu zaman uyumsuz olarak boşaltmak için Asdocumentquery () kullanın.

Şunları yapın:

• Cosmos DB .net apı 'lerini zaman uyumsuz olarak çağırın.
• Zaman uyumsuz/await desenlerinden faydalanmak için tüm çağrı yığını zaman uyumsuzdur.

Iş parçacığı havuzunasık sık eklenen iş parçacıklarını bulmak Için PerfViewgibi bir profil oluşturucu kullanılabilir. Microsoft-Windows-DotNETRuntime/ThreadPoolWorkerThread/StartOlay, iş parçacığı havuzuna eklenen bir iş parçacığını gösterir.

Ağ Geçidi modu kullanırken konak başına System.Net MaxConnections 'yi artırma

ağ geçidi modunu kullandığınızda Azure Cosmos DB istekleri HTTPS/REST üzerinden yapılır. Tabi, ana bilgisayar adı veya IP adresi başına varsayılan bağlantı sınırına göre yapılır. MaxConnectionsistemci kitaplığının Azure Cosmos DB için birden çok eş zamanlı bağlantı kullanabilmesi için daha yüksek bir değere (100 'e 1.000) ayarlamanız gerekebilir. .NET SDK 1.8.0 ve üzeri sürümlerde, ServicePointManager. DefaultConnectionLimit için varsayılan değer 50 ' dir. Değeri değiştirmek için belgeler. Client. ConnectionPolicy. MaxConnectionLimit değerini daha yüksek bir değere ayarlayabilirsiniz.

Bölümlenmiş koleksiyonlar için Paralel sorguları ayarlama

SQL .net SDK 1.9.0 ve üzeri, bölümlenmiş bir koleksiyonu paralel olarak sorgulamanızı sağlayan paralel sorguları destekler. Daha fazla bilgi için bkz. SDK 'lar ile çalışma ile ilgili kod örnekleri . Paralel sorgular, seri karşılığından daha iyi sorgu gecikmesi ve verimlilik sağlamak üzere tasarlanmıştır. Paralel sorgular, gereksinimlerinize uyacak şekilde ayarlayabilmeniz için iki parametre sağlar:

• MaxDegreeOfParallelism paralel olarak sorgulanabilecek en fazla bölüm sayısını denetler.
• MaxBufferedItemCount önceden getirilen sonuçların sayısını denetler.

Paralellik derecesi ayarlama

Paralel sorgu birden çok bölümü paralel olarak sorgulayarak işe yarar. Ancak tek bir bölümden alınan veriler sorguya göre işlem içine alınır. MaxDegreeOfParallelism SDK v2 'nin bölüm sayısına en iyi şekilde ayarlanması, diğer tüm sistem koşullarının aynı kalması şartıyla en iyi performansı elde etmek için en iyi şansınız vardır. Bölüm sayısını bilmiyorsanız paralellik derecesini yüksek bir sayı olarak ayarlayabilirsiniz. Sistem paralellik derecesi olarak en az (bölüm sayısını, Kullanıcı tarafından girilen girişi) seçer.

Paralel sorgular, verilerin sorguya göre tüm bölümler arasında eşit bir şekilde dağıtılması halinde en avantaja sahip olur. Bölümlenmiş koleksiyon, bir sorgu tarafından döndürülen verilerin tümünün veya çoğu birkaç bölümde yoğunlaşarak (bir bölüm en kötü durumdur), bu bölümlerin sorgunun performansını performans sorunlarına neden olur.

MaxBufferedItemCount ayarlama

Paralel sorgu, geçerli sonuç toplu işi istemci tarafından işlendiği sırada sonuçları önceden getirmek üzere tasarlanmıştır. Bu önceden getirme, bir sorgunun genel gecikmesinin artırılmasına yardımcı olur. MaxBufferedItemCountParametresi, önceden getirilen sonuçların sayısını sınırlar. MaxBufferedItemCountSorgunun ön getirmeyi en fazla avantaj almasına izin vermek için beklenen sonuç sayısı (veya daha yüksek bir sayı) olarak ayarlayın.

Önceden getirme, paralellik derecesi ne olursa olsun aynı şekilde çalışacaktır ve tüm bölümlerdeki veriler için tek bir arabellek vardır.

RetryAfter aralıklarında geri alma Uygula

Performans testi sırasında, küçük bir istek hızı kısıtlanana kadar yükü artırmanız gerekir. İstekler kısıtlanmamışsa, sunucu tarafından belirtilen yeniden deneme aralığı için istemci uygulamanın azaltılmasından sonra kapatılması gerekir. Geri alma işleminin tamamlanması, yeniden denemeler arasında bekleyen en az miktarda süre harcamanızı sağlar.

Yeniden deneme ilkesi desteği Bu SDK 'lara dahildir:

• SQL için .net sdk 'nın sürüm 1.8.0 ve üzeri sürümleri ve Java SDK 'sı SQL
• SQL ve SQL için Python sdk 'sı içinNode.js SDK 'sının sürüm 1.9.0 ve üzeri
• .NET Core SDK 'larının tüm desteklenen sürümleri

Daha fazla bilgi için bkz. RetryAfter.

.NET SDK 'nın 1,19 ve sonraki sürümlerinde, aşağıdaki örnekte gösterildiği gibi ek tanılama bilgileri ve sorun giderme gecikme sorunlarını günlüğe kaydetme mekanizması vardır. Daha yüksek okuma gecikmesi olan istekler için tanılama dizesini günlüğe kaydedebilirsiniz. Yakalanan tanılama dizesi, belirli bir istek için kaç kez 429 hatası 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 önbellek belgesi URI 'Leri

En iyi okuma performansı için mümkün olduğunda önbellek belgesi URI 'Leri. Kaynak oluşturduğunuzda kaynak KIMLIĞINI önbelleğe almak için mantığı tanımlamanız gerekir. Kaynak kimliklerini temel alan aramalar, ad tabanlı aramalardan daha hızlıdır, bu nedenle bu değerlerin önbelleğe alınması performansı geliştirir.

Daha iyi performans için, sorguların/okunan akışların sayfa boyutunu ayarlayın

belgeleri okuma akışı işlevini (örneğin,) kullanarak toplu okuma işlemi yaptığınızda ReadDocumentFeedAsync veya SQL bir sorgu verdiğinizde sonuçlar, sonuç kümesi çok büyükse bölümlenmiş bir biçimde döndürülür. Varsayılan olarak, sonuçlar 100 öğe veya 1 MB Öbekle döndürülür, bu sınır ilk önce dönüştürülür.

Tüm geçerli sonuçları almak için gereken ağ gidiş dönüşlerin sayısını azaltmak için, en fazla 1.000 üst bilgi istemek üzere x-MS-Max-item-Count kullanarak sayfa boyutunu artırabilirsiniz. Örneğin, Kullanıcı arabirimi veya uygulama API 'niz aynı anda yalnızca 10 sonuç döndürürse, okuma ve sorgular için tüketilen aktarım hızını azaltmak için sayfa boyutunu 10 ' a da azaltabilirsiniz.

ayrıca, kullanılabilir Azure Cosmos DB sdk 'larını kullanarak sayfa boyutunu ayarlayabilirsiniz. İçindeki Maxıtemcount özelliği, FeedOptions sabit listesi işleminde döndürülecek en fazla öğe sayısını ayarlamanıza olanak sağlar. maxItemCount-1 olarak ayarlandığında, SDK, belge boyutuna bağlı olarak en uygun değeri otomatik olarak bulur. Örnek:

IQueryable<dynamic> authorResults = client.CreateDocumentQuery(documentCollection.SelfLink, "SELECT p.Author FROM Pages p WHERE p.Title = 'About Seattle'", new FeedOptions { MaxItemCount = 1000 });

Bir sorgu yürütüldüğünde, sonuçta elde edilen veriler bir TCP paketi içinde gönderilir. İçin çok düşük bir değer belirtirseniz maxItemCount , VERILERI TCP paketi içinde göndermek için gereken gidiş sayısı yüksek olur ve bu da performansı etkiler. Bu nedenle, özelliği için hangi değeri maxItemCount ayarlayabileceğinize emin değilseniz, bunu-1 olarak ayarlamak ve SDK 'nın varsayılan değeri seçmesini sağlamak en iyisidir.

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

Bkz. Bu makalenin ağ bölümünde iş parçacığı sayısı/görevler sayısını artırı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ı (ındexingpolicy. ıncludedpaths ve ındexingpolicy. excludedpaths) kullanarak hangi belge yollarının dizine dahil edileceğini veya bu dizinden dışlanacağını belirtmenize de olanak tanır. Dizin oluşturma yolları yazma performansını iyileştirebilir ve sorgu desenlerinin önceden bildiği senaryolar için Dizin depolamayı azaltabilir. Bunun nedeni, dizin oluşturma maliyetlerinin doğrudan dizin oluşturulan benzersiz yolların sayısıyla ilişkilendirilmesi. Örneğin, bu kod, "*" joker karakterini kullanarak, belgelerin tamamını (bir alt ağacı) dizin oluşturma işleminden nasıl dışarıda bırakakullanacağınızı 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.

Trafiği

Düşük Istek birimleri/ikinci kullanım için ölçme ve ayarlama

Azure Cosmos DB zengin bir veritabanı işlemleri kümesi sunar. Bu işlemler, bir veritabanı koleksiyonu içindeki belgeler üzerinde çalışan UDF 'ler, saklı yordamlar ve tetikleyicilerle ilişkisel ve hiyerarşik sorgular içerir. Bu işlemlerden her biriyle ilişkilendirilmiş maliyet, işlemi gerçekleştirmek için gereken CPU, GÇ ve belleğe göre değişir. Donanım kaynaklarını düşünmek ve yönetmek yerine, çeşitli veritabanı işlemlerini gerçekleştirmek ve bir uygulama isteğine hizmet vermek için gereken kaynaklar için bir Istek birimi (RU) tek bir ölçü olarak düşünebilirsiniz.

Aktarım hızı, her bir kapsayıcı için ayarlanan Istek birimi sayısına göre sağlanır. İstek birimi tüketimi, saniye başına bir hız olarak değerlendirilir. Kapsayıcı için sağlanan Istek birimi oranını aşan uygulamalar, oran için sağlanan düzeyin altına düşene kadar sınırlandırılır. Uygulamanız daha yüksek bir işleme düzeyi gerektiriyorsa, ek Istek birimleri sağlayarak aktarım hızını 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 doğası, 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, RequestCharge ResourceResponse\<T> FeedResponse\<T> işlemler tarafından tüketilen istek birimlerinin sayısını ölçmek üzere x-MS-Request-ücret üst bilgisini (veya .NET SDK içindeki veya içinde eşdeğer özelliği) inceleyin:

// 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ı (yani, 2.000 ru/saniye) bir kesri. Örneğin, yukarıdaki sorgu 1.000 1 KB 'lik belgeler döndürürse, işlemin maliyeti 1.000 ' dir. Bu nedenle, bir saniye içinde sunucu, sonraki istekleri sınırlamadan önce yalnızca iki istek olduğunu kabul eder. Daha fazla bilgi için bkz. Istek birimleri ve istek birimi Hesaplayıcısı.

Tanıtıcı hız sınırlandırma/istek hızı çok büyük

Bir istemci, bir hesap için ayrılan aktarım hızını aşmaya çalıştığında, sunucuda bir performans düşüşü olmaz ve ayrılan düzeyin ötesinde üretilen iş kapasitesi kullanılamaz. Sunucu isteği RequestRateTooLarge ile sona erdirmek için preemptively (HTTP durum kodu 429). Kullanıcının isteği yeniden denemeden önce beklemesi gereken süre miktarını 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, sunucu tarafından belirtilen yeniden deneme üst bilgisine göre bu yanıtı dolaylı olarak yakalar ve isteği yeniden dener. Hesabınız birden çok istemci tarafından aynı anda erişilmediği takdirde, sonraki yeniden deneme başarılı olur.

İstek hızının sürekli olarak birden fazla istemciniz varsa, bu, şu anda istemci tarafından dahili olarak 9 olarak ayarlanmış olan varsayılan yeniden deneme sayısı çalışmayabilir. Bu durumda, istemci uygulamaya 429 durum kodu ile bir DocumentClientException oluşturur.

Örneği üzerinde ayarını yaparak varsayılan yeniden deneme sayısını değiştirebilirsiniz RetryOptions ConnectionPolicy . Varsayılan olarak, durum kodu 429 olan DocumentClientException, istek istek hızının üzerinde çalışmaya devam ederse, 30 saniyelik birikimli bir bekleme süresi dolduktan sonra döndürülür. Bu hata, geçerli yeniden deneme sayısı en fazla yeniden deneme sayısından daha az olduğunda, geçerli değerin varsayılan olarak 9 veya Kullanıcı tanımlı bir değer olup olmadığı halde döndürür.

Otomatik yeniden deneme davranışı çoğu uygulama için dayanıklılığı ve kullanılabilirliği artırmaya yardımcı olur. Ancak, özellikle gecikmeyi ölçmeniz durumunda performans kıyaslamaları yaparken en iyi davranış olmayabilir. Deneme sunucu tarafından azaldıysanız, istemci SDK 'sının sessizce yeniden denenmesine neden olursa istemci gözlenen gecikme süresi izlenir. Performans denemeleri sırasında gecikme sürelerini önlemek için, her bir işlem tarafından döndürülen ücreti ölçün ve isteklerin ayrılan istek oranının altında çalıştığından emin olun. Daha fazla bilgi için bkz. Istek birimleri.

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

Belirli bir işlemin istek ücreti (diğer bir deyişle, istek işleme maliyeti) doğrudan belgenin boyutuyla ilişkili olur. Büyük belgelerle ilgili işlemler küçük belgelerde işlemlerden daha fazla maliyetlidir.

Sonraki adımlar

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

uygulamanızı ölçek ve yüksek performans için tasarlama hakkında daha fazla bilgi için, bkz. Azure Cosmos DB bölümleme ve ölçeklendirme.