more edits

cebundy · cebundy · commit 8155e52ef064 · 2023-03-30T16:53:55.000-07:00
diff --git a/articles/azure-signalr/signalr-concept-messages-and-connections.md b/articles/azure-signalr/signalr-concept-messages-and-connections.md
@@ -38,47 +38,43 @@ Large messages do negatively affect messaging performance. Use smaller messages
 
 ## How messages are counted for billing
 
-Only outbound messages from Azure SignalR Service are counted for billing. Ping messages between clients and servers are ignored.
+Messages sent into the service are inbound messages and messages sent out of the service are outbound messages.  Only outbound messages from Azure SignalR Service are counted for billing. Ping messages between clients and servers are ignored.
 
 Messages larger than 2 KB are counted as multiple messages of 2 KB each. The message count chart in the Azure portal is updated every 100 messages per hub.
 
 For example, imagine you have one application server, and three clients:
 
-- When the application server broadcasts a 1-KB message to all connected clients, the message from the application server to the service is considered free inbound message. Only the three messages sent from service to each of the clients are billed as outbound messages.
+* When the application server broadcasts a 1-KB message to all connected clients, the message from the application server to the service is considered a free inbound msages.
 
-- When *client A* sends a 1 KB an inbound message to *client B*, without going through app server, the message is a free. The message routed from service to *client B* is billed as an outbound message.
+* When *client A* sends a 1 KB inbound message to *client B*, without going through app server, the message is a free inbound message. The message routed from service to *client B* is billed as an outbound message.
 
-- If you have three clients and one application server, when one client sends a 4-KB message for the server broadcast to all clients, the billed message count is eight: 
+* If you have three clients and one application server, when one client sends a 4-KB message for the server broadcast to all clients, the billed message count is eight: 
 
-    - One message from the service to the application server.
-    - Three messages from the service to the clients. Each message is counted as two 2-KB messages.
+  * One message from the service to the application server.
+  * Three messages from the service to the clients. Each message is counted as two 2-KB messages.
 
 ## How connections are counted
 
 The Azure SignalR Service creates application server and client connections. By default, each application server starts with five initial connections per hub, and each client has one client connection.
 
 For example, assume that you have two application servers and you define five hubs in code. The server connection count is 50: (2 app servers * 5 hubs * 5 connections per hub).
 
-The connection count shown in the Azure portal includes server connections, client connections, diagnostic connections, and live trace connections. The connection types are defined in the following list:
+The connection count shown in the Azure portal includes server, client, diagnostic, and live trace connections. The connection types are defined in the following list:
+
+* **Server connection**: Connects Azure SignalR Service and the app server.
+* **Client connection**: Connects Azure SignalR Service and the client app.
+* **Diagnostic connection**: A special type of client connection that can produce a more detailed log, which might affect performance. This kind of client is designed for troubleshooting.
+* **Live trace connection**: Connects to the live trace endpoint and receives live traces of Azure SignalR Service.
 
-- **Server connection**: Connects Azure SignalR Service and the app server.
-- **Client connection**: Connects Azure SignalR Service and the client app.
-- **Diagnostic connection**: A special type of client connection that can produce a more detailed log, which might affect performance. This kind of client is designed for troubleshooting.
-- **Live trace connection**: Connects to the live trace endpoint and receives live traces of Azure SignalR Service. 
- 
 A live trace connection isn't counted as a client connection or as a server connection. 
 
 ASP.NET SignalR calculates server connections in a different way. It includes one default hub in addition to hubs that you define. By default, each application server needs five more initial server connections. The initial connection count for the default hub stays consistent with other hubs.
 
-The service and the application server keep syncing connection status and making adjustment to server connections to get better performance and service stability.  So you might see server connection number changes from time to time.
-
-## How inbound/outbound traffic is counted
-
-Messages sent into the service are inbound messages. Messages sent out of the service are outbound messages. Traffic is calculated in bytes.
+The service and the application server keep syncing connection status and making adjustments to server connections to get better performance and service stability.  So you may see changes in the number of server connections in your running service.
 
 ## Related resources
 
