Мы хотим перенести наши выделенные серверы на платформу Azure, чтобы упростить и исследовать множество услуг Azure для наших нужд. Поэтому одной из услуг Azure, которую мы хотим использовать, является Azure Stream Analytics (ASA).Azure Stream Analytics работает слишком медленно - также значения времени невосприимчивы
Мы добавили несколько платформ Azure в соответствии с нашими потребностями для проведения некоторых тестов (на данный момент это не важно, каковы они для этого). Вот структура:
SimpleApp (отправка запроса, а не в Azure) -> Event Hub 1 (EH1) -> ASA -> Event Hub 2 (EH2) -> Функция App (FA)
- SimpleApp отправляет простой HTTP-запрос GET на классический выделенный сервер , который называется TESTSERVER. Он занимал максимум 100-150 мс, и он представляет наше время начала. После этого он отправляет сообщение в EH1.
- запрос ASA прост, как это: SELECT * INTO [Выход] FROM [Input]
- Функция App отправляет простой запрос HTTP GET на TestServer для идентифицирующего времени окончания.
У нас в шоке, когда мы видим результаты наших TestServer бревен. Это заняло 4000-5000мс!
Затем мы начали исследовать проблему. Проверенные значения, такие как EventEnqueuedUtcTime и EventProcessedUtcTime, чтобы определить, какой блок вызывает эту медлительность. Но эти значения времени совершенно неактуальны. Например; EventEnqueuedUtcTime должно быть меньше EventProcessedUtcTime, но нет! Таким образом, это показывает, что серверы времени могут быть разными даже в разных блоках Azure, и мы не можем их использовать для измерения. Я ошибаюсь?
В любом случае, после этого мы подозревали, что, возможно, последнее Приложение Azure Function может вызвать эту медлительность. Мы думали, что, возможно, функция Event Hub Trigger не работает. Таким образом, мы разработали новую тестовую систему:
SimpleApp (Requesting Request, Not In Azure) -> Event Hub 1 (EH1) -> Function App (FA1) -> Event Hub 2 (EH2) -> Function App 2 (FA2)
Второй удар ... Всего потребовалось всего ~ 400 мс!
Затем мы выполнили множество тестов с различной архитектурой, которая содержит ASA, но все они слишком медленны для нас.
Испытывали ли вы какие-либо проблемы с производительностью с ASA? Не могли бы вы поделиться своим опытом и общим потреблением времени?
С уважением.
Что вы пытаетесь достичь с помощью SA? Я не могу понять, почему у вас есть SA в середине вашего потока. – Thomas
Здравствуйте @Thomas, этот поток является лишь простой частью архитектуры. Я упростил его, чтобы сосредоточить основной вопрос. ASA не находится в середине потока в реальном сценарии, но мы хотим использовать его для обработки потока, и он должен быть достаточно быстрым для предоставления ** аналитики ** в реальном времени. Нам также нужно время-окнирование, чтобы измерять количество посещений пользователей и уведомлять их о достижении границ кампании. – msapcili
Хорошо, но вы не хотите делать SELECT * внутри вас. Вы пересылаете все свои данные из EventHub в SA, чтобы в вашем потоке не замедлилось. Параллельно вы можете запросить SA, и вы не будете иметь никакого влияния на время обработки сообщений – Thomas