SignalR 性能 (SignalR 1.x)

项目
07/13/2023

作者：Patrick Fletcher

警告

本文档不适用于最新版本的 SignalR。查看 ASP.NET Core SignalR。

本主题介绍如何在 SignalR 应用程序中设计、测量和提高性能。

有关 SignalR 性能和缩放的最新演示文稿，请参阅使用 ASP.NET SignalR 缩放实时 Web。

本主题包含以下各节：

设计注意事项
优化 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 启动类的方法中设置。下面的示例演示如何减少此值，以减少应用程序的内存占用量，以减少使用的服务器内存量：

Global.asax 中的 .NET 服务器代码，用于减小默认消息缓冲区大小
```
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

可提高 SignalR 性能 ASP.NET 设置包括：

每个 CPU 的最大并发请求数：增加此设置可以缓解性能瓶颈。若要增加此设置，请将以下配置设置添加到 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 性能计数器

本部分介绍如何启用和使用包中找到的 Microsoft.AspNet.SignalR.Utils SignalR 性能计数器。

安装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 请求或响应期间引发的连接错误。

错误：全部总计
错误：全部/秒
错误：中心解析总数
错误：中心解析/秒
错误：中心调用总数
错误：中心调用数/秒
错误：传输总数
错误：Transport/Sec

横向扩展指标

以下指标度量扩展提供程序生成的流量和错误。此上下文中的流是扩展提供程序使用的缩放单元;如果使用SQL Server，则为表;如果使用服务总线，则为主题;如果使用 Redis，则为订阅。默认情况下，仅使用一个流，但可以通过SQL Server和服务总线上的配置来增加此流。缓冲流是已进入错误状态的流;当流处于故障状态时，发送到底板的所有消息将立即失败，直到流不再出错。 发送队列长度是已发布但尚未发送的消息数。

收到的横向扩展消息总线消息数/秒
横向扩展流总数
横向扩展流打开
横向扩展流缓冲
横向扩展错误总数
横向扩展错误数/秒
横向扩展发送队列长度

有关这些计数器正在测量的内容的详细信息，请参阅 SignalR Scaleout with Azure 服务总线。

使用其他性能计数器

以下性能计数器还可用于监视应用程序的性能。

内存

w3wp) 的所有堆 (中的 .NET CLR 内存# 字节数

ASP.NET

ASP.NET\Requests Current
ASP.NET\Queued
ASP.NET\Rejected

CPU

处理器信息\处理器时间

TCP/IP

已建立 TCPv6/连接
TCPv4/已建立连接

Web 服务

Web 服务\当前连接
Web 服务\最大连接数

线程处理

当前逻辑线程的 .NET CLR LocksAndThreads#
当前物理线程的 .NET CLR LocksAnd Threads#

其他资源

有关 ASP.NET 性能监视和优化的详细信息，请参阅以下主题：

SignalR 性能 (SignalR 1.x)

设计注意事项

限制消息频率

减小消息大小

优化 SignalR 服务器的性能

性能问题故障排除

验证是否正在使用 WebSocket

使用 SignalR 性能计数器

安装signalr.exe

使用 SignalR.exe 安装性能计数器

SignalR 性能计数器

使用其他性能计数器

其他资源

反馈

反馈

其他资源