使用 Azure Web PubSub 服务的主要优势之一是易于扩展。 在大规模方案中，性能是重要的因素。
本指南将介绍影响 Web PubSub 服务性能的因素。 其中将在不同的用例场景中描述典型性能。
在讨论影响性能的因素之前，让我们先介绍一种监视服务压力的简单方法。 门户中有一个名为“服务器负载”的指标。
它显示了 Azure Web PubSub 服务的计算压力。 你可以针对你自己的场景进行测试，并检查此指标来决定是否要纵向扩展。 如果服务器负载低于 70%，Azure Web PubSub 服务内的延迟将保持较低水平。
备注
如果你使用单元 50 或更大值，并且在你的场景中主要向小型组（组大小 <20）发送数据，则需要查看发送到小型组进行参考。 在这些场景中，存在很高的路由成本，而这并不包括在服务器负载中。
下面是用于评估性能的详细概念。
入站：传入到 Azure Web PubSub 服务的消息。
出站：从 Azure Web PubSub 服务传出的消息。
带宽： 1 秒内所有消息的总大小。
本文将解答以下问题：
每个单元大小的典型 Azure Web PubSub 服务性能是什么？
Azure Web PubSub 服务是否满足我的消息吞吐量要求（例如，每秒发送 100000 条消息）？
对于特定方案，如何选择适当的单元大小？
为了解答这些问题，本指南首先提供影响性能的因素的概要说明。 然后，本指南说明了典型用例的最大入站和出站消息数，这三个典型用例分别为：通过 Web PubSub 子协议、上游和 REST API 发送到组。
本指南无法涵盖所有方案（及不同的用例、消息大小、消息发送模式等）。 但它提供的一些基本信息将有助于了解性能限制。
本部分介绍性能评估方法，然后列出影响性能的所有因素。 最后，提供一些方法来帮助你评估性能要求。
吞吐量和延迟是两个典型的性能检查项目。 最大吞吐量（入站和出站带宽）定义为当 99% 的消息的延迟小于 1 秒时实现的最大吞吐量。 这并非硬性限制。
理论上，Azure Web PubSub 服务容量受到以下计算资源的限制：CPU、内存和网络。 例如，与 Azure Web PubSub 服务建立更多连接会导致服务使用更多的内存。 对于较大的消息流量（例如，每条消息大于 2048 字节），Azure Web PubSub 服务需要花费更多的 CPU 周期来处理流量。
消息路由开销也会限制性能。 Azure Web PubSub 服务扮演着消息中转站的角色，在一组客户端之间路由消息。 不同的方案或 API 需要不同的路由策略。
对于“回显”，客户端向上游发送消息，然后上游将消息回显给客户端。 此模式的路由开销最低。 但对于“广播”、“发送到组”和“发送到连接”，Azure Web PubSub 服务需要通过内部分布式数据结构查找目标连接。 这些额外的处理会占用更多的 CPU、内存和网络带宽。 因此，性能将会降低。
概括而言，以下因素会影响入站和出站容量：
单元大小（CPU/内存）
连接数
消息大小
消息发送速率
用例场景（路由开销）
如何评估入站/出站容量或确定哪个单元大小适合特定的用例？
每个单元大小都具有自身的最大入站带宽和出站带宽。 入站或出站流量超过阈值后，则不能保证顺畅的用户体验。
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
- inboundConnections：发送消息的连接数。
- outboundConnections：接收消息的连接数。
- messageSize：单个消息的大小（平均值）。 小于 1,024 字节的小型消息的性能影响与 1,024 字节消息类似。
- sendInterval：发送消息的间隔。 例如，1 秒意味着每一秒发送一条消息。 间隔越短，在一个时间段内发送的消息就越多。 例如，0.5 秒意味着每一秒发送两条消息。
- 连接：每个单元大小的 Azure Web PubSub 服务提交的最大阈值。 超过阈值的连接会受到限制。
假设上游足够强大，不会成为性能瓶颈。 那么，请检查每个单元大小的最大入站和出站带宽。
以下各部分将介绍三个典型的用例：通过 Web PubSub 子协议发送到组，触发 CloudEvent，以及调用 REST API。 对于每个方案，相关部分列出了 Azure Web PubSub 服务的当前入站容量和出站容量。 此外，它还解释了影响性能的主要因素。
在所有用例中，默认消息大小为 2,048 字节，消息发送间隔为 1 秒。
该服务支持名为 json.webpubsub.azure.v1 的特定子协议，该子协议能使客户端直接进行发布/订阅，而不用往返于上游服务器。 此方案非常高效，因为无需任何服务器，而且所有流量都通过客户端服务 WebSocket 连接进行传输。
组成员和组计数是影响性能的两个因素。 为了简化分析，我们定义了两种类型的组：
- 大型组：组数始终为 10。 组成员计数 = 最大连接计数 / 10。 例如，对于单元 1，如果连接计数为 1,000，则每个组的成员数为 1000 / 10 = 100。
- 小型组：每个组有 10 个连接。 组数 = 最大连接数 / 10。 例如，对于单元 1，如果连接计数为 1,000，则组数为 1000 / 10 = 100。
“发送到组”会为 Azure Web PubSub 服务带来路由开销，因为它必须通过分布式数据结构查找目标连接。 随着发送连接数的增加，开销也会增大。
对于“发送到大型组”，出站带宽在达到路由开销限制之前会成为瓶颈。 下表列出了最大出站带宽。
| 发送到大型组 | 单元 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 | 1,000 | 5,000 | 10,000 | 5,000 | 10,000 | 20,000 |
| 组计数 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| 每秒入站消息数 | 30 | 30 | 30 | 30 | 30 | 30 | 30 | 30 |
| 入站带宽 | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps |
| 每秒出站消息数 | 3,000 | 6,000 | 30,000 | 150,000 | 300,000 | 600,000 | 1,500,000 | 3,000,000 |
| 出站带宽 | 6 MBps | 12 MBps | 60 MBps | 300 MBps | 600 MBps | 1,200 MBps | 3,000 MBps | 6,000 MBps |
将消息发送到大量的小型组时，路由开销很大。 目前，单元 50 上的 Azure Web PubSub 服务实施方案已经达到路由开销限制。 添加更多的 CPU 和内存不起作用，因此单元 100 无法通过设计进一步改善。 如果需要更多的入站带宽，则需要纵向扩展以使用 Premium_P2（单元 >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 | 1,000 | 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 KBps | 800 KBps | 4 MBps | 20 MBps | 20 MBps | 40 MBps | 100 MBps | 200 MBps |
| 每秒出站消息数 | 2,000 | 4,000 | 20,000 | 100,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 出站带宽 | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 200 MBps | 400 MBps | 1,000 MBps | 2000 MBps |
备注
表中列出的组计数、组成员计数不是硬限制。 选择这些参数值是为了建立稳定的基准方案。
服务使用 CloudEvents HTTP 协议将客户端事件传送到上游 Webhook。
它将为每个事件构建一个 HTTP POST 请求并发送到注册的上游，并需要 HTTP 响应。
备注
Web PubSub 还支持 HTTP 2.0 进行上游事件传送。 以下结果使用 HTTP 1.1 进行测试。 如果应用服务器支持 HTTP 2.0，性能将更好。
在这种情况下，应用服务器会将原始消息回写到 http 响应中。 “回显”的行为决定了最大入站带宽等于最大出站带宽。 有关详细信息，请参阅下表。
| 回显 | 单元 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 |
| 每秒入站/出站消息数 | 500 | 1,000 | 5,000 | 25,000 | 50,000 | 100,000 | 250,000 | 500,000 |
| 入站/出站带宽 | 1 MBps | 2 MBps | 10 MBps | 50 MBps | 100 MBps | 200 MBps | 500 MBps | 1,000 MBps |
Azure Web PubSub 提供强大的 API 用于管理客户端和传送实时消息。
在客户端开始连接到 Azure Web PubSub 服务之前，基准会将用户名分配给所有客户端。
| 通过 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 |
| 每秒入站/出站消息数 | 180 | 360 | 1,800 | 9,000 | 18,000 | 36,000 | 90,000 | 180,000 |
| 入站/出站带宽 | 360 KBps | 720 KBps | 3\.6 MBps | 18 MBps | 36 MBps | 72 MBps | 180 MBps | 360 MBps |
带宽与“发送到大型组”的带宽相同。
| 通过 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 |
| 每秒入站消息数 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 |
| 每秒出站消息数 | 3,000 | 6,000 | 30,000 | 150,000 | 300,000 | 600,000 | 1,500,000 | 3,000,000 |
| 入站带宽 | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps |
| 出站带宽 | 6 MBps | 12 MBps | 60 MBps | 300 MBps | 600 MBps | 1,200 MBps | 3,000 MB | 6,000MB |
使用这些资源开始生成自己的应用程序：