-- [Aggregation types in Azure Monitor](../azure-monitor/essentials/metrics-supported.md#microsoftsignalrservicesignalr )
-- [ASP.NET Core SignalR configuration](/aspnet/core/signalr/configuration)
-- [JSON](https://www.json.org/)
-- [MessagePack](/aspnet/core/signalr/messagepackhubprotocol)
+* [Aggregation types in Azure Monitor](../azure-monitor/essentials/metrics-supported.md#microsoftsignalrservicesignalr )
+* [ASP.NET Core SignalR configuration](/aspnet/core/signalr/configuration)
+* [JSON](https://www.json.org/)
+* [MessagePack](/aspnet/core/signalr/messagepackhubprotocol)
diff --git a/articles/azure-signalr/signalr-concept-performance.md b/articles/azure-signalr/signalr-concept-performance.md
@@ -11,15 +11,15 @@ ms.author: lianwei
 
 One of the key benefits of using Azure SignalR Service is the ease of scaling SignalR applications. In a large-scale scenario, performance is an important factor. 
 
-Article describes:
+This article describes:
 
 * The factors that affect SignalR application performance. 
 * The typical performance in different use-case scenarios.
 * The environment and tools that you can use to generate a performance report.
 
 ## Quick evaluation using metrics
 
-You can easily monitor your service in the Azure portal. From the **Metrics** page of your SignalR instance, you can select the **Server Load** metrics you can see the "pressure" of your service.
+You can easily monitor your service in the Azure portal. From the **Metrics** page of your SignalR instance, you can select the **Server Load** metrics to see the "pressure" of your service.
    
 <kbd>![Screenshot of the Server Load metric of Azure SignalR on Portal. The metrics shows Server Load is at about 8 percent usage. ](./media/signalr-concept-performance/server-load.png  "Server Load")</kbd>
 
@@ -57,8 +57,8 @@ To answer these questions, this guide first gives a high-level explanation of th
 
 This guide can't cover all scenarios (and different use cases, message sizes, message sending patterns, and so on). But it provides some methods to help you:
 
-- Evaluate your approximate requirement for the inbound or outbound messages.
-- Find the proper tiers by checking the performance table.
+* Evaluate your approximate requirement for the inbound or outbound messages.
+* Find the proper tiers by checking the performance table.
 
 ## Performance insight
 
@@ -95,7 +95,7 @@ Theoretically, Azure SignalR Service capacity is limited by compute resources: C
 The transport type is another factor that affects performance. The three types are:
 
 * [WebSocket](https://en.wikipedia.org/wiki/WebSocket): WebSocket is a bidirectional and full-duplex communication protocol over a single TCP connection. 
-* [Server-Sent-Event](https://en.wikipedia.org/wiki/Server-sent_events): erver-Sent-Event is a unidirectional protocol to push messages from server to client. 
+* [Server-Sent-Event](https://en.wikipedia.org/wiki/Server-sent_events): Server-Sent-Event is a unidirectional protocol to push messages from server to client. 
 * [Long-Polling](https://en.wikipedia.org/wiki/Push_technology): Long-Polling requires the clients to periodically poll information from the server through an HTTP request.
 
 For the same API under the same conditions, WebSocket has the best performance, Server-Sent-Event is slower, and Long-Polling is the slowest. Azure SignalR Service recommends WebSocket by default.
@@ -124,10 +124,10 @@ Assume that the app server is powerful enough and isn't the performance bottlene
 
 For a quick evaluation, assume the following default settings: 
 
-- The transport type is WebSocket.
-- The message size is 2,048 bytes.
-- A message is sent every 1 second.
-- Azure SignalR Service is in the default mode.
+* The transport type is WebSocket.
+* The message size is 2,048 bytes.
+* A message is sent every 1 second.
+* Azure SignalR Service is in the default mode.
 
 Every tier has its own maximum inbound bandwidth and outbound bandwidth. A smooth user experience isn't guaranteed after the inbound or outbound connection exceeds the limit.
 
@@ -154,15 +154,15 @@ Do *not* exceed the highlighted values in the following two tables.
   outboundBandwidth = outboundConnections * messageSize / sendInterval
 ```
 
-- *inboundConnections*: The number of connections sending the message.
+* *inboundConnections*: The number of connections sending the message.
 
-- *outboundConnections*: The number of connections receiving the message.
+* *outboundConnections*: The number of connections receiving the message.
 
-- *messageSize*: The size of a single message (average value). A small message that's less than 1,024 bytes has a performance impact that's similar to a 1,024-byte message.
+* *messageSize*: The size of a single message (average value). A small message that's less than 1,024 bytes has a performance impact that's similar to a 1,024-byte message.
 
-- *sendInterval*: The time of sending one message. Typically it's 1 second per message, which means sending one message every second. A smaller interval means sending more message in a time period. For example, 0.5 second per message means sending two messages every second.
+* *sendInterval*: The time of sending one message. Typically it's 1 second per message, which means sending one message every second. A smaller interval means sending more message in a time period. For example, 0.5 second per message means sending two messages every second.
 
-- *Connections*: The committed maximum threshold for Azure SignalR Service for every tier. If the connection number is increased further, it suffers from connection throttling.
+* *Connections*: The committed maximum threshold for Azure SignalR Service for every tier. If the connection number is increased further, it suffers from connection throttling.
 
 #### Evaluation for complex use cases
 
@@ -292,10 +292,10 @@ The **send to group** use case has a similar traffic pattern to **broadcast**. T
 Group member and group count are two factors that affect performance. To
 simplify the analysis, we define two kinds of groups:
 
-- **Small group**: Every group has 10 connections. The group number is equal to (max
+* **Small group**: Every group has 10 connections. The group number is equal to (max
 connection count) / 10. For example, for Unit1, if there are 1,000 connection counts, then we have 1000 / 10 = 100 groups.
 
-- **Big group**: The group number is always 10. The group member count is equal to (max
+* **Big group**: The group number is always 10. The group member count is equal to (max
 connection count) / 10. For example, for Unit1, if there are 1,000 connection counts, then every group has 1000 / 10 = 100 members.
 
 **Send to group** brings a routing cost to Azure SignalR Service because it has to find the target connections through a distributed data structure. As the sending connections increase, the cost increases.
