С помощью веб-приложений Azure я могу масштабировать множество полезных показателей, таких как дисковый или сетевой ввод-вывод, ЦП и использование памяти. До сих пор в документации по функциям Azure кажется, что только вы получить использование памяти в качестве метрики для масштабирования при использовании динамического плана обслуживания. Из того, что я читал, есть дополнительная недокументированная магия, которая определяет, как она масштабируется; Я действительно хочу, чтобы это было полностью задокументировано.
Если у меня есть приложение-функция, которое иногда использует много ЦП, иногда много дискового или сетевого ввода-вывода, иногда в основном ОЗУ - сочетание показателей или даже только одно из первых двух, будет ли работать масштабирование функций?
Более конкретно для моего случая или предполагаемого случая, если функция использует триггер очереди и имеет смесь требований к ресурсам в зависимости от каждого конкретного выполнения, но все задания соответствуют выбранному уровню памяти, будет ли масштабирование учитывать другие факторы. чем память, такая как ЦП и ввод-вывод, или количество сообщений в очереди и число, обрабатываемое на одной машине, чтобы распределить нагрузку на дополнительные машины?
Меня беспокоит то, что, если задания не используют много памяти, например, но имеют высокий ЦП или сетевой трафик, у меня будет много заданий на одной машине, которые будут медленно работать в ожидании других ресурсов, вместо того, чтобы распределять нагрузку. в нескольких экземплярах.
Наше текущее решение / услуга масштабируется только в зависимости от ЦП, поэтому кажется, что функции заменяют одну проблему другой аналогичной проблемой. Для завершения некоторых работ требовалось бесконечно, потому что они были связаны с вводом-выводом, и служба предоставляла им избыточное количество ресурсов для небольшого числа рабочих пчел. На самом деле мы написали код, который вращается на процессоре, чтобы имитировать высокую загрузку, чтобы предложить службе масштабирование, что довольно дрянно и расточительно.
