Производительность SignalR

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

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

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

Версии программного обеспечения, используемые в этом разделе

Visual Studio 2013

.NET 4.5

SignalR версии 2

Предыдущие версии этого раздела

Сведения о более ранних версиях SignalR см. в разделе SignalR более ранних версий.

Вопросы и комментарии

Оставьте отзыв о том, как вам понравилось это руководство и что, по вашему мнению, мы можем улучшить в комментариях в нижней части страницы. Если у вас есть вопросы, которые не связаны напрямую с руководством, их можно опубликовать на форуме ASP.NET SignalR или StackOverflow.com.

Последние презентации о производительности и масштабировании 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 в Startup.cs для уменьшения размера буфера сообщений по умолчанию
```
public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        // Any connection or hub wire up and configuration should go here
        GlobalHost.Configuration.DefaultMessageBufferSize = 500;
        app.MapSignalR();
    }
}
```

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

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

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

параметры конфигурации 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. Каждый поток обеспечивает упорядоченные операции чтения и записи; один поток может стать потенциальным узким местом масштабирования, поэтому количество потоков может быть увеличено, чтобы уменьшить это узкое место. Если используется несколько потоков, SignalR автоматически распределяет (сегмент) сообщения между этими потоками таким образом, чтобы сообщения, отправленные из любого заданного подключения, были упорядочены.

Параметр MaxQueueLength управляет длиной очереди отправки масштабирования, поддерживаемой SignalR. Если установить значение больше 0, все сообщения будут по одному отправляться в очередь отправки к настроенной серверной шине обмена сообщениями. Если размер очереди превышает настроенную длину, последующие вызовы для отправки немедленно завершаются ошибкой InvalidOperationException , пока число сообщений в очереди не меньше параметра. Очередное управление отключено по умолчанию, так как реализованные коммутационные платы обычно имеют собственные механизмы очереди или управления потоком. В случае SQL Server пул соединений эффективно ограничивает количество отправки в любое время.

По умолчанию для SQL Server и Redis используется только один поток, для служебной шины используются пять потоков, а очереди отключены, но эти параметры можно изменить с помощью конфигурации в SQL Server и служебной шине:

Код .NET Server для настройки количества таблиц и длины очереди для серверной части SQL Server

var connectionString = "(your connection string)";
var config = new SqlScaleoutConfiguration(connectionString) { 
TableCount = 3,
MaxQueueLength = 50 };
GlobalHost.DependencyResolver.UseSqlServer(config);

Код сервера .NET для настройки количества тем и длины очереди для коммутационной платы шины служебных сообщений

string connectionString = "(your connection string)";
var config = new ServiceBusScaleoutConfiguration(connectionString, "YourAppName") { 
TopicCount = 3,
MaxQueueLength = 50 };
GlobalHost.DependencyResolver.UseServiceBus(config);

Поток буферный — это тот, который вошел в состояние сбоя; если поток находится в состоянии сбоя, все сообщения, отправленные в backplane, будут сразу же отклонены до тех пор, пока поток не выйдет из состояния сбоя. Длина очереди отправки — это количество сообщений, которые были отправлены, но еще не отправлены.

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

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

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

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

Память

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

ASP.NET

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

процессор

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

TCP/IP

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

Веб-служба

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

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

Блокировки и потоки .NET CLR\Количество текущих логических потоков
.NET CLR Замки и потоки\Количество текущих физических потоков

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

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

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

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

Last updated on 2023-07-13