Я создал свою первую большую функцию Durable в Azure, она выполняет около 12 функций действий для каждой страницы документа. На днях обработал максимум 5000 страниц. Я понимаю, что каждое действие помещает элемент в рабочие элементы Q, поэтому теоретически я написал 60 тыс. Сообщений очереди, которые также необходимо было прочитать, так что это 120 тыс. Действий.
Хранилище GPv2 LRS в Северной Европе стоит 0,003 фунта стерлингов / 10 тыс. Действий класса 2 Q
Таким образом, это 12 * 0,003 фунта стерлингов = 3,6 пенса, однако моя подписка показывает действия класса 2 Q стоимостью более 90 пенсов, что эквивалентно операциям 3M Q или 600 действиям Q на страницу. Это было значительно больше, чем мои вычислительные затраты по плану потребления за тот же период, которые составляли 29 пенсов за рассматриваемый день. Я ценю, что есть и другие сообщения, которые нужно поместить в Q, но я не ожидал такого количества!
Мне что-то не хватает с точки зрения того, как устойчивые функции используют Q, есть ли что-нибудь, на что я могу обратить внимание или отслеживать, чтобы попытаться подсчитать для одной страницы все действия Q (стоимость), которые он генерирует, чтобы я мог, возможно, решить, как уменьшить их.
Ценю любую информацию, так как я люблю надежные функции, но стоимость хранения начинает становиться непомерно высокой! Я собираюсь перейти на v1, чтобы сократить расходы, но все же хотел бы понять это, чтобы знать, является ли это просто стоимостью функций или я делаю что-то неэффективное в своих функциях.
НАИБОЛЕЕ ПОЛЕЗНОЕ ОБНОВЛЕНИЕ 3
Я создал новую версию, которая просто берет файл, и одно действие разбивает его на одностраничные PDF-файлы, а затем каждая страница обрабатывается другим действием для преобразования в PNG. Я создал новую учетную запись хранения и включил все параметры ведения журнала, и регистрация журнала оказалась наиболее полезной. Я загрузил 100-страничный PDF-файл, а затем, когда я загрузил и проанализировал журналы за период работы функции, я увидел следующее:
Примерная обработка между 10:31 и 10:43, за это время я увидел из файла журнала:
203 PutMessage (which makes sense)
203 DeleteMessage
7868 GetMessage - all from the workitems queue
26445 GetMessages - all from the control queues, breakdown was
control-00 - 6217
control-01 - 6375
control-02 - 5134
control-03 - 8719
В остальном я оставил приложение бездействующим (по плану потребления), и каждый час я вижу примерно:
3500 - GetQueueMetadata - 700 against each Q, control 00-03 and workitems
3500 - PeekMessage - 700 against each Q, control 00-03 and workitems
(Возможно, здесь отсутствовал окончательный журнал, я думаю, что он опрашивает каждый из 5 Q с каждым типом сообщения каждые 10 секунд, так что будет 3600 Q действий в час, не уверен, почему ему нужно опросить Qs элемента управления и рабочего элемента, если ничего не отправлено в обработку?)
Мне кажется, что происходит чрезмерное количество запусков GetMessage и GetMessages, в то время как функция на самом деле что-то делает, просматривая журналы, я могу предоставить журналы, если это поможет диагностировать проблему.
(если это актуально, количество экземпляров увеличилось с 0 до 8 к моменту его завершения, интересно, есть ли корреляция между экземплярами и обилием Q-запросов)
ОБНОВЛЕНИЕ 1
Итак, я выполнил следующее, которое, как я надеюсь, даст мне все вызовы функций за рассматриваемый день:
let start = datetime(2018-06-12T00:00:00);
traces
| where timestamp > start and timestamp < start + 24h
| where message startswith "function started"
| summarize count()
Это дало мне в общей сложности 19 939, что примерно правильно, поскольку, хотя есть несколько функций, только некоторые из них вызываются для каждой страницы, которую я фактически обработал, около 3500 страниц.
Затем мне удалось выяснить, как запросить метрики для Q в этой учетной записи хранения, и после того, как я разработал фильтр, я обнаружил следующее, в которое пошли все транзакции Q:
Кажется, смехотворное количество чтения Q? Просто чтобы проверить, я тоже посмотрел, и объем сообщений на Q и 25K кажется примерно правильным:
С тех пор я перешел на учетную запись хранения V1 и сегодня попробовал еще раз запустить около 8K страниц, чтобы увидеть, как будут выглядеть метрики, когда все они будут отфильтрованы до метрик для учетной записи хранения.
NB: Глядя на графики, я замечаю, что данные за 13-е кажутся более разумными, я не думаю, что изменил что-либо существенное, кроме возможного включения выборки для анализа приложений, поскольку это генерировало много данных!
ОБНОВЛЕНИЕ 2. Вчера в новой учетной записи хранения v1 наблюдаются аналогичные огромные числа обработанных 8-килобайтных страниц.
