Советы по повышению производительности для Azure Cosmos DB и .NET

ОБЛАСТЬ ПРИМЕНЕНИЯ: NoSQL

Azure Cosmos DB — быстрая и гибкая распределенная база данных, которая легко масштабируется с гарантированными уровнями задержки и пропускной способности. Для масштабирования базы данных с помощью Azure Cosmos DB не нужно вносить в архитектуру существенные изменения или писать сложный код. Для увеличения или уменьшения масштаба достаточно выполнить один вызов API. Дополнительные сведения см. в разделах о подготовке пропускной способности контейнера и о подготовке пропускной способности базы данных.

Так как для доступа к Azure Cosmos DB выполняются сетевые вызовы, вы можете выполнить оптимизации на стороне клиента, чтобы повысить производительность при работе с пакетом SDK .NET для SQL.

Если вы хотите повысить производительность базы данных, рассмотрите варианты, описанные в следующих разделах.

Рекомендации по размещению

Включение сборки мусора на стороне сервера

В некоторых случаях для оптимизации можно уменьшить частоту сборки мусора. В .NET установите для параметра gcServer значение true.

Масштабирование клиентской рабочей нагрузки

При тестировании на высоких уровнях пропускной способности или скорости, превышающей 50 000 единиц запроса в секунду, клиентское приложение может стать узким местом рабочей нагрузки. Это связано с тем, что компьютер может превысить допустимую нагрузку при использовании ЦП или сети. Если вы достигли этой точки, то можете повысить производительность Azure Cosmos DB, развернув клиентские приложения на нескольких серверах.

Операции с метаданными

Не проверяйте существование базы данных и (или) контейнера с помощью вызова Create...IfNotExistsAsync и (или) Read...Async в критическом пути и (или) перед выполнением операции с элементом. Такая проверка должна выполняться только при запуске приложения, когда она необходима, то есть если вы ожидаете удаления объектов (в противном случае она не требуется). Эти операции с метаданными создают дополнительные задержки, не поддерживают Соглашения об уровне обслуживания и имеют собственные ограничения, которые плохо масштабируются, в отличие от операций с данными.

Логирование и трассировка

В некоторых средах включено средство .NET DefaultTraceListener. DefaultTraceListener создает проблемы с производительностью в рабочих средах, что приводит к возникновению узких мест из-за высокой загрузки ЦП и большого числа операций ввода-вывода. Убедитесь, что средство DefaultTraceListener отключено для вашего приложения, удалив его из TraceListeners в продуктивных средах.

Последние версии пакета SDK (после 3.23.0) автоматически удаляют его при обнаружении в более старых версиях. Вы можете удалить его сами, как указано ниже.

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
}

<configuration>
  <system.diagnostics>
    <sources>
      <source name="DocDBTrace" switchName="SourceSwitch" switchType="System.Diagnostics.SourceSwitch" >
        <listeners>
          <remove name="Default" />
          <!--Add your own trace listeners-->
          <add name="myListener" ... />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>
<configuration>

Высокая доступность

Общие рекомендации по настройке высокой доступности в Azure Cosmos DB см. в статье "Высокий уровень доступности" в Azure Cosmos DB.

Помимо хорошей базовой настройки на платформе базы данных, существуют определенные методы, которые можно реализовать в самом пакете SDK для .NET, что может помочь в сценариях сбоя. Две важные стратегии — это стратегия доступности на основе порогового значения и разбиение цепи на уровне секции.

Стратегия доступности на основе порогового значения

Стратегия доступности на основе порогового значения может улучшить задержку на хвосте и общую доступность, отправляя параллельные запросы на чтение в вторичные регионы (как указано в ApplicationPreferredRegions) и принимая самый быстрый ответ. Такой подход может значительно снизить влияние региональных сбоев или условий высокой задержки на производительность приложения.

Пример конфигурации :

Это можно сделать с помощью CosmosClientBuilder:

CosmosClient client = new CosmosClientBuilder("connection string")
    .WithApplicationPreferredRegions(
        new List<string> { "East US", "East US 2", "West US" } )
    .WithAvailabilityStrategy(
        AvailabilityStrategy.CrossRegionHedgingStrategy(
        threshold: TimeSpan.FromMilliseconds(500),
        thresholdStep: TimeSpan.FromMilliseconds(100)
     ))
    .Build();

