Руководство по производительности службы Azure SignalR

Одним из ключевых преимуществ использования службы Azure SignalR является простота масштабирования приложений SignalR. В крупномасштабном сценарии производительность является важным фактором.

В этой статье рассматриваются следующие вопросы:

• Факторы, влияющие на производительность приложения SignalR.
• Типичная производительность в разных сценариях использования.
• Среда и средства, которые можно использовать для создания отчета о производительности.

Быстрая оценка с помощью метрик

Вы можете легко отслеживать службу на портале Azure. На странице метрик экземпляра SignalR можно выбрать метрики загрузки сервера , чтобы увидеть "давление" службы.

На диаграмме показано вычислительное давление службы SignalR. Вы можете протестировать сценарий и проверить эту метрику, чтобы решить, следует ли масштабировать. Задержка внутри службы SignalR остается низкой, если загрузка сервера ниже 70%.

Определения терминов

Входящий трафик: входящее сообщение в службу Azure SignalR.

Исходящий трафик: исходящее сообщение из службы Azure SignalR.

Пропускная способность: общий размер всех сообщений в 1 секунду.

Режим по умолчанию: рабочий режим по умолчанию при создании экземпляра службы Azure SignalR. Служба Azure SignalR ожидает, что сервер приложений установит подключение к нему, прежде чем принимать любое клиентское подключение.

Бессерверный режим: режим, в котором служба Azure SignalR принимает только клиентские подключения. Подключение к серверу не разрешено.

Обзор

Служба Azure SignalR определяет семь стандартных уровней для разных возможностей производительности. В этом руководстве приведены ответы на следующие вопросы:

• Какова типичная производительность службы Azure SignalR для каждого уровня (единица)?

• Соответствует ли служба Azure SignalR требованиям к пропускной способности сообщений (например, отправка 100 000 сообщений в секунду)?

• Как для моего конкретного сценария выбрать правильный уровень?

• Какой тип сервера приложений (размер виртуальной машины) подходит для меня? Сколько из них следует развернуть?

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

Это руководство не может охватывать все сценарии (и различные варианты использования, размеры сообщений, шаблоны отправки сообщений и т. д.). Но он предоставляет некоторые методы, которые помогут вам:

• Оцените приблизительное требование для входящих или исходящих сообщений.
• Найдите соответствующие уровни, проверив таблицу производительности.

Аналитические сведения о производительности

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

Методология

Пропускная способность и задержка являются двумя типичными аспектами проверки производительности. Для службы Azure SignalR каждый уровень SKU имеет собственную политику регулирования пропускной способности. Политика определяет максимальную допустимую пропускную способность (входящий и исходящий трафик) в качестве максимальной пропускной способности , когда 99 процентов сообщений имеют задержку менее 1 секунды.

Задержка — это интервал времени с момента отправки сообщения через подключение до получения ответного сообщения от службы Azure SignalR. Рассмотрим эхо в качестве примера. Каждое подключение клиента добавляет метку времени в сообщении. Центр сервера приложений отправляет исходное сообщение клиенту. Таким образом, задержка распространения легко вычисляется каждым клиентским подключением. Метка времени добавляется для каждого сообщения в случае широковещательной трансляции, при отправке в группу и при отправке на подключение.

Для имитации тысяч одновременных подключений клиентов в Azure создаются несколько виртуальных машин в виртуальной частной сети. Все эти виртуальные машины подключаются к одному экземпляру службы Azure SignalR.

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

Факторы производительности

Следующие факторы влияют на производительность SignalR.

• Уровень SKU (ЦП/память)
• Количество подключений
• Размер сообщения
• Скорость отправки сообщений
• Тип транспорта (WebSocket, Server-Sent-Event или Long-Polling)
• Сценарий использования (стоимость маршрутизации)
• Подключения к серверу приложений и службам (в режиме сервера)

Ресурсы компьютера

