Руководство по производительности для Службы Azure SignalR
Одним из ключевых преимуществ использования службы Azure SignalR является простота масштабирования приложений SignalR. В крупномасштабном сценарии важным фактором является производительность.
В этой статье рассматриваются следующие вопросы:
- Факторы, влияющие на производительность приложения SignalR.
- Типичная производительность в разных сценариях использования.
- Среда и средства, которые можно использовать для создания отчета о производительности.
Быстрая оценка с помощью метрик
Вы можете легко отслеживать службу в портал Azure. На странице метрик экземпляра SignalR можно выбрать метрики загрузки сервера, чтобы увидеть "давление" службы.
На диаграмме показано вычислительное давление службы SignalR. Вы можете протестировать сценарий и проверка эту метрику, чтобы решить, следует ли масштабировать. Задержка в службе SignalR остается низкой, если загрузка сервера ниже 70%.
Примечание.
Если вы используете единицу 50 или больше, и ваш сценарий в основном отправляется в небольшие группы (размер <группы 20) или одно подключение, необходимо проверка отправлять в небольшую группу или отправлять подключение для получения справки. В этих сценариях существует большая стоимость маршрутизации, которая не включена в нагрузку сервера.
Определения терминов
Входящее: входящее сообщение в службу Azure SignalR.
Исходящее: исходящее сообщение от службы Azure SignalR.
Пропускная способность: общий размер всех сообщений за 1 секунду.
Режим по умолчанию: рабочий режим по умолчанию при создании экземпляра Служба Azure SignalR. Служба Azure SignalR ожидает, что сервер приложений установит подключение к нему, прежде чем он принимает любое клиентское подключение.
Бессерверный режим: режим, в котором служба Azure SignalR принимает только клиентские подключения. Подключение к серверу не разрешено.
Обзор
Служба Azure SignalR определяет семь уровней для различной производительности категории "Стандартный". В этой статье содержатся ответы на следующие вопросы:
Что такое типичная Служба Azure SignalR производительность для каждого уровня (единица)?
Отвечает ли служба Azure SignalR моим требованиям к пропускной способности сообщений (например, отправка 100 000 сообщений в секунду)?
Для конкретного сценария можно выбрать соответствующий уровень?
Какой тип сервера приложений (размер ВМ) мне подходит? Сколько из них необходимо развернуть?
Чтобы ответить на эти вопросы, в этом руководстве сперва дается подробное объяснение факторов, влияющих на производительность. После этого отображается максимальное количество входящих и исходящих сообщений для каждого уровня для типичных случаев использования: echo, широковещательная передача, отправка в группу, и подключение к сети. (одноранговое общение).
В этом руководством не рассматриваются все сценарии (и различные варианты использования, размеры сообщений, шаблоны отправки сообщений и т. д.). Однако в нем представлены несколько методов, которые помогут вам:
- Оценить ваши приблизительные требования к входящим или исходящим сообщениям.
- Найти подходящие уровни, проверив таблицу производительности.
Анализ производительности
В этом разделе описываются методики оценки производительности, после чего перечисляются все факторы, влияющие на производительность. В конце представлены методы, которые помогут вам оценить требования к производительности.
Методология
Пропускная способность и задержка — два типовых аспекта проверки производительности. Для службы 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 имеет лучшую производительность, Server-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.
- Размер сообщения составляет 2048 байт.
- Сообщение отправляется каждые 1 секунду.
- Служба Azure SignalR находится в режиме по умолчанию.
Каждый уровень имеет собственную максимальную пропускную способность для входящего и исходящего трафика. Плавное взаимодействие с пользователем не гарантируется после того, как входящее или исходящее подключение превышает ограничение.
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 |
| Входящая пропускная способность | 2 МБ ps | 4 МБ/с | 20 Мбит/с | 100 Мбит/с | 200 Мбит/с | 400 МБ ps | 1000 МБ пс | 2000 МБ ps |
| Исходящая пропускная способность | 2 Мбит/с | 4 Мбит/с | 20 Мбит/с | 100 Мбит/с | 200 Мбит/с | 400 Мбит/с | 1000 Мбит/с | 2000 Мбит/с |
| Broadcast | Единица 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 |
| Входящая пропускная способность | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с |
| Исходящая пропускная способность | 4 МБ/с | 8 МБ ps | 40 Мбит/с | 200 Мбит/с | 400 МБ ps | 800 МБ/с | 2000 МБ ps | 4000 МБ пс |
Входящая полоса пропускания и исходящая полоса пропускания представляют собой общий размер сообщения в секунду. Ниже приведены формулы для них:
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
inboundConnections: количество подключений, отправляющих сообщение.
outboundConnections: количество подключений, получающих сообщение.
messageSize: размер одного сообщения (среднее значение). Небольшое сообщение размером менее 1024 байтов оказывает влияние на производительность, подобное сообщению размером 1024 байта.
sendInterval: время отправки одного сообщения. Обычно это 1 секунда на сообщение, что означает отправку одного сообщения каждую секунду. Меньший интервал означает отправку большего количества сообщений за период времени. Например, 0,5 секунды в сообщение означает отправку двух сообщений каждую секунду.
Подключения: зафиксированное максимальное пороговое значение для службы Azure SignalR для каждого уровня. Если номер подключения увеличивается еще больше, он страдает от регулирования подключения.
Примечание.
Необходимо увеличить размер номера SKU до Premium_P2 , чтобы размер единицы превышает 100.
Оценка сложных вариантов использования
Больший размер сообщения или другая скорость отправки
Реальный вариант использования более сложен. Он может отправлять сообщение размером более 2 048 байт, или скорость отправки сообщений не является одним сообщением в секунду. Давайте рассмотрим трансляцию Unit 100 в качестве примера, чтобы узнать, как оценить его производительность.
В нижеприведенной таблице показан реальный вариант использования широковещательной передачи. Однако размер сообщения, количество подключений и скорость отправки сообщений отличаются от того, что мы предполагали в рамках предыдущего раздела. Вопрос в том, как мы можем вывести любой из этих элементов (размер сообщения, количество подключений или скорость отправки сообщений), если нам известно только два из них.
| Broadcast | Размер сообщения | Одновременные входящие сообщения | Связи | Интервалы отправки |
|---|---|---|---|---|
| 1 | 20 КБ | 1 | 100,000 | 5 с |
| 2 | 256 КБ | 1 | 8000 | 5 с |
Следующую формулу легко вывести на основе предыдущей:
outboundConnections = outboundBandwidth * sendInterval / messageSize
Для единицы 100 максимальная пропускная способность исходящего трафика составляет 400 МБ из предыдущей таблицы. Для 20-КБ размера сообщения максимальный исходящий трафик должен составлять 400 МБ * 5 / 20 КБ = 100 000, что соответствует реальному значению.
Смешанные варианты использования
В реальном варианте использования обычно смешиваются четыре основных варианта использования: echo, широковещательная передача, отправка в группу, и подключение к сети. Методология, которую вы используете для оценки потенциала, заключается в следующем:
- Разделите смешанные варианты использования на четыре основных варианта использования.
- Рассчитайте максимальную пропускную способность для входящих и исходящих сообщений, используя приведенные выше формулы отдельно.
- Просуммируйте расчеты пропускной способности, чтобы получить общую максимальную входящую/исходящую пропускную способность.
После этого выберите нужный уровень из таблиц максимальной входящей/исходящей пропускной способности.
Примечание.
Для отправки сообщения сотням или тысячам небольших групп или для тысяч клиентов, отправляющих сообщение друг другу, стоимость маршрутизации станет доминирующей. Необходимо учитывать это влияние.
В случае отправки сообщения клиентам убедитесь, что сервер приложений не является узким местом. В следующем разделе "Практический пример" приведены рекомендации о том, сколько серверов приложений вам нужно и сколько серверных подключений вы должны настроить.
Пример
В следующих разделах рассматриваются четыре типичных варианта использования транспорта WebSocket: echo, широковещательная передача, отправка в группу, и подключение к сети. Для каждого сценария в разделе перечислены текущие входящие и исходящие ресурсы для службы Azure SignalR. Также объясняются основные факторы, оказывающие влияние на производительность.
В режиме по умолчанию сервер приложений создает пять подключений к серверу со службой Azure SignalR. Сервер приложений по умолчанию использует пакет SDK службы Azure SignalR. В следующих результатах теста производительности количество подключений к серверу увеличено до 15 (или более для широковещательной передачи и отправки сообщения большой группе).
Разные варианты использования предъявляют разные требования к серверам приложений. Широковещательной передаче требуется небольшое количество серверов приложений. Для Echo или отправки на соединение требуется много серверов приложений.
Во всех случаях использования размер сообщения по умолчанию составляет 2048 байтов, а интервал отправки сообщения составляет 1 секунду.
Режим по умолчанию
Клиенты, серверы веб-приложений и служба Azure SignalR задействованы в режиме по умолчанию. Каждый клиент означает одно соединение.
Echo
Сначала веб-приложение подключается к службе Azure SignalR. Во-вторых, многие клиенты подключаются к веб-приложению, которое перенаправляет клиентов в службу Azure SignalR с токеном доступа и конечной точкой. После этого клиенты устанавливают соединения WebSocket со службой Azure SignalR.
После того, как все клиенты устанавливают соединение, они начинают каждую секунду отправлять сообщение, содержащее отметку времени, конкретному концентратору. Концентратор возвращает сообщение своему исходному клиенту. При получении сообщения echo каждый клиент вычисляет задержку.
На следующей диаграмме от 5 до 8 (выделенный красным трафик) замкнуты петли. Цикл выполняется в течение продолжительности по умолчанию (5 минут) и получает статистику всех задержек сообщений.
Поведение 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 |
| Входящих/исходящих сообщений в секунду | 1,000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Входящая/исходящая пропускная способность | 2 Мбит/с | 4 Мбит/с | 20 Мбит/с | 100 Мбит/с | 200 Мбит/с | 400 Мбит/с | 1000 Мбит/с | 2000 Мбит/с |
В этом случае каждый клиент вызывает концентратор, определенный на сервере приложений. Концентратор просто вызывает метод, определенный на исходной стороне клиента. Этот концентратор является самым легким для echo.
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
Даже для этого простого концентратора нагрузка трафика на сервер приложений заметна по мере увеличения нагрузки входящих сообщений echo. Эта нагрузка на трафик требует наличия множества серверов приложений для больших уровней SKU. В нижеприведенной таблице указано количество серверов приложений для каждого уровня.
| 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 |
| Количество серверов приложений | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Примечание.
Номер клиентского подключения, размер сообщения, скорость отправки сообщений, уровень SKU и ЦП/память сервера приложений влияют на общую производительность echo.
Broadcast
В случае широковещательной передачи, когда веб-приложение получает сообщение, оно рассылает широковещательную передачу всем клиентам. Чем больше клиентов есть для трансляции, тем больше трафика сообщений на всех клиентах. Рассмотрим схему ниже.
К широковещательной передаче подключено небольшое количество клиентов. Пропускная способность входящего сообщения мала, но исходящая полоса пропускания огромна. Пропускная способность исходящего сообщения увеличивается по мере увеличения скорости клиентского соединения или широковещательной передачи.
В нижеприведенной таблице приведены максимальное количество клиентских подключений, количество входящих / исходящих сообщений и пропускная способность.
| Broadcast | Единица 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 |
| Входящих сообщений в секунду | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Исходящих сообщений в секунду | 2 000 | 4000 | 20,000 | 100,000 | 200 000 | 400 000 | 1 000 000 | 2 000 000 |
| Входящая пропускная способность | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с |
| Исходящая пропускная способность | 4 Мбит/с | 8 Мбит/с | 40 Мбит/с | 200 Мбит/с | 400 Мбит/с | 800 Мбит/с | 2000 Мбит/с | 4000 МБ пс |
Клиентов в рамках широковещательной передачи, отправляющих сообщения, не более четырех. Им требуется меньшее количество серверов приложений по сравнению с echo, поскольку объем входящих сообщений невелик. Двух серверов приложений достаточно как для соглашения об уровне обслуживания, так и для обеспечения производительности. Но следует увеличить подключения сервера по умолчанию, чтобы избежать дисбаланса, особенно для единиц, превышающих 50.
| Broadcast | Единица 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 |
| Количество серверов приложений | 1 | 1 | 1 | 2 | 2 | 4 | 10 | 20 |
Примечание.
Увеличьте количество подключений к серверу по умолчанию с 5 до 40 на каждом сервере приложений, чтобы избежать возможных несбалансированных подключений сервера к службе Azure SignalR.
Номер клиентского подключения, размер сообщения, скорость отправки сообщений и уровень SKU влияют на общую производительность широковещательной передачи.
Отправка в группу
Вариант использования отправка группе имеет аналогичный шаблон трафика для широковещательной передачи. Разница в том, что после того, как клиенты устанавливают подключения WebSocket со службой Azure SignalR, они должны присоединиться к группам, прежде чем они смогут отправить сообщение определенной группе. На следующей схеме показан поток трафика.
Количество членов группы и количество групп — это два фактора, оказывающие влияние на производительность. Чтобы упростить анализ, мы определяем два типа групп:
Малая группа: каждая группа имеет 10 подключений. Номер группы равен (максимальное количество подключений)/10. Например, для единицы 1, если имеется 1000 подключений, то у нас есть 1000 / 10 = 100 групп.
Большая группа: номер группы всегда равен 10. Количество членов группы равно (максимальное количество подключений)/10. Например, для единицы 1, если имеется 1000 подключений, каждая группа имеет 1000 / 10 = 100 членов.
Отправка в группу требует затрат на маршрутизацию для службы Azure SignalR, поскольку от нее требуется нахождение целевых подключений через распределенную структуру данных. По мере увеличения числа отправляющих соединений стоимость увеличивается.
Небольшая группа
Стоимость маршрутизации значительна для отправки сообщения множеству небольших групп. В настоящее время реализация Служба Azure SignalR достигает предельной стоимости маршрутизации в единице 50. Добавление дополнительных ресурсов ЦП и памяти не помогает, поэтому модуль 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 | 1000 | 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 Мбит/с | 40 Мбит/с | 200 Мбит/с | 200 Мбит/с | 400 Мбит/с | 1000 Мбит/с | 2000 Мбит/с |
Многие клиентские подключения вызывают концентратор, поэтому номер сервера приложений также важен для производительности. В нижеприведенной таблице перечислены рекомендуемые количества серверов приложений.
| Отправка в небольшую группу | Единица 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 |
| Количество серверов приложений | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Примечание.
Номер клиентского подключения, размер сообщения, скорость отправки сообщений, стоимость маршрутизации, уровень SKU и ЦП/память сервера приложений влияют на общую производительность отправки в небольшую группу .
Число групп, число членов группы, перечисленных в таблице, не является жестким ограничением. Эти значения параметров выбираются для установления стабильного сценария тестирования. Например, можно назначить каждому коннечитону отдельной группе. В этой конфигурации производительность близка к отправке подключения.
Большая группа
Для отправки в большую группу исходящая полоса пропускания становится узким местом до достижения предела стоимости маршрутизации. В нижеприведенной таблице указана максимальная пропускная способность исходящего трафика, которая почти такая же, как и для широковещательной передачи.
| Отправка в большую группу | Единица 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 | 500 | 1,000 | 2 000 | 5 000 | 10 000 | 20,000 |
| Количество групп | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Входящих сообщений в секунду | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| Входящая пропускная способность | 40 Кбит/с | 40 Кбит/с | 40 Кбит/с | 40 Кбит/с | 40 Кбит/с | 40 Кбит/с | 40 Кбит/с | 40 Кбит/с |
| Исходящих сообщений в секунду | 2 000 | 4000 | 20,000 | 100,000 | 200 000 | 400 000 | 1 000 000 | 2 000 000 |
| Исходящая пропускная способность | 4 Мбит/с | 8 Мбит/с | 40 Мбит/с | 200 Мбит/с | 400 Мбит/с | 800 Мбит/с | 2000 Мбит/с | 4000 МБ пс |
Количество отправляющих подключений не превышает 40. Нагрузка на сервер приложений невелика, поэтому предлагаемое количество веб-приложений невелико.
| Отправка в большую группу | Единица 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 |
| Количество серверов приложений | 1 | 1 | 2 | 2 | 2 | 4 | 10 | 20 |
Примечание.
Увеличьте количество подключений к серверу по умолчанию с 5 до 40 на каждом сервере приложений, чтобы избежать возможных несбалансированных подключений сервера к службе Azure SignalR.
Номер клиентского подключения, размер сообщения, скорость отправки сообщений, стоимость маршрутизации и уровень SKU оказывают влияние на общую производительность отправки в большую группу.
Отправка на подключение
В варианте использования отправка на подключение, когда клиенты устанавливают подключения к службе Azure SignalR, каждый клиент вызывает специальный концентратор, чтобы получить свой собственный идентификатор подключения. В ходе теста производительности происходит сбор всех идентификаторов подключений, их перемешивание и переназначение всем клиентам в качестве цели отправки. Клиенты продолжают отправлять сообщение целевому соединению до завершения теста производительности.
Стоимость маршрутизации для отправки на подключение аналогична стоимости для отправки в малую группу.
По мере увеличения числа подключений затраты на маршрутизацию становятся критически важным фактором, ограничивающим общую производительность. В частности, единица 20 помечает пороговое значение, в котором служба попадает в узкое место маршрутизации. Дальнейшее увеличение числа единиц не приводит к улучшению производительности, если нет смены на Premium_P2(единица >=100), что повышает возможности маршрутизации.
Следующая таблица представляет собой статистическую сводку после многих раундов выполнения теста отправки на подключение.
| Отправка на подключение | Единица 1 | Единица 2 | Единица 20 | Единица 50 | Единица 100 | Единица 200 | Единица 500 | Единица 1000 |
|---|---|---|---|---|---|---|---|---|
| Связи | 1,000 | 2 000 | 20,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Входящих/исходящих сообщений в секунду | 1,000 | 2 000 | 20,000 | 20,000 | 20,000 | 40 000 | 100,000 | 200 000 |
| Входящая/исходящая пропускная способность | 2 Мбит/с | 4 Мбит/с | 40 Мбит/с | 40 Мбит/с | 40 Мбит/с | 80 Мбит/с | 200 Мбит/с | 400 Мбит/с |
Примечание.
Несмотря на стагнацию входящих и исходящих сообщений в секунду после единицы 20, емкость для большего объема подключений продолжает расти. В реальных бизнес-сценариях это часто количество подключений, а не их параллельное действие отправки сообщений, которое формирует узкие места. Это редкость для всех подключений, которые будут активно отправлять сообщения на такой высокой частоте, как тест теста.
Этот вариант использования требует высокой нагрузки на стороне сервера приложений. См. предлагаемое количество серверов приложений в нижеприведенной таблице.
| Отправка на подключение | Единица 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 |
| Количество серверов приложений | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Примечание.
Номер клиентского соединения, размер сообщения, скорость отправки сообщений, стоимость маршрутизации, уровень SKU и ЦП/память для сервера приложений влияют на общую производительность отправки на подключение.
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 | Единица 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 |
| Входящих сообщений в секунду | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Исходящих сообщений в секунду | 2 000 | 4000 | 20,000 | 100,000 | 200 000 | 400 000 | 1 000 000 | 2 000 000 |
| Входящая пропускная способность | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с | 4 Кбит/с |
| Исходящая пропускная способность | 4 МБ/с | 8 МБ ps | 40 Мбит/с | 200 Мбит/с | 400 МБ ps | 800 МБ/с | 2000 МБ ps | 4000 МБ пс |
Отправка пользователю через REST API
В рамках теста всем клиентам назначаются имена пользователей до того, как они начнут подключаться к службе Azure SignalR. После того, как клиенты устанавливают соединения WebSocket со службой Azure SignalR, они начинают отправлять сообщения другим пользователям через HTTP Post.
| Отправка пользователю через 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 |
| Входящие и исходящие сообщения в секунду | 200 | 400 | 2 000 | 10,000 | 20,000 | 40 000 | 100,000 | 200 000 |
| Пропускная способность для входящих и исходящих подключений | 400 Кбит/с | 800 Кбит/с | 4 Мбит/с | 20 Мбит/с | 40 Мбит/с | 80 Мбит/с | 200 Мбит/с | 400 Мбит/с |
Среды тестирования производительности
Для всех вариантов использования, перечисленных выше, мы провели тесты производительности в среде Azure. В большинстве случаев мы использовали 200 клиентских виртуальных машин и 100 виртуальных машин сервера приложений. Ниже приведены некоторые сведения:
Размер клиентской виртуальной машины: StandardDS2V2 (2 виртуальных ЦП, 7 ГБ памяти)
Размер виртуальной машины сервера приложений: StandardF4sV2 (4 виртуальных ЦП, 8 ГБ памяти)
Подключений к серверу пакета SDK для Azure SignalR: 15
Средства производительности
Средства оценки производительности для службы Azure SignalR можно найти на GitHub.
Следующие шаги
В этой статье вам были предоставлены краткие сведения о производительности службы Azure SignalR в контексте типичных сценариев использования.
Для получения подробной информации о внутреннем устройстве службы и ее масштабировании, прочтите следующие руководства:
- Azure SignalR Service internals (Внутренние компоненты Службы Azure SignalR)
- Масштабирование службы Azure SignalR