Azure Stream Analytics работает слишком медленно - значения времени также не имеют отношения

Мы хотим перенести наши выделенные серверы на платформу Azure для упрощения масштабирования и исследовали множество служб Azure для наших нужд. Итак, одна из служб Azure, которую мы хотим использовать, - это Azure Stream Analytics (ASA).

Мы добавили несколько платформ Azure в соответствии с нашими потребностями для выполнения некоторых тестов (пока не важно, для чего они нужны). Вот структура:

SimpleApp (отправка запроса, не в Azure) -> Концентратор событий 1 (EH1) -> ASA -> Концентратор событий 2 (EH2) -> Приложение-функция (FA)

  • SimpleApp отправляет простой HTTP-запрос GET классическому выделенному серверу с именем TESTSERVER. Он занимает максимум 100–150 мс и представляет время начала. После этого он отправляет сообщение в EH1.
  • Запрос ASA выглядит просто так: SELECT * INTO [Output] FROM [Input]
  • Приложение-функция отправляет простой HTTP-запрос GET на TESTSERVER для определения времени окончания.

Мы были шокированы, когда увидели результаты наших журналов TESTSERVER. Это занимает 4000-5000 мс!

Затем мы начали исследовать проблему. Проверенные значения, такие как EventEnqueuedUtcTime и EventProcessedUtcTime, чтобы определить, какой блок вызывает эту медлительность. Но эти значения времени совершенно не важны. Например; EventEnqueuedUtcTime должно быть меньше EventProcessedUtcTime, но не! Таким образом, это показывает, что серверы времени могут быть разными даже в разных блоках Azure, и мы не можем использовать их для измерения. Я ошибся?

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

SimpleApp (отправка запроса, не в Azure) -> Концентратор событий 1 (EH1) -> Приложение-функция (FA1) -> Концентратор событий 2 (EH2) -> Приложение-функция 2 (FA2)

Второй шок ... Он занимает всего ~ 400 мс!

Затем мы провели множество тестов с другой архитектурой, которая содержит ASA, но все они слишком медленные для нас.

Испытывали ли вы какие-либо проблемы с производительностью с ASA? Не могли бы вы поделиться своим опытом и общим временем, затраченным вашими потоками?

С наилучшими пожеланиями.


azure performance azure-functions azure-stream-analytics azure-eventhub
person msapcili    schedule 25.06.2016    source источник
comment
чего вы пытаетесь достичь с помощью SA? Я не могу понять, почему у вас есть SA в середине вашего потока.   -  person Thomas    schedule 25.06.2016
comment
Привет @Thomas, этот поток - лишь простая часть архитектуры. Я упростил его, чтобы сосредоточить внимание на основной проблеме. ASA не находится в середине потока в реальном сценарии, но мы хотим использовать его для потоковой обработки, и он должен быть достаточно быстрым для предоставления аналитики в реальном времени. Нам также нужны временные окна, чтобы измерять количество посещений пользователей и уведомлять их, если границы кампании достигнуты.   -  person msapcili    schedule 25.06.2016
comment
Хорошо, но вы не хотите делать SELECT * внутри вашего потока. Вы перенаправляете все свои данные из EventHub в SA, чтобы ваш поток не замедлялся. Параллельно вы можете запросить SA, и это не повлияет на время обработки сообщений.   -  person Thomas    schedule 26.06.2016
comment
@Thomas, это напрямую не влияет на мой основной поток, но это еще один важный поток для уведомлений. Он также должен быть достаточно быстрым, его временные затраты не должны быть больше 1, 1,5 сек. Потому что я должен уведомить указанного пользователя по результату обработки потоковых данных. Спасибо за вашу заботу о потоке, но настоящая проблема в том, что ASA не является быстрым устройством, как описано. Обработка потока в реальном времени. Процессор реального времени не может быть таким, он поддерживает временное окно посекундно, но я не могу получить от него результат за секунду.   -  person msapcili    schedule 26.06.2016

Ответы (1)


arrow_upward
5
arrow_downward

При объединении всех событий в хронологическом порядке из концентратора событий возникает задержка.

ASA посетит все разделы из EH, получит данные и организует события в хронологическом порядке. Это означает, что данные должны поступать во все разделы в EH. Я думаю, это также объясняет странное поведение, которое вы наблюдаете с EventProcessedUtcTime, возможно, из-за того, что события упорядочены, логическое время обработки опережает фактическое время прибытия. Хотя я в этом не уверен, потому что не знаю внутренней работы ASA.

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

Вы можете избежать слияния, разделив поле partitionid из EH. Убедитесь, что вы также отправляете данные в правильный раздел в EH.

Дополнительную информацию можно найти здесь, в блоге Stream Analytics < / а>.

person Waaghals    schedule 27.06.2016
comment
большое спасибо за ваш вклад. Согласно статье, которой вы поделились: Мой эксперимент показывает с помощью запроса select *, если я отправляю 1 событие в секунду в концентратор событий, сквозная задержка составляет около 6 секунд. Это именно то, что я ' я испытал. Я проведу несколько тестов и дам вам знать. С Уважением. - person msapcili; 27.06.2016
comment
Привет @Waaghals. Большое вам спасибо еще раз. Мы также поговорили с нашим представителем Microsoft и согласились, что наши проблемы с производительностью связаны с архитектурой, на которую вы указали. Но такая медлительность по-прежнему неприемлема для процессора реального времени, поэтому мы постараемся связаться с командой ASA, чтобы получить больше советов. С наилучшими пожеланиями, - person msapcili; 04.07.2016
comment
@msapcili У вас хоть раз падал даже больше 6с? - person John; 07.08.2019
comment
@John Я изменил архитектуру и не использовал ASA после этой проблемы. - person msapcili; 25.08.2019