Merge pull request #259153 from bjqian/main

Clarify the group count in performance doc of Azure SignalR and Azure Web PubSub

Author: prmerger-automator[bot]

articles/azure-signalr/signalr-concept-performance.md

@@ -26,7 +26,7 @@ You can easily monitor your service in the Azure portal. From the **Metrics** pa
 The chart shows the computing pressure of your SignalR service. You can test your scenario and check this metric to decide whether to scale up. The latency inside SignalR service remains low if the Server Load is below 70%. 
 
 > [!NOTE]
-> If you are using unit 50 or unit 100 **and** your scenario is mainly sending to small groups (group size <100) or single connection, you need to check [sending to small group](#small-group) or [sending to connection](#send-to-connection) for reference. In those scenarios there is large routing cost which is not included in the Server Load.
+> If you are using unit 50 or unit 100 **and** your scenario is mainly sending to small groups (group size <20) or single connection, you need to check [sending to small group](#small-group) or [sending to connection](#send-to-connection) for reference. In those scenarios there is large routing cost which is not included in the Server Load.
 
 ## Term definitions
 
@@ -323,6 +323,8 @@ Many client connections are calling the hub, so the app server number is also cr
 
 > [!NOTE]
 > The client connection number, message size, message sending rate, routing cost, SKU tier, and CPU/memory of the app server affect the overall performance of **send to small group**.
+>
+> The group count, group member count listed in the table are **not hard limits**. These parameter values are selected to establish a stable benchmark scenario. For example, it is OK to assign each conneciton to a distinct group. Under this configuration, the performance is close to [send to connection](#send-to-connection).
 
 ##### Big group
 

articles/azure-web-pubsub/concept-performance.md

@@ -23,7 +23,7 @@ In this guide, we'll introduce the factors that affect Web PubSub upstream appli
    It shows the computing pressure of your Azure Web PubSub service. You could test on your own scenario and check this metrics to decide whether to scale up. The latency inside Azure Web PubSub service would remain low if the Server Load is below 70%. 
 
 > [!NOTE]
-> If you are using unit 50 or unit 100 **and** your scenario is mainly sending to small groups (group size <100), you need to check [sending to small group](#small-group) for reference. In those scenarios there is large routing cost which is not included in the Server Load.
+> If you are using unit 50 or unit 100 **and** your scenario is mainly sending to small groups (group size <20), you need to check [sending to small group](#small-group) for reference. In those scenarios there is large routing cost which is not included in the Server Load.
    
    Below are detailed concepts for evaluating performance.
 ## Term definitions
@@ -145,6 +145,9 @@ The routing cost is significant for sending message to many small groups. Curren
 | Outbound messages per second | 4,000 | 8,000 | 20,000 | 40,000 | 80,000 | 150,000 | 150,000 |
 | Outbound bandwidth | **8 MBps** | **16 MBps** | **40 MBps** | **80 MBps** | **160 MBps** | **300 MBps** | **300 MBps** |
 
+> [!NOTE]
+> The group count, group member count listed in the table are **not hard limits**. These parameter values are selected to establish a stable benchmark scenario. 
+
 ### Triggering Cloud Event 
 Service delivers client events to the upstream webhook using the [CloudEvents HTTP protocol](./reference-cloud-events.md).