Теоретически емкость службы Azure SignalR ограничена вычислительными ресурсами: ЦП, памятью и сетью. Например, больше подключений к службе Azure SignalR приводит к тому, что служба будет использовать больше памяти. Для большего трафика сообщений (например, каждое сообщение больше 2048 байт), служба Azure SignalR должна тратить больше циклов ЦП для обработки трафика. Между тем пропускная способность сети Azure также накладывает ограничение на максимальный трафик.

Тип транспорта

Тип транспорта — это еще один фактор, влияющий на производительность. Три типа:

• WebSocket: WebSocket — это двунаправленный и полно дуплексный протокол связи через одно TCP-подключение.
• Server-Sent-Event: Server-Sent-Event является однонаправленным протоколом для отправки сообщений с сервера на клиент.
• Long-Polling: Long-Polling требует, чтобы клиенты периодически опрашивать информацию с сервера через HTTP-запрос.

Для того же API в одинаковых условиях WebSocket имеет лучшую производительность, сервер-Sent-Event медленнее, и Long-Polling является самым медленным. Служба Azure SignalR рекомендует WebSocket по умолчанию.

Стоимость маршрутизации сообщений

Стоимость маршрутизации сообщений также ограничивает производительность. Служба Azure SignalR играет роль маршрутизатора сообщений, который направляет сообщение из набора клиентов или серверов на другие клиенты или серверы. Для другого сценария или API требуется другая политика маршрутизации.

Для echo клиент отправляет сообщение самому себе, и назначением маршрутизации также является он сам. Этот шаблон имеет наименьшую стоимость маршрутизации. Но для трансляции, отправки в группу и отправки в подключение служба Azure SignalR должна искать целевые подключения через внутреннюю распределенную структуру данных. Эта дополнительная обработка использует больше ЦП, памяти и пропускной способности сети. В результате производительность замедляется.

В режиме по умолчанию сервер приложений также может стать узким местом для определенных сценариев. Пакет SDK Azure SignalR должен вызывать концентратор, хотя он поддерживает динамическое соединение с каждым клиентом с помощью сигналов пульса.

В бессерверном режиме клиент отправляет сообщение по протоколу HTTP, что не так эффективно, как WebSocket.

Протокол

Другим фактором является протокол JSON и MessagePack. MessagePack меньше размера и поставляется быстрее, чем JSON. MessagePack может не повысить производительность, однако. Производительность службы Azure SignalR не зависит от протоколов, так как во время пересылки сообщений от клиентов к серверам и наоборот она не декодирует нагрузку сообщений.

Поиск правильного номера SKU

Как оценить входящий или исходящий объем или найти, какой уровень подходит для конкретного варианта использования?

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

Быстрая оценка

Для быстрой оценки используйте следующие параметры по умолчанию:

• Тип транспорта — WebSocket.
• Размер сообщения составляет 2 048 байт.
• Сообщение отправляется каждые 1 секунду.
• Служба Azure SignalR находится в режиме по умолчанию.

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

Эхо дает максимальную пропускную способность для входящего трафика, так как она имеет наименьшую стоимость маршрутизации. Широковещательная передача определяет максимальную пропускную способность исходящего сообщения.

Не превышайте выделенные значения в следующих двух таблицах.

Входящий трафик и пропускная способность исходящего трафика — это общий размер сообщения в секунду. Ниже приведены формулы для них:

  inboundBandwidth = inboundConnections * messageSize / sendInterval
  outboundBandwidth = outboundConnections * messageSize / sendInterval

• inboundConnections: количество подключений, отправляемых сообщением.

• outboundConnections: количество подключений, получающих сообщение.

• messageSize: размер одного сообщения (среднее значение). Небольшое сообщение, которое меньше 1024 байтов, влияет на производительность, аналогичное 1024-байтового сообщения.

• sendInterval: время отправки одного сообщения. Как правило, это 1 секунда в сообщение, что означает отправку одного сообщения каждые секунды. Меньший интервал означает отправку большего сообщения за период времени. Например, 0,5 секунды на сообщение означает отправку двух сообщений каждые секунды.