Или путем настройки параметров и их добавления в CosmosClient:

CosmosClientOptions options = new CosmosClientOptions()
{
    AvailabilityStrategy
     = AvailabilityStrategy.CrossRegionHedgingStrategy(
        threshold: TimeSpan.FromMilliseconds(500),
        thresholdStep: TimeSpan.FromMilliseconds(100)
     )
      ApplicationPreferredRegions = new List<string>() { "East US", "East US 2", "West US"},
};

CosmosClient client = new CosmosClient(
    accountEndpoint: "account endpoint",
    authKeyOrResourceToken: "auth key or resource token",
    clientOptions: options);

Принцип работы.

1. Первоначальный запрос: в момент времени T1 выполняется запрос на чтение в основной регион (например, Восточный регион США). Пакет SDK ожидает ответа до 500 миллисекунд (значение threshold).

2. Второй запрос: если ответа от основного региона в течение 500 миллисекунд нет, параллельный запрос отправляется в следующий предпочтительный регион (например, восточная часть США 2).

3. Третий запрос: если ни основной, ни дополнительный регион не отвечает в течение 600 миллисекунда (500 мс + 100 мс, thresholdStep значение), пакет SDK отправляет другой параллельный запрос в третий предпочтительный регион (например, западная часть США).

4. Самый быстрый ответ выигрывает: любой регион отвечает первым, этот ответ принимается, а другие параллельные запросы игнорируются.

Автоматический выключатель на уровне раздела

Средство разбиения на уровне секций (PPCB) — это функция пакета SDK для .NET, которая повышает доступность и задержку путем отслеживания неработоспособных физических секций. Если этот параметр включен, он помогает направлять запросы в более устойчивые регионы, предотвращая каскадные сбои из-за региональных или специфических для секций проблем. Эта функция независима от функций автоматического переключения, запускаемых серверной частью, и контролируется через переменные среды.

Эта функция по умолчанию отключена, но включается автоматически, когда включена отказоустойчивость на уровне раздела.

Принцип работы

1. Обнаружение сбоев: При обнаружении определенных ошибок, таких как 503 Service Unavailable, 408 Request Timeoutили маркеров отмены, пакет SDK подсчитывает последовательные сбои для секции.
2. Переключение на резервный канал: После достижения заданного порога последовательных сбоев SDK перенаправляет запросы для этого диапазона ключей раздела в следующий предпочтительный регион.GlobalPartitionEndpointManagerCore.TryMarkEndpointUnavailableForPartitionKeyRange
3. Фоновое восстановление: Фоновая задача инициируется во время переключения на резервный узел для периодической повторной оценки состояния отказавшего раздела с целью подключения ко всем четырем репликам. Когда система стабилизируется, SDK удаляет переопределение и возвращается в основную область.

Поведение по типу учетной записи

• Запись в один регион (один главный): Только запросы на чтение участвуют в логике отработки отказа PPCB.
• Запись в нескольких регионах (многоуровневая): Оба запроса на чтение и запись используют логику отработки отказа PPCB.

Параметры конфигурации

Используйте следующие переменные среды для настройки PPCB:

Сравнение оптимизаций доступности

• Стратегия доступности на основе порогов:

  • Преимущество. Сокращение задержки хвоста путем отправки параллельных запросов на чтение в вторичные регионы и повышения доступности путем предварительного ввода запросов, которые приводят к истечению времени ожидания сети.
  • Компромисс. В связи с дополнительными запросами между регионами (хотя и в периоды, когда пороговые значения нарушаются) взимается дополнительная плата за единицу запросов в секунду.
  • Вариант использования. Оптимальный вариант для рабочих нагрузок с высокой нагрузкой на чтение, где снижается задержка, а также некоторые дополнительные затраты (как с точки зрения платы за единицу ЕЗ, так и нагрузку на ЦП клиента) приемлемы. Операции записи также могут воспользоваться преимуществами, если вы решили использовать политику повторных попыток без idempotent и учетную запись с несколькими регионами.

