Azure Web PubSub 服務的效能指南
使用 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 服務是否符合訊息輸送量的需求（例如每秒傳送 100,000 則訊息）？
針對特定案例，如何選取適當的單位大小？
為了回答這些問題，本指南會先提供影響效能的因素的高階說明。 然後說明一般使用案例的輸入和輸出訊息上限： 透過 Web PubSub 子程式、 上游和 rest API 傳送至群組。
本指南無法涵蓋所有案例（以及不同的使用案例、訊息大小、訊息傳送模式等等）。 但它提供一些基本資訊來瞭解效能限制。
效能深入解析
本節說明效能評估方法，然後列出影響效能的所有因素。 最後，它會提供方法來協助您評估效能需求。
方法
輸送量 和 延遲 是效能檢查的兩個典型層面。 當 99% 的訊息有小於 1 秒的延遲時，最大輸送量（輸入和輸出頻寬） 定義為達到的最大輸送量。 這不是硬性限制。
效能因素
理論上，Azure Web PubSub 服務容量受限於計算資源：CPU、記憶體和網路。 例如，更多 Azure Web PubSub 服務的聯機會導致服務使用更多記憶體。 對於較大的訊息流量（例如，每個訊息大於 2,048 個字節），Azure Web PubSub 服務需要花費更多 CPU 周期來處理流量。
訊息路由成本也會限制效能。 Azure Web PubSub 服務扮演訊息代理程式的角色，它會在一組客戶端之間路由傳送訊息。 不同的案例或 API 需要不同的路由原則。
若為 回應，用戶端會將訊息傳送至上游，而上游會將訊息傳回用戶端。 此模式具有最低的路由成本。 但是，針對廣播、傳送至群組和傳送至連線，Azure Web PubSub 服務必須透過內部分散式數據結構查閱目標連線。 此額外處理會使用更多CPU、記憶體和網路頻寬。 因此，效能會變慢。
總而言之，下列因素會影響輸入和輸出容量：
單位大小 （CPU/記憶體）
連線數目
訊息大小
訊息傳送速率
使用案例 （路由成本）
尋找適當的單位大小
如何評估輸入/輸出容量，或尋找適合特定使用案例的單位大小？
每個單位大小都有自己的輸入頻寬上限和輸出頻寬。 在輸入或輸出流量超過閾值之後，無法保證順暢的用戶體驗。
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
- inbound 連線 ions：傳送訊息的連線數目。
- outbound 連線 ions：接收訊息的連接數目。
- messageSize：單一訊息的大小（平均值）。 小於 1,024 個字節的小型訊息對效能的影響類似於 1,024 位元組的訊息。
- sendInterval：傳送訊息的間隔。 例如，1 秒表示每秒傳送一則訊息。 較小的間隔表示在一段時間內傳送更多訊息。 例如，0.5 秒表示每秒傳送兩則訊息。
- 連線：每個單位大小的 Azure Web PubSub 服務已認可最大閾值。 超過閾值的 連線 會受到節流。
假設上游功能足夠強大，而且效能瓶頸不足。 然後，檢查每個單位大小的輸入和輸出頻寬上限。
案例研究
下列各節會進行三個典型的使用案例：透過 Web PubSub 子程式傳送至群組、觸發 CloudEvent、呼叫 rest api。 針對每個案例，區段會列出 Azure Web PubSub Service 目前的輸入和輸出容量。 它也會說明影響效能的主要因素。
在所有使用案例中，預設訊息大小為 2,048 個字節，而訊息傳送間隔為 1 秒。
透過 Web PubSub 子程式傳送至群組
此服務支持稱為 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 |
小型群組
將訊息傳送至許多小型群組時，路由成本相當重要。 目前，Azure Web PubSub 服務實作達到單位 50 的路由成本限制。 新增更多 CPU 和記憶體並無濟於事，因此單元 100 無法透過設計進一步改善。 如果您需要更多輸入頻寬，則必須相應增加以使用 進階版_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 | 2,000 MBps |
注意
數據表 中列出的群組計數、群組成員計數不是硬性限制。 系統會選取這些參數值來建立穩定的基準檢驗案例。
觸發雲端事件
服務會使用 CloudEvents HTTP 通訊協定將用戶端事件傳遞至上游 Webhook。
針對每個事件，它會針對已註冊的上游制定 HTTP POST 要求，並預期會有 HTTP 回應。
注意
Web PubSub 也支援 HTTP 2.0 來傳遞上游事件。 下列結果會使用 HTTP 1.1 進行測試。 如果您的應用程式伺服器支援 HTTP 2.0，效能會更好。
Echo
在此情況下，應用程式伺服器會在 HTTP 回應中回寫原始訊息。 響應的行為會判斷輸入頻寬上限等於輸出頻寬上限。 如需詳細資訊，請參閱下表。
| Echo | 單位 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 |
REST API
Azure Web PubSub 提供強大的 API 來管理客戶端並傳遞即時訊息。
透過 REST 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 廣播
帶寬與 傳送至大型群組的頻寬相同。
| 透過 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 |
下一步
使用這些資源開始建置您自己的應用程式：