Функция Performance Azure с несколькими выходными привязками - PullRequest
Новая
       37

Функция Performance Azure с несколькими выходными привязками

0 голосов
/ 23 января 2019

Привет всем, кто читает это,

Мы написали функцию маршрутизатора на Azure в плане приложения, который получает сообщения от iothub, и в зависимости от типа сообщения мы направляем наше сообщение другому концентратору событий.

Ранее в этой функции у нас было 6 привязок к концентраторам событий. Недавно мы добавили еще 3 типа сообщений, поэтому еще 3 привязки к 3 концентраторам событий

В этой функции не происходит никакой обработки сообщений, но теперь мы видим, чтомы тратим в 16 раз больше времени на функцию маршрутизации.

Есть ли проблема с производительностью при наличии нескольких выходных привязок.Мы не видим увеличения загрузки входящих сообщений.

Мы работаем над функциями Azure 1.0 (Runtime version: 1.0.12205.0 (~ 1))

С уважением, Бен

Упрощенный пример кода функции маршрутизации 

public static class IotHubRouterFunction
{
    [FunctionName("IotHubRouterFunction")]
    public static void Run([EventHubTrigger("%iothub%", Connection = "IothubRouterListen")]EventData myEventHubData,
        [EventHub("%msg1-eventhub%", Connection = "msg1event")] ICollector<EventData> eventHub4Dmsg1Event,
        [EventHub("%msg2-eventhub%", Connection = "msg2event")] ICollector<EventData> eventHub4Dmsg2Event,
        [EventHub("%msg3-eventhub%", Connection = "msg3event")] ICollector<EventData> eventHub4Dmsg3Event,
        //...  like 6 more bindings like this
        ILogger logger
    )
    {
        try
        {
            var messageType = GetValue(myEventHubData.Properties, "type");

            // routing
            switch (messageType)
            {
                case "msg1event":
                {
                    eventHub4DevicesStatusChanged.Add(eventHub4Dmsg1Event);
                    break;
                }
                case "msg2event":
                {
                    eventHub4MeasurementLog.Add(eventHub4Dmsg2Event);
                    break;
                }
                case "msg3event":
                {
                    eventHub4DeviceDiscovered.Add(eventHub4Dmsg3Event);
                    break;
                }
                //6 more cases like this
                default:
                {
                    logger.LogError("Unrouteable message of type: {messageType}", messageType);
                    break;
                }
            }
        }
        catch (Exception ex)
        {
            //removed
        }
    }        
}

При 6 привязках сообщение проходит через функцию маршрутизатора при 50 мс При 9 привязках сообщение сканирует через функцию маршрутизатора при 800 мс

CPUтакже подняли на 30% с апплана (мы масштабировали дополнительно, поэтому у нас это под контролем, но почему так много, что вызывает это)

Ответы [ 2 ]

0 голосов
/ 15 февраля 2019

Немного поздно с продолжением того, что произошло

В конце концов мы узнали, что происходит У нас есть несколько экземпляров нашего плана приложения но старое решение для мониторинга показало среднее значение процессора и памяти в целом для экземпляров applan.

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

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

Мы перезапустили функцию, и все проблемы исчезли.

Все еще задаюсь вопросом, было ли это в нашем коде, что заставило его пройти сквозь крышу или что-то произошло в лазури, что заставило его сойти с ума.

: - * s * 1013

0 голосов
/ 24 января 2019

Когда вы используете функцию Azure в плане обслуживания приложения, вам нужно следить за параметрами производительности, такими как масштабирование. Вы исследовали, что ваша функция не перегружена?

С другой стороны, как часть вашего дизайна этот подход мне не подходит. При таком количестве привязок могут возникнуть потенциальные проблемы с производительностью, и что, если в будущем предполагается добавить больше привязок? Если вы не выполняете никаких операций, вам не следует перенаправлять сообщения.

Сетка событий

Мы можем использовать для этого сетки событий. В зависимости от темы, центр IoT публикует событие в теме, а события используются подписчиками в вашем случае другими центрами событий. Вы также получаете преимущества микро-биллинга (без сервера) и автоматического масштабирования. https://docs.microsoft.com/en-us/azure/event-grid/overview

...