• Разбиение цепи на уровне секции:

  • Преимущество: Повышает доступность и снижает задержки за счет предотвращения неработоспособных разделов, что обеспечивает маршрутизацию запросов в более стабильные регионы.
  • Компромисс: Не несет дополнительных затрат на RU, но может по-прежнему допускать некоторую начальную потерю доступности для запросов, которые приведут к сетевым тайм-аутам.
  • Сценарий использования: Идеально подходит для рабочих процессов с большой нагрузкой на запись или смешанных процессов, где устойчивая производительность важна, особенно при работе с разделами, которые могут периодически стать неработоспособными.

Обе стратегии можно использовать вместе для повышения доступности чтения и записи и уменьшения пиковой задержки. Прерыватель цепи на уровне разделов может обрабатывать различные сценарии преходящих сбоев, включая те, которые могут привести к медленной работе реплик, без необходимости выполнять параллельные запросы. Кроме того, добавление стратегии доступности, основанной на пороговых значениях, приведет к снижению латентности в хвосте распределения и устранению потери доступности, если дополнительная стоимость RU допустима.

Реализуя эти стратегии, разработчики могут обеспечить устойчивость приложений, обеспечить высокую производительность и повысить производительность даже во время региональных сбоев или условий высокой задержки.

Сеть

Политика подключения: использование режима прямого подключения

Для пакета SDK для .NET v3 по умолчанию используется прямое подключение по протоколу TCP. Режим подключения настраивается при создании экземпляра CosmosClient в CosmosClientOptions. Дополнительные сведения о различных вариантах подключения см. в статье Режимы подключения.

CosmosClient client = new CosmosClient(
  "<nosql-account-endpoint>",
  tokenCredential
  new CosmosClientOptions
  {
      ConnectionMode = ConnectionMode.Gateway // ConnectionMode.Direct is the default
  }
);

Временная нехватка портов

При большом числе подключений или высокой интенсивности использования портов на ваших экземплярах необходимо сначала убедиться, что клиентские экземпляры являются одиночными. Иными словами, экземпляры клиента должны быть уникальными в течение всего времени существования приложения.

Когда клиент работает по протоколу TCP, он оптимизирует задержку, используя длительные соединения. Это отличается от протокола HTTPS, который прерывает подключения после двух минут бездействия.

В сценариях с разреженным доступом, если вы видите более высокое число подключений по сравнению с режимом шлюза, вы можете:

• Задать для свойства CosmosClientOptions.PortReuseMode значение PrivatePortPool (действует с версиями платформы 4.6.1 и более поздними и версиями .NET Core 2.0 и более поздними). Это свойство позволяет пакету SDK использовать небольшой пул временных портов для разных конечных точек назначения Azure Cosmos DB.
• Настройте свойство CosmosClientOptions.IdleTcpConnectionTimeout как больше или равно 10 минут. Рекомендуется использовать значения от 20 минут до 24 часов.

Повышение производительности за счет размещения клиентов в одном регионе Azure

Если это возможно, размещайте приложения, выполняющие вызовы к Azure Cosmos DB, в том же регионе, в котором находится база данных Azure Cosmos DB. Для приблизительного сравнения: вызовы к Azure Cosmos DB в пределах региона выполняются в течение 1–2 мс, но задержка между восточным и западным побережьем США превышает 50 мс. Значение задержки может отличаться в зависимости от выбранного маршрута при передаче запроса от клиента к границе центра обработки данных Azure.

Можно достичь минимальной задержки при размещении клиентского приложения в том же регионе Azure, в котором предоставляется конечная точка Azure Cosmos DB. Список доступных регионов см. на странице с регионами Azure.

Увеличение количества потоков или задач

Так как вызовы Cosmos DB выполняются по сети, может потребоваться изменить степень параллелизма запросов, чтобы клиентское приложение тратило минимальное количество времени на ожидание между запросами. Например, если вы используете библиотеку параллельных задач .NET, создайте около нескольких сотен задач считывания или записи в Azure Cosmos DB.

Включите ускоренное сетевое соединение для уменьшения задержки и колебаний производительности ЦП

