當「基準」documentdb

我可能（可能）做這一切都是錯誤的，結果大不相同。但是我在使用DocumentDb的Web應用程序中產生了一些奇怪的結果之後，我做了一個簡單的基準測試。當「基準」documentdb

 var id = "62734c17-e939-43bd-8719-08e4c7b51f75"; 
     var client = new DocumentClient(new Uri(LocalDbConfig.Endpoint),LocalDbConfig.Key); 
     var sw = new Stopwatch(); 
     var collectionLink = UriFactory.CreateDocumentCollectionUri(LocalDbConfig.DatabaseId, 
      LocalDbConfig.CollectionId); 

     var tsResults = new List<long>(); 
     var docResults = new List<long>(); 

     for (int i = 0; i < 10; i++) 
     { 
      sw.Restart(); 
      var result = client.CreateDocumentQuery(collectionLink, $"select c._ts from c where c.id = \"{id}\"").AsEnumerable().FirstOrDefault()._ts; 
      sw.Stop(); 
      tsResults.Add(sw.ElapsedMilliseconds); 
      Console.WriteLine($"TS: {sw.ElapsedMilliseconds}"); 
     } 

     for (int i = 0; i < 10; i++) 
     { 
      sw.Restart(); 
      var doc = client.CreateDocumentQuery(collectionLink).Where(q => q.Id == id).AsEnumerable().FirstOrDefault(); 
      sw.Stop(); 
      docResults.Add(sw.ElapsedMilliseconds); 
      Console.WriteLine($"DOC: {sw.ElapsedMilliseconds}"); 
     } 

     Console.WriteLine($"TS: Average: {tsResults.Average()} - Longest: {tsResults.Max()} - Shortest: {tsResults.Min()}"); 
     Console.WriteLine($"DOC: Average: {docResults.Average()} - Longest: {docResults.Max()} - Shortest: {docResults.Min()}"); 


     Console.ReadLine();

這是一個C＃控制檯應用程序的Main()功能。我要求的文檔大約是5MB的JSON。

在第一個循環中，我只是請求文檔的單個屬性，它是時間戳。（我開始嘗試實現一個非常天真的緩存startegy）而另一個循環返回完整的文檔。

這是輸出：

TS: 1450 
TS: 17 
TS: 18 
TS: 22 
TS: 548 
TS: 156 
TS: 532 
TS: 174 
TS: 519 
TS: 182 
DOC: 557 
DOC: 1725 
DOC: 1916 
DOC: 1868 
DOC: 1876 
DOC: 1832 
DOC: 1861 
DOC: 1851 
DOC: 1881 
DOC: 1870 
TS: Average: 361,8 - Longest: 1450 - Shortest: 17 
DOC: Average: 1723,7 - Longest: 1916 - Shortest: 557

正如你可以看到，返回的時間戳是所有的地方，但返回完整的文檔是那種穩定的第一請求後，爲什麼第一個請求400％比其他我無法弄清楚的要快。

需要注意的是該測試運行在DocumentDb模擬器上，但原始問題也出現在Azure DocumentDb服務中。

任何人都知道爲什麼讓時間戳到處都是這樣嗎？爲什麼第一次讀取的文件是500毫秒，而其餘的幾乎是2000毫秒？

來源

2017-01-20 Christian Wattengård

您可以在與您的DocumentDB相同的數據中心運行此模塊，而不是在模擬器本地運行該模塊嗎？我知道你說這個問題是存在的，但我認爲如果你的數據來自於生產環境，更多的人會對幫助感興趣。 –

我也建議關閉節流的重試。初始化DocumentClient時，將ConnectionPolicy.RetryOptions.MaxRetryAttemptsOnThrottle = 0設置爲消除任何節流變化。 –

此外，如果您可以將收集內容共享到[email protected]，我們可以調試/分析並將結果發佈回SO。 –

根據提供的信息，您可能已達到預配置的採集吞吐量並進入速率限制。當速率限制時，SDK會自動重試，因此您會將此視爲較長的延遲，特別是對於像SELECT c._ts這樣的有效載荷較小的請求。

通過增加集合的預配置吞吐量，可以獲得可預測的單位數毫秒延遲。在[email protected]上通過電子郵件發送Azure DocumentDB支持以及您的端點詳細信息也將爲您提供確鑿的答案。

來源

2017-01-21 17:16:39

當「基準」documentdb

回答

相關問題