Производительность SignalR (SignalR 1.x)

Статья
07/13/2023

Предупреждение

Эта документация не для последней версии SignalR. Взгляните на ASP.NET Core SignalR.

В этом разделе описывается проектирование, измерение и повышение производительности в приложении SignalR.

Недавнюю презентацию о производительности и масштабировании SignalR см. в статье Масштабирование интернета в режиме реального времени с помощью ASP.NET SignalR.

Этот раздел состоит из следующих подразделов.

Рекомендации по проектированию
Настройка производительности сервера SignalR
Устранение проблем с производительностью
Использование счетчиков производительности SignalR
Использование других счетчиков производительности
Другие ресурсы

Рекомендации по проектированию

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

Частота сообщений регулирования

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

Уменьшение размера сообщения

Вы можете уменьшить размер сообщения SignalR, уменьшив размер сериализованных объектов. Если в коде сервера вы отправляете объект, содержащий свойства, которые не нужно передавать, запретите сериализацию этих свойств с помощью атрибута JsonIgnore . Имена свойств также хранятся в сообщении; имена свойств можно сократить с помощью атрибута JsonProperty . В следующем примере кода показано, как исключить свойство из отправки клиенту и как сократить имена свойств:

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

using Newtonsoft.Json; 
using System; 
public class ShapeModel
{
[JsonProperty("l")]
    public double Left { get; set; }
[JsonProperty("t")]
    public double Top { get; set; }
    // We don't want the client to get the "LastUpdatedBy" property
[JsonIgnore]
    public string LastUpdatedBy { get; set; }
}

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

Код JavaScript на стороне клиента, который переназначает сокращенные имена свойств в имена, доступные для чтения

function reMap(smallObject, contract) {
    var largeObject = {};
    for (var smallProperty in contract) {
        largeObject[contract[smallProperty]] = smallObject[smallProperty];
    }
    return largeObject;
}
var shapeModelContract = {
    l: "left",
    t: "top"
};
myHub.client.setShape = function (shapeModelSmall) {
    var shapeModel = reMap(shapeModelSmall, shapeModelContract);
    // shapeModelSmall has "l" and "t" properties  but after remapping
    // shapeModel now has "left" and "top" properties
};

Имена также можно сократить в сообщениях от клиента к серверу, используя тот же метод.

Уменьшение объема памяти (т. е. объема памяти, используемой для сообщения) объекта сообщения также может повысить производительность. Например, если полный int диапазон не требуется, short вместо него можно использовать или byte .

Так как сообщения хранятся в шине сообщений в памяти сервера, уменьшение размера сообщений также может устранить проблемы с памятью сервера.

Настройка производительности сервера SignalR

Следующие параметры конфигурации можно использовать для настройки сервера для повышения производительности в приложении SignalR. Общие сведения о том, как повысить производительность в приложении ASP.NET, см. в статье Повышение производительности ASP.NET.

Параметры конфигурации SignalR

DefaultMessageBufferSize. По умолчанию SignalR сохраняет в памяти 1000 сообщений на каждый концентратор для каждого подключения. Если используются большие сообщения, это может привести к проблемам с памятью, которые можно устранить, уменьшив это значение. Этот параметр можно задать в обработчике Application_Start событий в приложении ASP.NET или в Configuration методе класса запуска OWIN в локальном приложении. В следующем примере показано, как уменьшить это значение, чтобы уменьшить объем памяти приложения, чтобы уменьшить объем используемой памяти сервера:

Код сервера .NET в Global.asax для уменьшения размера буфера сообщений по умолчанию
```
protected void Application_Start(object sender, EventArgs e)
{
    GlobalHost.Configuration.DefaultMessageBufferSize = 500;
}
```

Параметры конфигурации IIS

Максимальное число одновременных запросов на приложение. Увеличение числа параллельных запросов IIS приведет к увеличению ресурсов сервера, доступных для обслуживания запросов. Значение по умолчанию — 5000; Чтобы увеличить этот параметр, выполните следующие команды в командной строке с повышенными привилегиями:
```
cd %windir%\System32\inetsrv\
appcmd.exe set config /section:system.webserver/serverRuntime 
        /appConcurrentRequestLimit:10000
```

параметры конфигурации ASP.NET

В этом разделе содержатся параметры конфигурации, которые можно задать в aspnet.config файле . Этот файл находится в одном из двух расположений в зависимости от платформы:

%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet.config
%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet.config

ASP.NET параметры, которые могут повысить производительность SignalR, включают следующие:

Максимальное количество одновременных запросов на ЦП. Увеличение этого параметра может устранить узкие места производительности. Чтобы увеличить этот параметр, добавьте в файл следующий параметр конфигурации aspnet.config :
```
<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
    <system.web>
        <applicationPool maxConcurrentRequestsPerCPU="20000" />
    </system.web>
</configuration>
```
Ограничение очереди запросов. Если общее количество подключений превышает заданное maxConcurrentRequestsPerCPU значение, ASP.NET начнет регулировать запросы с помощью очереди. Чтобы увеличить размер очереди, можно увеличить requestQueueLimit параметр . Для этого добавьте следующий параметр конфигурации к processModel узлу в config/machine.config (а не aspnet.config):
```
<processModel autoConfig="false" requestQueueLimit="250000" />
```