Рекомендуется следовать инструкциям, чтобы включить ускоренную сеть в Windows (щелкните инструкции) или Linux (щелкните инструкции) виртуальной машины Azure, чтобы повысить производительность.

Без ускоренной сети операции ввода-вывода, выполняемые между виртуальной машиной Azure и другими ресурсами Azure, могут без необходимости маршрутизироваться через узел и виртуальный коммутатор, расположенный между виртуальной машиной и ее сетевой картой. Наличие узла и виртуального коммутатора внутри пути данных не только увеличивает задержку и дрожание в коммуникационном канале, но также приводит к краже циклов ЦП у виртуальной машины. Благодаря ускоренной сети виртуальная машина взаимодействует напрямую с сетевой картой, без посредников; все сведения о политике сети, которые ранее обрабатывались узлом и виртуальным коммутатором, теперь обрабатываются оборудованием на сетевой карте, а узел и виртуальный коммутатор обходятся. При включении ускоренной сети, как правило, можно ожидать снижение задержки и увеличение пропускной способности, а также улучшение согласованности задержки и снижение загрузки ЦП.

Ограничения: ускоренная сеть должна поддерживаться в ОС виртуальной машины и может быть включена только при остановке и освобождении виртуальной машины. Виртуальную машину невозможно развернуть с помощью Azure Resource Manager. Служба приложений не включает ускоренную сеть.

Дополнительные сведения см. в инструкциях для Windows и Linux.

Использование пакета SDK

Установка последней версии пакета SDK

Пакеты SDK для Azure Cosmos DB постоянно улучшаются, чтобы обеспечивать самую высокую производительность. Сведения о последней версии пакета SDK и об улучшениях см. в статье о пакете SDK для Azure Cosmos DB.

Использование API-интерфейсов потока

Пакет SDK для .NET v3 содержит API-интерфейсы потока, которые могут получать и возвращать данные без сериализации.

Приложения среднего уровня, которые не используют ответы непосредственно из пакета SDK, но ретранслируют их на другие уровни приложений, могут получить преимущества от API-интерфейсов потока. Примеры обработки потоков см. в разделе с примерами управления элементами.

Использование одного и того же клиента Azure Cosmos DB в течение всего жизненного цикла приложения

Каждый экземпляр CosmosClient в режиме работы «Прямое подключение» обеспечивает безопасность потоков, эффективно управляет подключениями и кэширует адреса. Чтобы обеспечить эффективное управление подключениями и более высокую производительность клиента пакета SDK, рекомендуется использовать один экземпляр за AppDomain время существования приложения для каждой учетной записи, с которыми взаимодействует ваше приложение.

Для мультитенантных приложений, обрабатывающих несколько учетных записей, см. связанные рекомендации.

При работе с Azure Functions также следует следовать существующим рекомендациям и поддерживать одну инстанцию.

Избегайте блокирующих вызовов

Пакет SDK Для Azure Cosmos DB должен быть разработан для одновременной обработки множества запросов. Асинхронные API позволяют небольшому пулу потоков работать с тысячами одновременных запросов, не дожидаясь блокировки вызовов. Вместо ожидания завершения длительной синхронной задачи поток может работать с другим запросом.

Распространенная проблема с производительностью в приложениях с помощью пакета SDK Azure Cosmos DB блокирует вызовы, которые могут быть асинхронными. Множество синхронных блокирующих вызовов может привести к истощению пула потоков и ухудшению времени отклика.

Не рекомендуется:

• Блокировать асинхронное выполнение путем вызова Task.Wait или Task.Result.
• Использовать метод Task.Run, чтобы сделать синхронный API асинхронным.
• Получать блокировки в общих участках кода. .NET SDK для Azure Cosmos DB обеспечивает наивысшую производительность при выполнении кода параллельно.
• Вызовите Task.Run и сразу ожидайте его. ASP.NET Core уже выполняет программный код в стандартных потоках пула потоков, поэтому вызов Task.Run приведет лишь к ненужному планированию задач в пуле потоков. Даже если запланированный код блокирует поток, Task.Run не препятствует этому.
• Не используйте ToList() на Container.GetItemLinqQueryable<T>(), который использует блокирующие вызовы для синхронного выполнения запроса. Используйте ToFeedIterator() для асинхронной очистки запросов.

