концентраторы событий получают медленные

Я тестирую концентраторы событий Azure на одном компьютере.

У меня есть концентратор событий с максимально допустимыми разделами (32).

Я обнаружил, что запись в хаб выполняется очень быстро - в основном порядка 1000 сообщений в секунду. Однако, когда я пытаюсь извлечь данные, я не получаю почти такой же пропускной способности. Вывод 1000 сообщений занимает около минуты.

Я пробовал как прямой подход с 32 параллельными приемниками, так и подход EventHost. Оба примерно одинаковы по скорости.

Я оставил все настройки по умолчанию.

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

Обновление: вот код, который я использую для извлечения данных из концентраторов событий (прямая версия):

let startDirectPump
    stream
    eventHubConnectionString
    storageConnectionString
    fPost =
    let tag = "startEventHubPump"
    let client = EventHubClient.CreateFromConnectionString(eventHubConnectionString,stream)
    let cg = client.GetDefaultConsumerGroup()
    let runtimeInfo = client.GetRuntimeInformation()
    let pCount = runtimeInfo.PartitionCount
    let receivers =
        [for p in 0..pCount - 1 ->
            cg.CreateReceiver(runtimeInfo.PartitionIds.[p],System.DateTime.UtcNow)
            ]
    let tasks =
        receivers
        |> List.map (fun r ->
            async {
                try 
                    while not r.IsClosed do
                        let! e = r.ReceiveAsync() |> Async.AwaitTask
                        if e <> null then
                            fPost e
                with ex ->
                    do! Async.Sleep 5000
                    Logging.logex "eh receive" ex
            })
    tasks |> Async.Parallel |> Async.Ignore |> Async.Start
    client

person fwaris    schedule 04.02.2015    source источник


Ответы (4)


Если ваша цель - перекачивать данные в Storm, на самом деле выполняется интеграция, чтобы предоставить адаптер для получения данных EventHub в Storm. См. Код @ https://github.com/hdinsight/hdinsight-storm-examples/tree/master/lib

Что касается выяснения проблемы с задержкой, вы можете попробовать несколько вещей:

  • Включите счетчик производительности ServiceBus, чтобы увидеть задержку приема. Вы можете следовать примеру @ https://code.msdn.microsoft.com/windowsazure/Service-Bus-Messaging-7a0a0761
  • Ваш код использует DateTimeUtc в качестве маркера контрольной точки. Интересно, можете ли вы вместо этого попробовать использовать смещение в качестве маркера, чтобы увидеть, есть ли улучшение производительности (использование datetime в качестве маркера потребует перевода на стороне службы).
  • Убедитесь, что ваш клиент работает в том же регионе Azure, что и EventHub.

Спасибо - Эрик Лам (MSFT)

person Hiu-Ming Eric Lam - MSFT    schedule 05.03.2015

что ты используешь для измерения скорости? Вы храните данные в базе данных и проверяете, все ли данные получены? Эта проблема может быть где-то еще, может быть в вашей вставке базы данных. Некоторое время требуется, когда он сначала пытается взять в аренду разделы. Вы можете попробовать отправить еще одно сообщение, когда оно нагреется. И проверьте, занимает ли еще столько же времени.

person Pragmatic    schedule 05.02.2015
comment
Я пока пользуюсь настенными часами. Разница явно заметна. На данный момент я просто выгружаю сообщения в консоль в виде простых строк. Я не думаю, что это узкое место. Я проведу более длительный тест, чтобы увидеть, имеет ли это значение. - person fwaris; 06.02.2015
comment
Я не заглядывал под прикрытие, но могло ли случиться так, что пропускная способность ограничена из-за одного соединения AMQP / одной машины. Не знаю, означает ли 32 раздела, что открыто 32 соединения - по одному на каждый раздел? - person fwaris; 06.02.2015
comment
@fwaris, Вы выяснили причину этого? - person Pragmatic; 18.02.2015
comment
Мы столкнулись с подобной проблемой. Сетевая задержка может быть здесь виновата. Вы можете попробовать с «короткими сообщениями». Другой способ - опробовать среду Azure, например запустить код в рабочей роли. - person Pragmatic; 21.02.2015
comment
К сожалению, мне не удалось определить основную причину. Сообщения очень короткие (около 200 символов в формате json). Я не считаю, что задержка в сети является проблемой, поскольку мы находимся в корпоративной сети. Также попробовал сайт Azure. На данный момент я считаю, что для повышения пропускной способности необходимо использовать несколько одновременных подключений, возможно, с разных машин. Возможно, нам придется искать альтернативы, такие как Kafka, чтобы обойти эту проблему. - person fwaris; 26.02.2015
comment
Так быть не должно. Мы работаем над подобными вещами. Мы легко можем получить 1000 сообщений на небольшие сообщения. В случае более крупного сообщения мы не смогли бы получить их в таком темпе. Но когда мы протестировали рабочую роль Azure, скорость получения нами резко возросла. Конечно, он не может превышать 2 МБ в секунду, если вы используете 1 единицу пропускной способности. - person Pragmatic; 28.02.2015
comment
Спасибо за информацию. Я пробовал лазурный веб-сайт - это не рабочая роль - но не увидел значительного увеличения. Код очень прост, поэтому не уверен, в чем проблема. Наша цель - перекачивать данные в Apache Storm, поэтому на данный момент мы напрямую используем веб-сокеты. - person fwaris; 05.03.2015
comment
спасибо, попробую apache kafka, мне не нравится слышать о медленной задержке облака, но меня это не удивляет. - person hamish; 05.07.2018

Я использовал тот же подход, что и вы, и не смог получить никаких событий / данных. Через некоторое время я узнал о EventProcessorHost, который немного более подробен, но работает нормально.

person Stefan Turcanu    schedule 12.06.2016

вам поможет увеличение пропускной способности.

person Community    schedule 13.01.2019