Устранение проблем с производительностью

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

Проверка использования WebSocket

Хотя SignalR может использовать различные транспорты для обмена данными между клиентом и сервером, WebSocket обеспечивает значительное преимущество производительности, и его следует использовать, если клиент и сервер поддерживают его. Чтобы определить, соответствуют ли клиент и сервер требованиям для WebSocket, см. статью Транспорты и резервные варианты. Чтобы определить, какой транспорт используется в приложении, можно использовать средства разработчика браузера и просмотреть журналы, чтобы узнать, какой транспорт используется для подключения. Сведения об использовании средств разработки браузера в Internet Обозреватель и Chrome см. в статье Транспорты и резервные варианты.

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

В этом разделе описывается, как включить и использовать счетчики производительности SignalR, которые находятся в пакете Microsoft.AspNet.SignalR.Utils .

Установка signalr.exe

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

В Visual Studio выберите Инструменты> Диспетчер >пакетов NuGetУправление пакетами NuGet для решения.
Найдите signalr.utils и выберите Установить.
Примите лицензионное соглашение для установки пакета.
SignalR.exe будет установлено в <project folder>/packages/Microsoft.AspNet.SignalR.Utils.<version>/tools.

Установка счетчиков производительности с помощью SignalR.exe

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

SignalR.exe ipc

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

SignalR.exe upc

Счетчики производительности SignalR

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

Метрики подключения

Следующие метрики измеряют события времени существования подключения, которые происходят. Дополнительные сведения см. в разделе Общие сведения о событиях времени существования соединения и их обработка.

Подключенные подключения
Подключения повторно подключены
Подключения отключены
Текущие подключения

Метрики использования

Следующие метрики измеряют трафик сообщений, создаваемый SignalR.

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

Метрики шины сообщений

Следующие метрики измеряют трафик через внутреннюю шину сообщений SignalR, очередь, в которой размещаются все входящие и исходящие сообщения SignalR. Сообщение публикуется при отправке или трансляции. Подписчик в этом контексте является подпиской на шине сообщений; оно должно равняться количеству клиентов и самому серверу. Выделенная рабочая роль — это компонент, который отправляет данные в активные подключения; Занятая рабочая роль — это рабочая роль, которая активно отправляет сообщение.

Всего полученных сообщений шины сообщений
Получено сообщений шины сообщений/с
Всего опубликованных сообщений шины сообщений
Опубликованных сообщений шины сообщений/с
Подписчики шины сообщений
Всего подписчиков шины сообщений
Подписчики шины сообщений/с
Выделенные рабочие роли шины сообщений
Занятые рабочие роли шины сообщений
Текущие разделы шины сообщений

Ошибка метрик

Следующие метрики измеряют ошибки, создаваемые трафиком сообщений SignalR. Ошибки разрешения концентратора возникают, когда не удается устранить концентратор или метод концентратора. Ошибки вызова концентратора — это исключения, создаваемые при вызове метода концентратора. Ошибки транспорта — это ошибки подключения, создаваемые во время HTTP-запроса или ответа.

Ошибки: все итого
Ошибки: всего/с
Ошибки: всего разрешения концентратора
Ошибки: разрешение концентратора/с
Ошибки: всего вызовов концентратора
Ошибки: вызов концентратора/с
Ошибки: Общий объем транспорта
Ошибки: транспорт/с

Метрики масштабирования

Следующие метрики измеряют трафик и ошибки, создаваемые поставщиком масштабирования. Stream в этом контексте — это единица масштабирования, используемая поставщиком масштабирования; Это таблица, если используется SQL Server, раздел , если используется служебная шина, и подписка, если используется Redis. По умолчанию используется только один поток, но его можно увеличить с помощью настройки SQL Server и служебной шины. Поток буферизации — это поток, который перешел в состояние сбоя; Если поток находится в состоянии сбоя, все сообщения, отправляемые на объединителенную панель, немедленно завершатся ошибкой, пока поток не перестанет выполнять сбой. Длина очереди отправки — это количество сообщений, которые были опубликованы, но еще не отправлены.

Получено сообщений шины сообщений горизонтального увеличения масштаба/с
Всего масштабируемых потоков
Открытие потоков масштабирования
Буферизация потоков масштабирования
Всего ошибок масштабирования
Ошибки масштабирования/с
Длина очереди отправки scaleout

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

Использование других счетчиков производительности

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

Память

.NET CLR Memory# в байтах во всех кучах (для w3wp)

ASP.NET

ASP.NET\Requests Current
ASP.NET\В очереди
ASP.NET\Отклонено

ЦП

Сведения о процессоре\Время процессора

TCP/IP

TCPv6/Connections (Установленные подключения)
TCPv4/Connections (Установленные подключения)

Веб-служба

Веб-служба\Текущие подключения
Веб-служба\Максимальное число подключений

Работа с потоками

.NET CLR LocksAndThreads# текущих логических потоков
.NET CLR LocksAnd Threads# текущих физических потоков

Другие ресурсы

Дополнительные сведения о мониторинге и настройке ASP.NET производительности см. в следующих разделах: