Рекомендации по производительности службы Azure Web PubSub
Одним из ключевых преимуществ использования службы Azure Web PubSub является простота масштабирования. В крупномасштабном сценарии важным фактором является производительность.
В этом руководстве представлены факторы, влияющие на производительность службы Web PubSub. Мы описываем типичную производительность в разных сценариях использования.
Быстрая оценка с помощью метрик
Прежде чем пройти через факторы, влияющие на производительность, давайте сначала введем простой способ мониторинга давления вашей службы. На портале есть метрика с именем "Загрузка сервера".
В нем отображается вычислительная нагрузка службы Azure Web PubSub. Вы можете протестировать собственный сценарий и проверка эту метрику, чтобы решить, следует ли масштабировать. Задержка в службе Azure Web PubSub останется низкой, если загрузка сервера ниже 70 %.
Примечание.
Если вы используете единицу 50 или больше, и ваш сценарий в основном отправляется в небольшие группы (размер <группы 20), необходимо проверка отправку в небольшую группу для справки. В этих сценариях существует большая стоимость маршрутизации, которая не включена в нагрузку сервера.
Ниже приведены подробные понятия для оценки производительности.
Определения терминов
Входящее: входящее сообщение в службу Azure Web PubSub.
Исходящее: исходящее сообщение от службы Azure Web PubSub.
Пропускная способность: общий размер всех сообщений за 1 секунду.
Обзор
В этой статье содержатся ответы на следующие вопросы:
Какова типичная производительность службы Azure Web PubSub для каждого размера единицы?
Отвечает ли служба Azure Web PubSub моим требованиям к пропускной способности сообщений (например, отправка 100 000 сообщений в секунду)?
Для конкретного сценария можно выбрать правильный размер единицы?
Чтобы ответить на эти вопросы, в этом руководстве сперва дается подробное объяснение факторов, влияющих на производительность. Затем он иллюстрирует максимальное количество входящих и исходящих сообщений для типичных вариантов использования: отправка в группы через подпротокол Web PubSub, вышестоящий и REST API.
В этом руководством не рассматриваются все сценарии (и различные варианты использования, размеры сообщений, шаблоны отправки сообщений и т. д.). Но оно содержит некоторые основные сведения, позволяющие понять ограничения производительности.
Анализ производительности
В этом разделе описываются методики оценки производительности, после чего перечисляются все факторы, влияющие на производительность. В конце представлены методы, которые помогут вам оценить требования к производительности.
Методология
Пропускная способность и задержка — два типовых аспекта проверки производительности. Максимальная пропускная способность (входящий и исходящий трафик) определяется как максимальная достигнутая пропускная способность, когда 99 процентов сообщений имеют задержку менее 1 секунды. Это не жесткий предел.
Факторы производительности
В теории производительность службы Azure Web PubSub ограничена вычислительными ресурсами: ЦП, памятью и сетью. К примеру, большее количество подключений к службе Azure Web PubSub заставляет службу использовать больше памяти. Для большего трафика сообщений (например, каждое сообщение имеет размер более 2048 байт) службе Azure Web PubSub необходимо тратить больше циклов ЦП для обработки трафика.
Стоимость маршрутизации сообщений также ограничивает производительность. Служба Azure Web PubSub играет роль брокера сообщений, который маршрутизирует сообщение среди набора клиентов. Другой сценарий или API требует наличия другой политики маршрутизации.
В режиме echoклиент отправляет сообщение вышестоящему приложению, а вышестоящее приложение возвращает его клиенту. Этот шаблон имеет самую низкую стоимость маршрутизации. Однако для широковещательной передачи, отправки в группу и отправки в соединение службе Azure Web PubSub необходимо искать целевые соединения через внутреннюю распределенную структуру данных. Эта дополнительная обработка использует больше ЦП, памяти и пропускной способности сети. В результате производительность снижается.
Таким образом, нижеприведенные факторы оказывают влияние на входящую и исходящую пропускную способность:
Размер единицы (ЦП/память)
Количество подключений.
Размер сообщения
Скорость отправки сообщений
Сценарий использования (стоимость маршрутизации)
Поиск правильного размера единицы
Как оценить входящий или исходящий объем или найти, какой размер единицы подходит для конкретного варианта использования?
Каждый размер единицы имеет собственную максимальную пропускную способность для входящего трафика и исходящую пропускную способность. Плавное взаимодействие с пользователем не гарантируется после того, как входящий или исходящий трафик превышает пороговое значение.
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
- inboundConnections: количество подключений, отправляющих сообщение.
- outboundConnections: количество подключений, получающих сообщение.
- messageSize: размер одного сообщения (среднее значение). Небольшое сообщение размером менее 1024 байтов оказывает влияние на производительность, подобное сообщению размером 1024 байта.
- sendInterval: интервал отправки сообщений. Так, 1 секунда означает отправку одного сообщения каждую секунду. Меньший интервал означает отправку большего количества сообщений за период. Так, 0,5 секунды означает отправку двух сообщений каждую секунду.
- Подключение ions: максимальное пороговое значение для службы Azure Web PubSub для каждого размера единицы. Число подключений, превышающих порог, регулируется.
Предположим, что вышестоящее приложение достаточно мощное и не является узким местом в контексте производительности. Затем проверка максимальную пропускную способность для входящего и исходящего трафика для каждого размера единицы.
Пример использования
В следующих разделах рассматриваются три типичных варианта использования: отправка в группы по подпротоколу Web PubSub, активация CloudEvent и вызов REST API. Для каждого сценария в разделе перечислены текущие входящие и исходящие ресурсы для службы Azure Web PubSub. Также объясняются основные факторы, оказывающие влияние на производительность.
Во всех случаях использования размер сообщения по умолчанию составляет 2048 байтов, а интервал отправки сообщения составляет 1 секунду.
Отправка в группы по подпротоколу Web PubSub
Служба поддерживает подпротокол json.webpubsub.azure.v1, который дает клиентам возможность публиковать данные и подписываться напрямую без кругового пути к вышестоящему серверу. Этот сценарий эффективен, так как в нем не участвует сервер, а весь трафик проходит через подключение WebSocket клиентской службы.
Количество членов группы и количество групп — это два фактора, оказывающие влияние на производительность. Чтобы упростить анализ, мы определяем два типа групп:
- Большая группа: номер группы всегда равен 10. Количество членов группы равно (максимальное количество подключений)/10. Например, для единицы 1, если имеется 1000 подключений, каждая группа имеет 1000 / 10 = 100 членов.
- Малая группа: каждая группа имеет 10 подключений. Номер группы равен (максимальное количество подключений)/10. Например, для единицы 1, если имеется 1000 подключений, то у нас есть 1000 / 10 = 100 групп.
Отправка в группу требует затрат на маршрутизацию для службы Azure Web PubSub, поскольку от нее требуется нахождение целевых подключений через распределенную структуру данных. По мере увеличения числа отправляющих соединений стоимость увеличивается.
Большая группа
Для отправки в большую группу исходящая полоса пропускания становится узким местом до достижения предела стоимости маршрутизации. В таблице ниже указана максимальная пропускная способность исходящего трафика.
| Отправка в большую группу | Единица 1 | Единица 2 | Единица 10 | Единица 50 | Единица 100 | Единица 200 | Единица 500 | Единица 1000 |
|---|---|---|---|---|---|---|---|---|
| Связи | 1,000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Количество участников группы | 100 | 200 | 1,000 | 5 000 | 10 000 | 5 000 | 10 000 | 20,000 |
| Количество групп | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Входящих сообщений в секунду | 30 | 30 | 30 | 30 | 30 | 30 | 30 | 30 |
| Входящая пропускная способность | 60 Кбит/с | 60 Кбит/с | 60 Кбит/с | 60 Кбит/с | 60 Кбит/с | 60 Кбит/с | 60 Кбит/с | 60 Кбит/с |
| Исходящих сообщений в секунду | 3,000 | 6000 | 30,000 | 150 000 | 300 000 | 600,000 | 1,500,000 | 3 000 000 |
| Исходящая пропускная способность | 6 Мбит/с | 12 Мбит/с | 60 Мбит/с | 300 МБ пс | 600 МБ ps | 1200 МБ ps | 3000 МБ ps | 6000 МБ ps |
Небольшая группа
Стоимость маршрутизации значительна для отправки сообщения множеству небольших групп. В настоящее время реализация службы Azure Web PubSub достигает предела стоимости маршрутизации на уровне Unit50. Добавление дополнительных ресурсов ЦП и памяти не помогает, поэтому модуль 100 не может улучшиться дальше по проектированию. Если требуется дополнительная пропускная способность для входящего трафика, необходимо масштабировать до использования Premium_P2(единица >100).
| Отправка в небольшую группу | Единица 1 | Единица 2 | Единица 10 | Единица 50 | Единица 100 | Единица 200 | Единица 500 | Единица 1000 |
|---|---|---|---|---|---|---|---|---|
| Связи | 1,000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Количество участников группы | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Количество групп | 100 | 200 | 1,000 | 5 000 | 10 000 | 20,000 | 50,000 | 100,000 |
| Входящих сообщений в секунду | 200 | 400 | 2 000 | 10,000 | 10,000 | 20,000 | 50,000 | 100,000 |
| Входящая пропускная способность | 400 Кбит/с | 800 Кбит/с | 4 Мбит/с | 20 Мбит/с | 20 Мбит/с | 40 Мбит/с | 100 Мбит/с | 200 Мбит/с |
| Исходящих сообщений в секунду | 2 000 | 4000 | 20,000 | 100,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Исходящая пропускная способность | 4 МБ/с | 8 МБ ps | 40 Мбит/с | 200 Мбит/с | 200 Мбит/с | 400 МБ ps | 1000 МБ пс | 2000 МБ ps |
Примечание.
Число групп, число членов группы, перечисленных в таблице, не является жестким ограничением. Эти значения параметров выбираются для установления стабильного сценария тестирования.
Активация облачного события
Служба передает клиентские события вышестоящему веб-перехватчику с помощью протокола HTTP CloudEvents.
Для каждого события он формирует запрос HTTP POST к зарегистрированному вышестоящему приложению и ожидает ответа HTTP.
Примечание.
Web PubSub также поддерживает протокол HTTP 2.0 для доставки события вышестоящему приложению. Приведенный ниже результат проверен с использованием протокола HTTP 1.1. Если ваш сервер приложений поддерживает протокол HTTP 2.0, производительность будет выше.
Echo
В этом случае сервер приложений записывает исходное сообщение обратно в ответ HTTP. Поведение echo определяет, что максимальная входящая полоса пропускания равна максимальной исходящей пропускной способности. Дополнительные сведения см. в следующей таблице.
| Echo | Единица 1 | Единица 2 | Единица 10 | Единица 50 | Единица 100 | Единица 200 | Единица 500 | Единица 1000 |
|---|---|---|---|---|---|---|---|---|
| Связи | 1,000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Входящих/исходящих сообщений в секунду | 500 | 1,000 | 5 000 | 25,000 | 50,000 | 100,000 | 250 000 | 500,000 |
| Входящая/исходящая пропускная способность | 1 Мбит/с | 2 МБ ps | 10 МБ/с | 50 Мбит/с | 100 Мбит/с | 200 Мбит/с | 500 МБ пс | 1000 МБ пс |
REST API
Azure Web PubSub предоставляет функциональные интерфейсы API для управления клиентами и доставки сообщений в режиме реального времени.
Отправка пользователю через REST API
В рамках теста производительности всем клиентам назначаются имена пользователей, до того как они начнут подключаться к службе Azure Web PubSub.
| Отправка пользователю через REST API | Единица 1 | Единица 2 | Единица 10 | Единица 50 | Единица 100 | Единица 200 | Единица 500 | Единица 1000 |
|---|---|---|---|---|---|---|---|---|
| Связи | 1,000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Входящих/исходящих сообщений в секунду | 180 | 360 | 1800 | 9,000 | 18 000 | 36 000 | 90 000 | 180 000 |
| Входящая/исходящая пропускная способность | 360 Кбит/с | 720 Кбит/с | 3,6 Мбит/с | 18 Мбит/с | 36 МБ пс | 72 МБ ps | 180 МБ/с | 360 МБ пс |
Широковещательная передача через REST API
Пропускная способность совпадает с пропускной способностью для отправки в большую группу.
| Широковещательная передача через REST API | Единица 1 | Единица 2 | Единица 10 | Единица 50 | Единица 100 | Единица 200 | Единица 500 | Единица 1000 |
|---|---|---|---|---|---|---|---|---|
| Связи | 1,000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Входящих сообщений в секунду | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 |
| Исходящих сообщений в секунду | 3,000 | 6000 | 30,000 | 150 000 | 300 000 | 600,000 | 1,500,000 | 3 000 000 |
| Входящая пропускная способность | 6 Кбит/с | 6 Кбит/с | 6 Кбит/с | 6 Кбит/с | 6 Кбит/с | 6 Кбит/с | 6 Кбит/с | 6 Кбит/с |
| Исходящая пропускная способность | 6 Мбит/с | 12 Мбит/с | 60 Мбит/с | 300 МБ пс | 600 МБ ps | 1200 МБ ps | 3000 МБ | 6000 МБ |
Следующие шаги
Используйте эти ресурсы для начала создания собственного приложения: