База данных функций и документов Azure

Мне любопытно, как работает масштабирование в функциях Azure по отношению к выводу в базу данных документов.

В основном, что происходит, когда Document DB возвращает 429, потому что я превысил выделенную мне пропускную способность? Я спрашиваю, потому что, когда у меня был самый низкий уровень функций Azure в сочетании с самым низким уровнем базы данных документов и я продолжал вызывать функцию 1000 раз за 20 секунд, я видел только 700-800 фактических документов, вставленных в мою коллекцию db документов. Когда я снова масштабировал Document DB до максимума с тем же самым низким функциональным уровнем, я получил только 700-800 документов в моей коллекции doc db. Однако, когда я масштабировал функцию до максимума с документом db на максимуме, я получаю все 1000. Когда я опускаю doc db до минимума, я получил только 300ish .... хотя кажется, что я заблокировал документ db и что он все еще пытается вставить, пока не удастся.

Так что я просто смущен тем, что это масштабирование, и если бы я мог получить некоторое представление, чтобы я мог лучше настроить различные аспекты функции или приложения.


person steveko23    schedule 06.04.2016    source источник


Ответы (1)


Да, в настоящее время он повторяет попытку на 429, ожидая рекомендованное время в соответствии с ответом DocDB. В настоящее время нет абсолютного тайм-аута, поэтому попытки будут продолжаться до тех пор, пока они не закончатся (сейчас я дважды проверяю, является ли это ожидаемым поведением).

В вашем первом сценарии, если вы достаточно долго ждете, пока дроссель будет удален, все ли 1000 в конечном итоге появятся?

Я хотел бы попробовать воспроизвести это - вы вставляете 1000 элементов в очередь, прежде чем включить свою функцию? Или как-то иначе?

Если вам интересно, то здесь находится конкретный запущенный код повтора: https://github.com/Azure/azure-webjobs-sdk-extensions/blob/master/src/WebJobs.Extensions.DocumentDB/DocumentDBUtility.cs#L36

person brettsam    schedule 06.04.2016
comment
Я запускаю функцию через http, так как не верю, что триггеры служебной шины в C # в настоящее время работают (хотя это могло измениться, поскольку в настоящее время это быстро меняется). Итак, я запускаю все 1000 через http, я использую loader.io для этого, вызывая конечную точку веб-api в моем коде, которая, в свою очередь, запускает сообщение http для запуска функции. Тест loader.io настроен на выполнение 50 запросов в секунду в течение 20 секунд. - person steveko23; 07.04.2016
comment
Я не уверен на 100%, что функция в конечном итоге завершится. В моем последнем тесте записи, похоже, больше не записывались, но я все еще получал 429, когда пытался взаимодействовать с коллекцией doc db. Поэтому я удалил всю коллекцию и воссоздал ее, а затем увидел дополнительные записи, записанные в коллекцию. Так что кажется, что он все еще пытался, но также казалось, что он был в странном состоянии. - person steveko23; 07.04.2016
comment
Сейчас это обновлено в производственной среде - попробуйте еще раз. Поведение должно быть немного разумнее. Теперь повторные попытки выполняются максимум 10 раз, что означает, что вы начнете получать ошибки, когда DocDB возвращает слишком много 429, но этого следовало ожидать при загрузке. - person brettsam; 16.04.2016
comment
Просто примечание: похоже, что в текущей версии привязок базы данных Cosmos вообще нет встроенных 429 повторных попыток. - person Stephen Cleary; 03.05.2020