You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-web-pubsub/concept-performance.md
+60-58Lines changed: 60 additions & 58 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,20 +10,20 @@ author: bjqian
10
10
11
11
# Performance guide for Azure Web PubSub Service
12
12
13
-
One of the key benefits of using Azure Web PubSub Service is the ease of scaling Web PubSub upstream applications. In a large-scale scenario, performance is an important factor.
13
+
One of the key benefits of using Azure Web PubSub Service is the ease of scaling. In a large-scale scenario, performance is an important factor.
14
14
15
-
In this guide, we'll introduce the factors that affect Web PubSub upstream application performance. We'll describe typical performance in different use-case scenarios.
15
+
In this guide, we introduce the factors that affect Web PubSub service performance. We describe typical performance in different use-case scenarios.
16
16
17
17
## Quick evaluation using metrics
18
-
Before going through the factors that impact the performance, let's first introduce an easy way to monitor the pressure of your service. There's a metrics called **Server Load** on the Portal.
18
+
Before going through the factors that impact the performance, let's first introduce an easy way to monitor the pressure of your service. There's a metric called **Server Load** on the Portal.
19
19
20
-
<kbd>![Screenshot of the Server Load metric of Azure Web PubSub on Portal. The metrics shows Server Load is at about 8 percent usage. ](./media/concept-performance/server-load.png"Server Load")</kbd>
20
+
<kbd>![Screenshot of the Server Load metric of Azure Web PubSub on Portal. The metric shows Server Load is at about 8 percent usage. ](./media/concept-performance/server-load.png"Server Load")</kbd>
21
21
22
22
23
-
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%.
23
+
It shows the computing pressure of your Azure Web PubSub service. You could test on your own scenario and check this metric to decide whether to scale up. The latency inside Azure Web PubSub service would remain low if the Server Load is below 70%.
24
24
25
25
> [!NOTE]
26
-
> 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.
26
+
> If you are using unit 50 or larger**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.
27
27
28
28
Below are detailed concepts for evaluating performance.
29
29
## Term definitions
@@ -36,16 +36,15 @@ In this guide, we'll introduce the factors that affect Web PubSub upstream appli
36
36
37
37
## Overview
38
38
39
-
Azure Web PubSub Service defines seven Standard tiers for different performance capacities. This
40
-
guide answers the following questions:
39
+
This guide answers the following questions:
41
40
42
-
- What is the typical Azure Web PubSub Service performance for each tier?
41
+
- What is the typical Azure Web PubSub Service performance for each unit size?
43
42
44
43
- Does Azure Web PubSub Service meet my requirements for message throughput (for example, sending 100,000 messages per second)?
45
44
46
-
- For my specific scenario, which tier is suitable for me? Or how can I select the proper tier?
45
+
- For my specific scenario, how can I select the proper unit size?
47
46
48
-
To answer these questions, this guide first gives a high-level explanation of the factors that affect performance. It then illustrates the maximum inbound and outbound messages for every tier for typical use cases: **Send to groups through Web PubSub subprotocol**, **upstream**, and **rest api** .
47
+
To answer these questions, this guide first gives a high-level explanation of the factors that affect performance. It then illustrates the maximum inbound and outbound messages for typical use cases: **Send to groups through Web PubSub subprotocol**, **upstream**, and **rest api** .
49
48
50
49
This guide can't cover all scenarios (and different use cases, message sizes, message sending patterns, and so on). But it provides some basic information to understand the performance limitation.
51
50
@@ -55,7 +54,7 @@ This section describes the performance evaluation methodologies, and then lists
55
54
56
55
### Methodology
57
56
58
-
*Throughput* and *latency* are two typical aspects of performance checking. For Azure Web PubSub Service, each SKU tier has its own throughput throttling policy. The policy defines *the maximum allowed throughput (inbound and outbound bandwidth)* as the maximum achieved throughput when 99 percent of messages have latency that's less than 1 second.
57
+
*Throughput* and *latency* are two typical aspects of performance checking. The *maximum throughput (inbound and outbound bandwidth)*is defined as the maximum achieved throughput when 99 percent of messages have latency that's less than 1 second. It's **not** a hard limit.
59
58
60
59
### Performance factors
61
60
@@ -67,7 +66,7 @@ For **echo**, the client sends a message to the upstream, and upstream echoes th
67
66
68
67
In summary, the following factors affect the inbound and outbound capacity:
69
68
70
-
-SKU tier (CPU/memory)
69
+
-Unit size (CPU/memory)
71
70
72
71
- Number of connections
73
72
@@ -78,11 +77,11 @@ In summary, the following factors affect the inbound and outbound capacity:
78
77
- Use-case scenario (routing cost)
79
78
80
79
81
-
### Finding a proper SKU
80
+
### Finding a proper unit size
82
81
83
-
How can you evaluate the inbound/outbound capacity or find which tier is suitable for a specific use case?
82
+
How can you evaluate the inbound/outbound capacity or find which unit size is suitable for a specific use case?
84
83
85
-
Every tier has its own maximum inbound bandwidth and outbound bandwidth. A smooth user experience isn't guaranteed after the inbound or outbound traffic exceeds the limit.
84
+
Each unit size has its own maximum inbound bandwidth and outbound bandwidth. A smooth user experience isn't guaranteed after the inbound or outbound traffic exceeds the threshold.
@@ -93,9 +92,9 @@ Every tier has its own maximum inbound bandwidth and outbound bandwidth. A smoot
93
92
-*outboundConnections*: The number of connections receiving the message.
94
93
-*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.
95
94
-*sendInterval*: The interval for sending messages. For example, 1 second means sending one message every second. A smaller interval means sending more messages in a time period. For example, 0.5 second means sending two messages every second.
96
-
-*Connections*: The committed maximum threshold for Azure Web PubSub Service for every tier. Connections that exceed the threshold get throttled.
95
+
-*Connections*: The committed maximum threshold for Azure Web PubSub Service for each unit size. Connections that exceed the threshold get throttled.
97
96
98
-
Assume that the upstream is powerful enough and isn't the performance bottleneck. Then, check the maximum inbound and outbound bandwidth for every tier.
97
+
Assume that the upstream is powerful enough and isn't the performance bottleneck. Then, check the maximum inbound and outbound bandwidth for each unit size.
99
98
100
99
## Case study
101
100
@@ -111,39 +110,40 @@ The service supports a specific subprotocol called `json.webpubsub.azure.v1`, wh
111
110
Group member and group count are two factors that affect performance. To simplify the analysis, we define two kinds of groups:
112
111
113
112
-**Big group**: The group number is always 10. The group member count is equal to (max
114
-
connection count) / 10. For example, for Unit1, if there are 1,000 connection counts, then every group has 1000 / 10 = 100 members.
113
+
connection count) / 10. For example, for Unit 1, if there are 1,000 connection counts, then every group has 1000 / 10 = 100 members.
115
114
-**Small group**: Every group has 10 connections. The group number is equal to (max
116
-
connection count) / 10. For example, for Unit1, if there are 1,000 connection counts, then we have 1000 / 10 = 100 groups.
115
+
connection count) / 10. For example, for Unit 1, if there are 1,000 connection counts, then we have 1000 / 10 = 100 groups.
117
116
118
117
**Send to group** brings a routing cost to Azure Web PubSub Service because it has to find the target connections through a distributed data structure. As the sending connections increase, the cost increases.
119
118
120
119
##### Big group
121
120
122
121
For **send to big group**, the outbound bandwidth becomes the bottleneck before hitting the routing cost limit. The following table lists the maximum outbound bandwidth.
123
122
124
-
| Send to big group | Unit1 | Unit2 | Unit5 | Unit10 | Unit20 | Unit50 | Unit100 |
The routing cost is significant for sending message to many small groups. Currently, the Azure Web PubSub Service implementation hits the routing cost limit at Unit 50. Adding more CPU and memory doesn't help, so Unit100 can't improve further by design. If you need more inbound bandwidth, contact customer support.
136
+
The routing cost is significant for sending message to many small groups. Currently, the Azure Web PubSub Service implementation hits the routing cost limit at Unit 50. Adding more CPU and memory doesn't help, so Unit 100 can't improve further by design. If you need more inbound bandwidth, need to scale up to use **Premium_P2**(unit >100).
137
137
138
-
| Send to small group |Unit1 | Unit2 | Unit5 | Unit10 | Unit20 |Unit50 | Unit100 |
> 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.
@@ -162,11 +162,12 @@ For every event, it formulates an HTTP POST request to the registered upstream a
162
162
163
163
In this case, the app server writes back the original message back in the http response. The behavior of **echo** determines that the maximum inbound bandwidth is equal to the maximum outbound bandwidth. For details, see the following table.
0 commit comments