Устранение неполадок с производительностью Центры событий Azure

В этой статье приводятся решения распространенных проблем с производительностью, которые могут возникнуть при использовании библиотеки Центров событий в пакете SDK Azure для Java. Если вы ищете решения других распространенных проблем, которые могут возникнуть при использовании Центров событий, см. раздел "Устранение неполадок" Центры событий Azure.

Использование processEvent или processEventBatch

При использовании обратного processEvent вызова каждый EventData экземпляр получил вызов кода. Этот процесс хорошо работает с низким или умеренным трафиком в концентраторе событий.

Если в концентраторе событий ожидается высокий трафик и высокая пропускная способность, совокупная стоимость непрерывного вызова препятствует производительности EventProcessorClient. В этом случае следует использовать processEventBatch.

Для каждой секции обратный вызов вызывается по одному за раз. Высокая скорость обработки в обратном вызове препятствует производительности, так как она EventProcessorClient не продолжает отправлять больше событий вниз и не запрашивать больше EventData экземпляров из службы Центров событий.

Затраты на проверка назначение

При использовании Хранилище BLOB-объектов Azure в качестве хранилища проверка point есть сетевая стоимость для проверка назначения, так как он делает HTTP-запрос и ожидает ответа. Этот процесс может занять до нескольких секунд из-за задержки сети, производительности Хранилище BLOB-объектов Azure, расположения ресурсов и т. д.

Контрольные точки после обработки каждого EventData экземпляра препятствуют производительности из-за затрат на выполнение этих HTTP-запросов. Вы не должны проверка point, если обратный вызов не обрабатывал никаких событий, или вы должны проверка point после обработки некоторого количества событий.

Использование LoadBalancingStrategy.BALANCED или LoadBalancingStrategy.GREEDY

При использовании LoadBalancingStrategy.BALANCEDEventProcessorClient утверждения одной секции для каждого цикла балансировки нагрузки. Если в концентраторе событий есть 32 секции, для утверждения всех секций требуется 32 итерации балансировки нагрузки. Если пользователи знают, что выполняется определенное EventProcessorClient количество экземпляров, они могут использовать LoadBalancingStrategy.GREEDY их общий доступ к секциям в одном цикле балансировки нагрузки.

Дополнительные сведения о каждой стратегии см. в статье LoadBalancingStrategy.java в репозитории azure-sdk-for-java.

Настройка prefetchCount

Значение предварительной выборки по умолчанию равно 500. Когда откроется ссылка на получение AMQP, она помещает 500 кредитов по ссылке. Предположим, что каждый EventData экземпляр является одним кредитом на связь, EventProcessorClient предварительная выборка составляет 500 EventData экземпляров. При использовании всех событий клиент обработчика добавляет 500 кредитов на ссылку для получения дополнительных сообщений. Этот поток повторяется, пока EventProcessorClient у него по-прежнему есть владение секцией.

Настройка prefetchCount может иметь последствия для производительности, если число слишком низко. Каждый раз, когда amQP получает ссылку на кредиты, удаленная служба отправляет ACK. В сценариях с высокой пропускной способностью затраты на выполнение тысяч запросов клиентов и пакетов управления службами могут препятствовать производительности.

Настройка prefetchCount может иметь последствия для производительности, если число слишком велико. Если кредиты x помещаются в строку, служба Центров событий знает, что она может отправлять не более x сообщений. При получении каждого EventData экземпляра он помещается в очередь в памяти, ожидая обработки. Большое количество EventData экземпляров в очереди может привести к очень высокому использованию памяти.

Следующие шаги

Если рекомендации по устранению неполадок, описанные в этой статье, не помогают устранить проблемы при использовании клиентских библиотек пакета SDK Azure для Java, рекомендуется отправить проблему в репозитории Azure SDK для Java GitHub.