• Подключения: зарезервированное максимальное пороговое значение для службы Azure SignalR для каждого уровня. Если количество подключений увеличивается ещё больше, это приводит к ограничению подключений.

Оценка сложных вариантов использования

Более крупный размер сообщения или другая скорость отправки

Реальный вариант использования сложнее. Он может отправлять сообщение размером более 2 048 байт, или скорость отправки сообщений не является одним сообщением в секунду. Давайте рассмотрим трансляцию Unit 100 в качестве примера, чтобы узнать, как оценить его производительность.

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

Следующая формула легко вывести на основе предыдущей формулы:

outboundConnections = outboundBandwidth * sendInterval / messageSize

Для единицы 100 максимальная пропускная способность исходящего трафика составляет 400 МБ из предыдущей таблицы. Для размера сообщения размером 20 КБ максимальный исходящий трафик должен составлять 400 МБ * 5 /20 КБ = 100 000, что соответствует реальному значению.

Смешанные варианты использования

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

1. Разделите варианты смешанного использования на четыре основных варианта использования.
2. Вычислите максимальную пропускную способность входящего и исходящего сообщения с помощью приведенных выше формул отдельно.
3. Суммирует вычисления пропускной способности, чтобы получить общую максимальную пропускную способность для входящего и исходящего трафика.

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

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

Примеры

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

В режиме по умолчанию сервер приложений создает пять подключений к серверу со службой Azure SignalR. Сервер приложений использует пакет SDK службы Azure SignalR по умолчанию. В следующих результатах теста производительности подключение сервера увеличивается до 15 (или более для трансляции и отправки сообщения в большую группу).

Разные варианты использования имеют разные требования для серверов приложений. Для трансляции требуется небольшое количество серверов приложений. Эхо или отправка на соединение требует много серверов приложений.

Во всех случаях использования размер сообщения по умолчанию составляет 2 048 байт, а интервал отправки сообщений составляет 1 секунду.

Режим по умолчанию

Клиенты, серверы веб-приложений и служба Azure SignalR участвуют в режиме по умолчанию. Каждый клиент соответствует одному подключению.

Эхо

Сначала веб-приложение подключается к службе Azure SignalR. Во-вторых, многие клиенты подключаются к веб-приложению, который перенаправляет клиентов в службу Azure SignalR с маркером доступа и конечной точкой. Затем клиенты устанавливают подключения WebSocket со службой Azure SignalR.

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

На следующем диаграмме элементы 5–8 (выделенный красным трафик) находятся в цикле. Цикл выполняется по умолчанию (5 минут) и получает статистику всех задержек сообщений.

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

В этом случае каждый клиент вызывает концентратор, определенный на сервере приложений. Концентратор просто вызывает метод, определенный в исходной стороне клиента. Этот концентратор является самым упрощенным концентратором для эха.

        public void Echo(IDictionary<string, object> data)
        {
            Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
        }

Даже для этого простого концентратора давление трафика на сервер приложений заметно по мере увеличения входящей нагрузки эхо-сообщений. Это давление на трафик требует большого количества серверов приложений для больших уровней SKU. В следующей таблице перечислены количество серверов приложений для каждого уровня.

Вещание

Для трансляции, когда веб-приложение получает сообщение, оно передается всем клиентам. Чем больше клиентов есть для трансляции, тем больше трафика сообщений на всех клиентах. См. следующую схему.

Небольшое число клиентов вещает. Пропускная способность входящего сообщения небольшая, но пропускная способность исходящего трафика огромна. Пропускная способность исходящего сообщения увеличивается по мере увеличения скорости подключения клиента или широковещательной трансляции.

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

Количество клиентов вещания, публикующих сообщения, не превышает четырех. Они нуждаются в меньшем количестве серверов приложений по сравнению с эхом , так как объем входящих сообщений мал. Для обеспечения SLA и производительности достаточно двух серверов приложений. Но следует увеличить число стандартных подключений к серверу, чтобы избежать дисбаланса, особенно для единицы, превышающей 50.

Отправить в группу

