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

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

Используйте processEvent или processEventBatch

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

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

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

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

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

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

Используйте LoadBalancingStrategy.BALANCED или LoadBalancingStrategy.GREEDY

При использовании LoadBalancingStrategy.BALANCED компонент EventProcessorClient резервирует один раздел для каждого цикла балансировки нагрузки. Если в концентраторе событий есть 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.