Измерение производительности запросов Cosmos DB

Я новичок в Cosmos DB, и я пытаюсь выполнить некоторые измерения производительности для запросов к коллекции Cosmos db (documentdb api) duo c#-sdk. Я пытаюсь сделать это с помощью простого секундомера. Но когда я делаю запрос со следующим фрагментом кода, я всегда получаю колеблющиеся данные измерений между 14 мс и примерно 33 мс. Он независим, если я запрашиваю запись об одном или 10000 данных, а также независим, если я запрашиваю значение ключа раздела, другое индексированное значение или неиндексированное значение с активным EnableScaninQuery. Я так понимаю, что с этим кодом что-то не так? Я ожидаю гораздо больше времени для сбора 10000 записей неиндексированных данных, чем для запроса данных одного ключа раздела. Также FeedOptions предоставляет метод PopulateQueryMetrics. Есть ли способ получить доступ к времени запроса, используя эти показатели в моем приложении С#?

FeedOptions asd = new FeedOptions
        {
            EnableCrossPartitionQuery = true,
            // EnableScanInQuery = true,
            //PopulateQueryMetrics = true,
            MaxItemCount = 500,
            MaxBufferedItemCount = 10000,
            MaxDegreeOfParallelism = -1
        }; 
watch.Start();
            try
            {
                IDocumentQuery<Item> query = client.CreateDocumentQuery<Item>(
                    UriFactory.CreateDocumentCollectionUri(Database, coll), asd)
                    .Where(m => m.userid == 999999).AsDocumentQuery<Item>();

                WriteToConsoleAndPromptToContinue("Query took {0} ms ", watch.ElapsedMilliseconds);
                watch.Stop();

person Alex    schedule 11.08.2017    source источник
comment
Каково сетевое расстояние между вашим клиентом доступа к базе данных и экземпляром CosmosDb в Azure?   -  person camelCase    schedule 15.08.2017


Ответы (1)


Попробуйте перебрать весь набор результатов, чтобы получить надежные результаты.

while (query.HasMoreResults)  
{
    var result = await query.ExecuteNextAsync<Item>();

    // Process paged results
}
person camelCase    schedule 15.08.2017
comment
спасибо за ответ, я сделаю это уже, чтобы напечатать мне некоторую информацию о каждом запрошенном элементе. Но как я могу измерить время с этой обработкой? - person Alex; 16.08.2017
comment
Код, показанный в вашем вопросе, измеряет время, прошедшее до того, как все результаты запросов к базе данных будут реализованы в вашем коде на стороне клиента. Если вы вставите предложенный мной блок кода непосредственно перед оператором измерения WriteToConsoleAndPromptToContinue(), я думаю, вы получите реалистичные тайминги. Вы также должны подсчитать документы, возвращенные только для проверки вашего запроса. - person camelCase; 16.08.2017
comment
благодарю вас. Но я не хочу обрабатывать результат, я хочу только запросить некоторые документы и измерить время для этого. Выполнение этого с вашим примером приводит к запросам на основе ключа раздела для одного элемента за время, например, 5000 мс. SLA разрешают запросы менее чем за 10 мс без их обработки. Итак, я предполагаю, что мои предыдущие результаты с измерениями около 14-33 мс могут быть реалистичными значениями (на основе задержки на стороне клиента) только для запроса значений и даже без их обработки? - person Alex; 17.08.2017
comment
Если вы видите время запроса 5000 мс для запроса и материализации одного объекта среднего размера (1 КБ), значит, что-то не так с вашей тестовой настройкой. Усилия ЦП по созданию экземпляра результата запроса DocumentDb json на стороне клиента ничтожны по сравнению с остальной механикой запроса. Устранили ли вы затраты на API и прогрев соединения, измеряя второй, а не первый тестовый запрос? - person camelCase; 17.08.2017
comment
Извините, я не могу следить за вами. Что вы имеете в виду под отказом от API и стоимости прогрева соединения? Единственное измерение времени, которое я использовал, это то, которое вы можете увидеть в исходном посте. - person Alex; 17.08.2017