В случае отправки в группу наблюдается похожий шаблон трафика с трансляцией. Разница заключается в том, что после того, как клиенты устанавливают подключения WebSocket со службой Azure SignalR, они должны присоединиться к группам, прежде чем они смогут отправить сообщение в определенную группу. На следующей схеме показан поток трафика.

Количество участников группы и количество групп — это два фактора, влияющих на производительность. Чтобы упростить анализ, мы определим два типа групп:

• Небольшая группа: каждая группа имеет 10 подключений. Число группы равно (максимальному числу подключений) / 10. Например, для единицы 1, если имеется 1000 подключений, то у нас есть 1000 / 10 = 100 групп.

• Большая группа: номер группы всегда равен 10. Число членов группы равно (максимальному количеству подключений) / 10. Например, для единицы 1, если имеется 1000 подключений, каждая группа имеет 1000 / 10 = 100 членов.

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

Небольшая группа

Стоимость маршрутизации значительна для отправки сообщений многим небольшим группам. В настоящее время реализация службы Azure SignalR достигает предельной стоимости маршрутизации в единице 50. Добавление дополнительных ресурсов ЦП и памяти не помогает, поэтому модуль 100 не может улучшиться дальше по проектированию. Если вам нужна дополнительная пропускная способность для входящего трафика, обратитесь в службу поддержки клиентов.

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

Большая группа

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

Количество соединений для отправки не превышает 40. Бремя на сервере приложений невелика, поэтому предлагаемое количество веб-приложений невелико.

Отправка на подключение

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

Стоимость маршрутизации для отправки в подключение аналогична стоимости отправки в небольшую группу.

По мере увеличения числа подключений затраты на маршрутизацию становятся критически важным фактором, ограничивающим общую производительность. В частности, единица 20 помечает пороговое значение, в котором служба попадает в узкое место маршрутизации. Дальнейшее увеличение числа единиц не приводит к улучшению производительности, если нет смены на Premium_P2(единица >=100), что повышает возможности маршрутизации.

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

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

ASP.NET SignalR

Служба Azure SignalR предоставляет ту же емкость производительности для ASP.NET SignalR.

Бессерверный режим

Клиенты и служба Azure SignalR участвуют в бессерверном режиме. Каждый клиент соответствует одному подключению. Клиент отправляет сообщения через REST API другому клиенту или транслирует сообщения всем.

Отправка сообщений с высокой плотностью через REST API не так эффективна, как использование WebSocket. Он требует создания нового HTTP-подключения каждый раз, и это дополнительная стоимость в бессерверном режиме.

Трансляция через REST API

Все клиенты устанавливают подключения WebSocket со службой Azure SignalR. Затем некоторые клиенты начинают вещание через REST API. Отправка сообщений (входящий трафик) выполняется через HTTP Post, которая не эффективна по сравнению с WebSocket.

Отправка пользователю через REST API

Этот тест назначает имена пользователей всем клиентам перед началом подключения к службе Azure SignalR. После того как клиенты устанавливают подключения WebSocket со службой Azure SignalR, они начинают отправлять сообщения другим пользователям через HTTP Post.

Среды тестирования производительности

Для всех вариантов использования, перечисленных выше, мы провели тесты производительности в среде Azure. В большинстве случаев мы использовали 200 клиентских виртуальных машин и 100 виртуальных машин сервера приложений. Ниже приведены некоторые сведения:

• Размер виртуальной машины клиента: StandardDS2V2 (2 vCPU, память 7G)

• Размер виртуальной машины сервера приложений: StandardF4sV2 (4 vCPU, память 8G)

• Подключения к серверу SDK Azure SignalR: 15

Средства производительности

Средства производительности службы Azure SignalR можно найти на сайте GitHub.

Дальнейшие действия

В этой статье вы получили общие сведения о производительности службы Azure SignalR в типичных сценариях использования.

Дополнительные сведения о внутренних компонентах службы и масштабировании см. в следующих руководствах:

• Azure SignalR Service internals (Внутренние компоненты Службы Azure SignalR)
• Масштабирование службы Azure SignalR