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

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

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

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

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

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

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

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

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

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

Даже в приложении, которое отправляет сообщения с высокой частотой (например, игровое приложение в режиме реального времени), большинство приложений не должны отправлять больше нескольких сообщений в секунду. Чтобы уменьшить объем трафика, создаваемый каждым клиентом, можно реализовать цикл сообщений, который ставит в очередь и отправляет сообщения с не более чем определенным фиксированным интервалом времени (т. е. до определенного количества сообщений будет отправляться каждую секунду, если в этом интервале будут сообщения для отправки). В качестве примера приложения, которое регулирует сообщения с определенной скоростью (как от клиента, так и от сервера), см. High-Frequency Realtime с использованием 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 Explorer и Chrome см. в разделе "Транспорты и резервные копии".

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

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

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

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

В Visual Studio выберите Tools>NuGet Package Manager>Manage NuGet Packages for Solution
Найдите 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

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

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

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

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

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

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

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

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

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

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

Метрики ошибок

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

Ошибки: все итого
Ошибки: all/sec
Ошибки: общее разрешение концентратора
Ошибки: скорость хаба/с
Ошибки: общее количество вызовов концентратора
Ошибки: вызов концентратора/с
Ошибки: общий объем транспорта
Ошибки: транспорт/с

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

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

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

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

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

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

Память

Количество байтов в памяти CLR .NET во всех кучах (для w3wp)

ASP.NET

ASP.NET\Текущие запросы
ASP.NET\Queued
ASP.NET\Отклонено

процессор

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

TCP/IP

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

Веб-служба

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

многопоточность

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

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

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

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-03-27