Сделайте следующее:

• Асинхронно вызовите API .NET для Azure Cosmos DB.
• Весь стек вызовов является асинхронным, чтобы использовать преимущества шаблонов async/await.

Можно использовать профилировщик, например PerfView, чтобы находить потоки, часто добавляемые в пул потоков. Событие Microsoft-Windows-DotNETRuntime/ThreadPoolWorkerThread/Start указывает поток, добавленный в пул потоков.

Отключение ответа содержимого при операциях записи

Для рабочих нагрузок, создающих большие объемы данных, установите для параметра запроса EnableContentResponseOnWrite значение false. Служба больше не будет возвращать созданный или обновленный ресурс пакету SDK. Как правило, поскольку приложение имеет создаваемый объект, служба не должна его возвращать. Значения заголовков по-прежнему доступны, как, например, плата за запрос. Отключение реагирования на содержимое может помочь повысить производительность, поскольку пакету SDK больше не требуется выделять память или сериализовать текст ответа. Это также сокращает использование пропускной способности сети для еще большего повышения производительности.

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

Активируйте режим Bulk для оптимизации пропускной способности вместо минимизации задержки

Включите массовые операции для сценариев, в которых рабочей нагрузке требуется большой объем пропускной способности, а задержка не так важна. Дополнительные сведения о включении функции массовых операций и о том, для каких сценариев ее следует использовать, см. в разделе Поддержка массовых операций.

Увеличение максимального количества подключений System.Net для каждого узла при использовании режима шлюза

При использовании режима шлюза запросы Azure Cosmos DB выполняются через HTTPS/REST. К ним применяются ограничения на количество подключений по умолчанию для каждого имени узла или IP-адреса. Может потребоваться задать для параметра MaxConnections более высокое значение (от 100 до 1000), чтобы клиентская библиотека могла использовать несколько одновременных подключений к Azure Cosmos DB. В пакете SDK для .NET 1.8.0 и более поздних версиях значение по умолчанию для ServicePointManager.DefaultConnectionLimit равно 50. Чтобы изменить значение, можно задать для Documents.Client.ConnectionPolicy.MaxConnectionLimit более высокое значение.

Увеличение количества потоков или задач

См. подраздел Увеличение количества потоков или задач раздела "Сеть" этой статьи.

Операции запросов

Операции с запросами см. в разделе Рекомендации по повышению производительности запросов.

Политика индексирования

Исключите неиспользуемые пути из индексирования, чтобы ускорить выполнение операций записи

Политика индексирования Azure Cosmos DB также позволяет добавлять пути к документам или исключать их из индексирования. Для этого используется параметр Indexing Paths (IndexingPolicy.IncludedPaths и IndexingPolicy.ExcludedPaths).

Индексирование только нужных путей может повысить производительность операций записи, сократить расходы на RU при операциях записи и уменьшить объем хранилища индексов для сценариев, в которых эти запросы известны заранее. Это обусловлено тем, что стоимость индексирования напрямую соотносится с количеством уникальных путей. Например, следующий код показывает, как с помощью символа подстановки "*" исключить из индексации целый раздел документов (поддерево).

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);

Дополнительные сведения см. в статье Политики индексации Azure Cosmos DB.

Пропускная способность

Измерение и настройка для уменьшения использования RU/s

В Azure Cosmos DB предлагается обширный набор операций базы данных. К этим операциям относятся реляционные и иерархические запросы с определяемыми пользователем функциями (UDFS), хранимыми процедурами и триггерами, всеми работающими на документах в коллекции баз данных.

Затраты, связанные с каждой из этих операций, зависят от типа процессора, операций ввода-вывода и памяти, необходимой для выполнения операции. Вы можете забыть о необходимости управления аппаратными ресурсами, вместо этого рассматривая единицу запроса как универсальную меру оценки ресурсов, требуемых для выполнения различных операций с базами данных и обслуживания запросов приложения.

Пропускная способность выделяется на основе количества единиц запроса, заданного для каждого контейнера. Расход единиц запроса оценивается как количество единиц в секунду. Приложения, у которых частота использования единиц запроса превышает уровень, назначенный для их контейнера, ограничиваются до тех пор, пока частота не упадет ниже этого уровня. Если приложению требуется более высокий уровень пропускной способности, можно увеличить ее путем выделения дополнительных единиц запроса.

Сложность запроса влияет на количество единиц запроса, потребляемых операцией. Количество предикатов и их характер, количество файлов UDF и размер набора исходных данных — все это влияет на плату за операции запроса.

Для оценки расходов на каждую операцию (создание, обновление или удаление) посмотрите на заголовок x-ms-request-charge (или эквивалентное свойство RequestCharge в ResourceResponse<T> или FeedResponse<T> в пакете SDK для .NET), чтобы измерить число единиц запроса, используемых такими операциями.

// 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);
    }

Затраты на запрос, возвращенные в этом заголовке, — это часть выделенной пропускной способности (то есть, 2000 RU/с). Например, если приведенный выше запрос вернет 1000 документов размером по 1 КБ каждый, затраты на операцию составят 1000. Таким образом, перед ограничением частоты выполнения последующих запросов сервер за одну секунду выполняет лишь два таких запроса. Чтобы узнать больше, ознакомьтесь с единицами запроса и калькулятором единиц запроса.

Обработка ограничения скорости / слишком высокая частота запросов

Если клиент пытается превысить зарезервированную пропускную способность для учетной записи, это не приводит к замедлению работы сервера и не позволяет использовать пропускную способность сверх зарезервированного уровня. Сервер заблаговременно прерывает запрос с кодом состояния RequestRateTooLarge (код статуса HTTP 429). Он возвращает заголовок x-ms-retry-after-ms, который указывает время ожидания (в миллисекундах), по истечении которого пользователь должен выполнить запрос еще раз.

    HTTP Status 429,
    Status Line: RequestRateTooLarge
    x-ms-retry-after-ms :100

Все пакеты SDK неявно перехватят этот ответ, обработают заголовок retry-after, указанный сервером, и отправят запрос повторно. Если к вашей учетной записи параллельно имеет доступ только один клиент, следующая попытка будет успешной.

Если сразу несколько клиентов регулярно выполняют запросы с частотой выше заданной, количество повторных попыток по умолчанию, которое сейчас задано клиентом как 9, может быть недостаточным. В этом случае клиент создает в приложении исключение CosmosException с кодом состояния 429.

Можно изменить число повторных попыток по умолчанию, задав RetryOptions для экземпляра CosmosClientOptions. По умолчанию исключение с кодом состояния 429 (CosmosException) возвращается после совокупного времени ожидания в 30 секунд, если запрос продолжает работать выше скорости запроса. Эта ошибка возвращается, даже если текущее число повторных попыток меньше максимального, независимо от того, является ли текущее значение значением по умолчанию 9 или значением, определенным пользователем.

Автоматическое поведение повторных попыток помогает повысить устойчивость и удобство использования для большинства приложений. Но это может не быть лучшим поведением при выполнении тестов производительности, особенно при измерении задержки. Если эксперимент ударится о серверное ограничение и приведёт к тому, что клиентская SDK начнёт незаметно повторять запросы, у клиента возникнет всплеск задержек. Чтобы избежать пиков задержек во время настройки производительности, проверьте расход ресурсов на каждую операцию и убедитесь, что значение частоты запросов не превышено.

Дополнительные сведения см. в статье Единицы запроса.

Использование документов меньшего размера для обеспечения более высокой пропускной способности

Плата за запрос (т. е. затраты на обработку запросов) указанной операции напрямую коррелирует с размером документа. За операции с большими документами взимается больше единиц запроса, чем за операции с мелкими документами.

Следующие шаги

Пример приложения, используемого в сценариях оценки производительности Azure Cosmos DB на нескольких клиентских компьютерах, см. в статье Проверка производительности и масштабирования с помощью Azure Cosmos DB.

Дополнительные сведения о создании приложения с высокой масштабируемостью и производительностью см. в статье Partitioning and scaling in Azure Cosmos DB (Секционирование и масштабирование в Azure Cosmos DB).