Azure SignalR Service 的效能指南
使用 Azure SignalR Service 的主要優點之一，是可以輕鬆調整 SignalR 應用程式。 在大規模案例中，效能便是重要的因素。
本文章說明：
- 影響 SignalR 應用程式效能的因素。
- 不同使用案例中的一般效能。
- 您可用來產生效能報告的環境和工具。
使用計量快速評估
您可以在 Azure 入口網站中輕鬆監視您的服務。 從 SignalR 執行個體的 [計量] 頁面，您可以選取 [伺服器負載] 計量以查看服務的「壓力」。
此圖表會顯示 SignalR 服務的運算壓力。 您可以測試您的案例並檢查此計量，以決定是否要相應增加。 如果伺服器負載低於 70%，則 SignalR 服務內會維持低延遲。
注意
如果您使用單位 50 或更大單位，而您的案例主要是傳送至小型群組 (群組大小 <20) 或單一連線，您就必須查看傳送至小型群組或傳送至連線以供參考。 在這些情況下，會有大型路由成本，但不包含在伺服器負載中。
詞彙定義
輸入：要傳入 Azure SignalR Service 的訊息。
輸出：從 Azure SignalR Service 傳出的訊息。
頻寬：所有訊息的大小總計 (以 1 秒為單位)。
預設模式：建立 Azure SignalR Service 執行個體時的預設工作模式。 Azure SignalR Service 預期應用程式伺服器在接受任何用戶端連線之前，會先與其建立連線。
無伺服器模式：Azure SignalR Service 僅接受用戶端連線的模式。 不允許伺服器連線。
概觀
Azure SignalR Service 針對不同的效能容量會定義七個標準層。 本指南會回答下列問題：
每一個階層 (單位) 的一般 Azure SignalR Service 效能為何？
Azure SignalR Service 是否符合訊息輸送量的需求 (例如，每秒傳送 100,000 則訊息)？
針對特定案例，如何選取適當的階層？
哪種類型的應用程式伺服器 (VM 大小) 適合我？ 我應該部署幾個？
為了回答這些問題，本指南會先提供效能影響因素的高階說明。 然後，其會針對一般使用案例說明每個階層的輸入和輸出訊息上限：回應、廣播、傳送至群組，以及傳送至連線 (對等聊天)。
本指南無法涵蓋所有案例 (以及不同的使用案例、訊息大小、訊息傳送模式等等)。 但其可提供一些方法來協助您：
- 評估輸入或輸出訊息的近似需求。
- 可藉由檢查效能資料表來尋找適當的階層。
效能深入解析
本節中說明效能評估方法，然後列出影響效能的所有因素。 最後，其會提供方法來協助您評估效能需求。
方法
輸送量和延遲是兩個效能檢查的一般層面。 針對 Azure SignalR Service，每個 SKU 階層都有其自己的輸送量節流原則。 原則會將允許的輸送量上限 (輸入和輸出頻寬) 定義為當 99% 的訊息出現小於 1 秒的延遲時所達到的輸送量上限。
延遲是從傳送訊息到接收來自 Azure SignalR Service 回應訊息的連線時間範圍。 採用回應做為範例。 每個用戶端連線都會在訊息中新增時間戳記。 應用程式伺服器的中樞會將原始訊息傳回到用戶端。 因此，每個用戶端連線都能輕鬆地計算傳播延遲。 廣播、傳送至群組，以及傳送至連線中的每個訊息都會附加時間戳記。
為模擬數千個並行用戶端連線，會在 Azure 的虛擬私人網路中建立多個 VM。 這所有的 VM 都會連線到相同的 Azure SignalR Service 執行個體。
在 Azure SignalR Service 的預設模式中，應用程式伺服器 VM 會部署在與用戶端 VM 相同的虛擬私人網路中。 所有用戶端 VM 和應用程式伺服器 VM 都會部署在相同區域的相同網路中，以避免跨區域延遲。
效能因素
下列因素會影響 SignalR 效能。
- SKU 階層 (CPU/記憶體)
- 連線數目
- 訊息大小
- 訊息傳送速率
- 傳輸類型 (WebSocket、Server-Sent-Event 或 Long-Polling)
- 使用案例 (路由成本)
- 應用程式伺服器和服務連線 (在伺服器模式中)
電腦資源
理論上，Azure SignalR Service 容量受限於計算資源：CPU、記憶體和網路。 例如，Azure SignalR Service 的連線增加會導致服務使用更多記憶體。 對於較大的訊息流量 (例如，每個訊息大於 2,048 個位元組)，Azure SignalR Service 需要花費更多 CPU 週期來處理流量。 同時，Azure 網路頻寬也會限制流量上限。
傳輸類型
傳輸類型是影響效能的另一個因素。 這三種類型為：
- WebSocket：WebSocket 是透過單一 TCP 連線的雙向及全雙工通訊協定。
- Server-Sent-Event：Server-Sent-Event 是單向通訊協定，可將訊息從伺服器推送到用戶端。
- Long-Polling：Long-Polling 需要用戶端透過 HTTP 要求定期輪詢伺服器中的資訊。
針對相同情況下的相同 API，WebSocket 具有最佳效能、Server-Sent-Event 速度較慢，而 Long-Polling 速度最慢。 Azure SignalR Service 預設建議使用 WebSocket。
訊息路由成本
訊息路由成本也會限制效能。 Azure SignalR Service 扮演訊息路由器的角色，會將訊息從一組用戶端或伺服器路由傳送至其他用戶端或伺服器。 不同的案例或 API 需要不同的路由原則。
針對回應，用戶端會將訊息傳送給本身，而路由目的地也是本身。 此模式的路由成本最低。 但針對廣播、傳送至群組和傳送至連線，Azure SignalR Service 必須透過內部分散式資料結構來查閱目標連線。 此額外處理會使用更多 CPU、記憶體和網路頻寬。 因此，效能會變慢。
在預設模式中，應用程式伺服器也可能變成特定案例的瓶頸。 Azure SignalR SDK 必須叫用中樞，同時透過活動訊號與每個用戶端維持即時連線。
在無伺服器模式中，用戶端會透過 HTTP Post 傳送訊息，這麼做的效率不如 WebSocket。
通訊協定
另一項因素是通訊協定：JSON 和 MessagePack。 MessagePack 的大小較小，且傳遞速度較 JSON 快。 不過，MessagePack 可能無法改善效能。 Azure SignalR Service 的效能對於通訊協定並不敏感，因為其不會在訊息從用戶端轉送至伺服器 (反之亦然) 期間，將訊息承載解碼。
尋找適當的 SKU
如何評估輸入/輸出容量，或尋找哪一個階層適合特定使用案例？
假設應用程式伺服器夠強大，且不是效能瓶頸。 然後，檢查每個階層的輸入和輸出頻寬上限。
快速評估
如需快速評估，請假設下列預設設定：
- 傳輸類型為 WebSocket。
- 訊息大小為 2,048 位元組。
- 每 1 秒會傳送一則訊息。
- Azure SignalR Service 處於預設模式。
每個階層都有自己的輸入頻寬和輸出頻寬上限。 在輸入或輸出連線超過限制之後，不保證有順暢的使用者體驗。
回應會有輸入頻寬上限，因為其路由成本最低。 廣播會定義輸出訊息頻寬上限。
請勿超過下列兩個資料表中反白顯示的值。
| 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 |
| 輸入頻寬 | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1,000 MBps | 2,000 MBps |
| 輸出頻寬 | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1,000 MBps | 2,000 MBps |
| 廣播 | 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 |
| 輸入頻寬 | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| 輸出頻寬 | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2,000 MBps | 4,000 MBps |
輸入頻寬和輸出頻寬是每秒訊息大小總計。 以下為其公式：
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
inboundConnections：傳送訊息的連線數目。
outboundConnections：接收訊息的連線數目。
messageSize：單一訊息的大小 (平均值)。 小於 1,024 位元組的小型訊息會有類似於 1,024 位元組訊息的效能影響。
sendInterval：傳送一則訊息的時間。 通常每則訊息為 1 秒，表示每秒傳送一則訊息。 間隔較小表示在一段時間內傳送更多訊息。 例如，每則訊息 0.5 秒表示每秒傳送兩則訊息。
連線：每個階層 Azure SignalR Service 的認可最大閾值。 如果進一步增加連線數目，則會受到連線節流影響。
注意
您必須相應增加至 SKU Premium_P2，才能使單位大小大於 100。
評估複雜使用案例
訊息大小較大或不同的傳送速率
實際使用案例較為複雜。 其可能會傳送大於 2,048 位元組的訊息，或傳送訊息速率不是每秒一則訊息。 讓我們以單位 100 的廣播為例，來了解如何評估其效能。
下表顯示廣播的實際使用案例。 但訊息大小、連線計數和訊息傳送速率與我們在上一節中所假設的不同。 問題是，如果我們只知道其中兩個項目，該如何推算這些項目 (訊息大小、連線計數或訊息傳送速率)。
| 廣播 | 訊息大小 | 同時輸入訊息 | 連線 | 傳送間隔 |
|---|---|---|---|---|
| 1 | 20 KB | 1 | 100,000 | 5 sec |
| 2 | 256 KB | 1 | 8,000 | 5 sec |
下列公式可輕鬆根據先前的公式進行推斷：
outboundConnections = outboundBandwidth * sendInterval / messageSize
針對單位 100，上表的輸出頻寬上限為 400 MB。 如果是 20 KB 訊息大小，輸出連線上限應該是 400 MB * 5 / 20 KB = 100,000，符合實際值。
混合使用案例
實際的使用案例通常會將四個基本使用案例混合在一起：回應、廣播、傳送至群組，以及傳送至連線。 您用來評估容量的方法為：
- 將混合使用案例分為四個基本使用案例。
- 個別使用上述公式來計算輸入和輸出訊息頻寬上限。
- 將頻寬計算加總，以取得輸入/輸出頻寬總計。
然後從輸入/輸出頻寬上限資料表中挑選適當的階層。
注意
若要將訊息傳送至數百或數千個小型群組，或對於互相傳送訊息的數千個用戶端，則會以路由成本為主。 將此影響納入考量。
針對將訊息傳送給用戶端的使用案例，請確定應用程式伺服器並非瓶頸。 下列「案例研究」一節提供您指導方針，說明需要多少應用程式伺服器，以及您應該設定多少伺服器連線。
案例研究
下列各節會討論 WebSocket 傳輸的四個典型使用案例：回應、廣播、傳送至群組，以及傳送至連線。 針對每個案例，區段會列出目前 Azure SignalR Service 的輸入和輸出容量。 其也說明影響效能的主要因素。
在預設模式中，應用程式伺服器會建立五個具有 Azure SignalR Service 的伺服器連線。 應用程式伺服器預設會使用 Azure SignalR Service SDK。 在下列效能測試結果中，伺服器連線會增加到 15 個 (或更多個，以進行廣播並將訊息傳送至大型群組)。
不同的使用案例對應用程式伺服器會有不同的需求。 廣播需要少量的應用程式伺服器。 回應或傳送至連線需要許多應用程式伺服器。
在所有使用案例中，預設訊息大小為 2,048 個位元組，而訊息傳送間隔為 1 秒。
預設模式
用戶端、Web 應用程式伺服器和 Azure SignalR Service 都涉及預設模式。 每個用戶端都代表一個單一連線。
Echo
首先，Web 應用程式會連線到 Azure SignalR Service。 其次，許多用戶端會連線到 Web 應用程式，如此會使用存取權杖和端點將用戶端重新導向至 Azure SignalR Service。 然後，用戶端會使用 Azure SignalR Service 建立 WebSocket 連線。
在所有用戶端建立連線之後，他們就會開始傳送訊息，其中包含每秒對特定中樞的時間戳記。 中樞會將訊息回應給其原始用戶端。 每個用戶端會在其收到回應訊息時計算延遲。
在下圖中，5 到 8 (紅色醒目提示的流量) 位於迴圈中。 迴圈會執行預設的持續時間 (5 分鐘)，並取得所有訊息延遲的統計資料。
回應的行為會判斷輸入頻寬上限等於輸出頻寬上限。 如需詳細資料，請參閱下表。
| 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 |
| 每秒輸入/輸出訊息 | 1,000 | 2,000 | 10,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 輸入/輸出頻寬 | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1,000 MBps | 2,000 MBps |
在此使用案例中，每個用戶端都會叫用應用程式伺服器中定義的中樞。 中樞只會呼叫原始用戶端中所定義的方法。 此中樞是回應的最輕量型中樞。
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
即使是對於這個簡單的中樞，應用程式伺服器上的流量壓力也會隨著回應輸入訊息負載增加而變得明顯。 此流量壓力需要大型 SKU 階層的許多應用程式伺服器。 下表列出每個階層的應用程式伺服器計數。
| 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 |
| 應用程式伺服器計數 | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
注意
應用程式伺服器的用戶端連線數目、訊息大小、訊息傳送速率、SKU 階層和 CPU/記憶體都會影響回應的整體效能。
廣播
針對廣播，當 Web 應用程式收到訊息時，會向所有用戶端廣播。 要廣播的用戶端越多，所有用戶端的訊息流量也就越多。 請參閱下圖。
少數用戶端正在廣播。 輸入訊息頻寬很小，但輸出頻寬很大。 輸出訊息頻寬會隨著用戶端連線或廣播速率增加而增加。
下表摘要說明用戶端連線上限、輸入/輸出訊息計數以及頻寬。
| 廣播 | 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 |
| 每秒輸入訊息 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| 每秒輸出訊息 | 2,000 | 4,000 | 20,000 | 100,000 | 200,000 | 400,000 | 1,000,000 | 2,000,000 |
| 輸入頻寬 | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| 輸出頻寬 | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2,000 MBps | 4,000 MBps |
張貼訊息的廣播用戶端不超過四個。 相較於回應，其需要較少的應用程式伺服器，因為輸入訊息數目很小。 兩個應用程式伺服器即可滿足 SLA 和效能考量。 但您應該增加預設伺服器連線以避免不平衡的情況，特別是針對大於 50 的單位。
| 廣播 | 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 |
| 應用程式伺服器計數 | 1 | 1 | 7 | 2 | 2 | 4 | 10 | 20 |
注意
在每個應用程式伺服器上，將預設伺服器連線從 5 個增加到 40 個，以避免 Azure SignalR Service 可能不平衡伺服器的連線。
用戶端連線數目、訊息大小、訊息傳送速率和 SKU 階層都會影響廣播的整體效能。
群組至群組
傳送至群組使用案例具有類似的流量模式進行廣播。 差異在於用戶端建立與 Azure SignalR Service 的 WebSocket 連線之後，他們必須先加入群組，才能將訊息傳送至特定群組。 下圖說明流量流程。
群組成員和群組計數是影響效能的兩個因素。 為了簡化分析，我們會定義兩種群組：
小型群組：每個群組都有 10 個連線。 群組數目等於 (連線計數上限) / 10。 例如，針對單位 1，如果有 1,000 個連線計數，則我們有 1000/10 = 100 個群組。
大型群組：群組數目一律為 10。 群組成員計數等於 (連線計數上限) / 10。 例如，針對單元 1，如果有 1,000 個連線計數，則每個群組都有 1000/10 = 100 個成員。
傳送至群組會將路由成本帶到 Azure SignalR Service，因為其必須透過分散式資料結構來尋找目標連線。 隨著傳送連線增加，成本也會增加。
小型群組
路由成本對於將訊息傳送至許多小型群組而言相當重要。 目前，Azure SignalR Service 實作達到單位 50 的路由成本限制。 新增更多 CPU 和記憶體並沒有幫助，因此單位 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 |
許多用戶端連線都會呼叫中樞，因此應用程式伺服器數目對效能也很重要。 下表列出建議的應用程式伺服器計數。
| 傳送至小型群組 | 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 |
| 應用程式伺服器計數 | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
注意
應用程式伺服器的用戶端連線數目、訊息大小、訊息傳送速率、SKU 階層和 CPU/記憶體都會影響回應的整體效能。
資料表中列出的群組計數、群組成員計數不是硬性限制。 系統會選取這些參數值來建立穩定的基準案例。 例如，可以將每個連線指派給不同的群組。 在此設定下，效能會接近傳送至連線。
大型群組
對於傳送至大型群組，輸出頻寬會在達到路由成本限制之前變成瓶頸。 下表列出輸出頻寬上限，這與廣播的輸出頻寬幾乎相同。
| 傳送至大型群組 | 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 | 500 | 1,000 | 2,000 | 5,000 | 10,000 | 20,000 |
| 群組計數 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| 每秒輸入訊息 | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| 輸入頻寬 | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps |
| 每秒輸出訊息 | 2,000 | 4,000 | 20,000 | 100,000 | 200,000 | 400,000 | 1,000,000 | 2,000,000 |
| 輸出頻寬 | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2,000 MBps | 4,000 MBps |
傳送連線計數不超過 40。 應用程式伺服器上的負擔很小，因此建議的 Web 應用程式數目很少。
| 傳送至大型群組 | 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 |
| 應用程式伺服器計數 | 1 | 7 | 2 | 2 | 2 | 4 | 10 | 20 |
注意
在每個應用程式伺服器上，將預設伺服器連線從 5 個增加到 40 個，以避免 Azure SignalR Service 可能不平衡伺服器的連線。
用戶端連線數目、訊息大小、訊息傳送速率、路由成本和 SKU 階層都會影響傳送至大型群組的整體效能。
傳送至連線
在傳送至連線使用案例中，當用戶端建立與 Azure SignalR Service 的連線時，每個用戶端都會呼叫特殊中樞，以取得自己的連線識別碼。 效能基準測試會收集所有連線識別碼、隨機顯示，並將其重新指派給所有用戶端做為傳送目標。 用戶端會持續將訊息傳送至目標連線，直到效能測試完成為止。
傳送至連線的路由成本類似於傳送至小型群組的成本。
隨著連線數目增加，路由成本會成為限制整體效能的重要因素。 值得注意的是，單位 20 會標示服務達到路由瓶頸的閾值。 單位計數的進一步增加不會帶來效能改善，除非轉向至 Premium_P2 (單位 >=100)，這會增強路由功能。
下表是執行傳送至連線基準測試許多回合之後的統計摘要。
| 傳送至連線 | 1 個單位 | 2 個單位 | 20 個單位 | 50 個單位 | 100 個單位 | 200 個單位 | 500 個單位 | 1000 個單位 |
|---|---|---|---|---|---|---|---|---|
| 連線 | 1,000 | 2,000 | 20,000 | 50,000 | 100,000 | 200,000 | 500,000 | 1,000,000 |
| 每秒輸入/輸出訊息 | 1,000 | 2,000 | 20,000 | 20,000 | 20,000 | 40,000 | 100,000 | 200,000 |
| 輸入/輸出頻寬 | 2 MBps | 4 MBps | 40 MBps | 40 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
注意
儘管在單位 20 之後每秒的輸入/輸出訊息停滯不前，但更多連線容量仍會持續成長。 在實際的商務實例中，形成瓶頸的通常是連線計數，而不是同時訊息傳送活動。 所有連線都會像基準測試那樣以高頻率傳送訊息的情況並不常見。
此使用案例在應用程式伺服器端需要高負載。 請參閱下表的建議應用程式伺服器計數。
| 傳送至連線 | 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 |
| 應用程式伺服器計數 | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
注意
應用程式伺服器的用戶端連線數目、訊息大小、訊息傳送速率、SKU 階層和 CPU/記憶體都會影響傳送至連線的整體效能。
ASP.NET SignalR
Azure SignalR Service 為 ASP.NET SignalR 提供相同的效能容量。
無伺服器模式
用戶端和 Azure SignalR Service 涉及無伺服器模式。 每個用戶端都代表一個單一連線。 用戶端會透過 REST API 將訊息傳送至另一個用戶端，或將訊息廣播至所有用戶端。
透過 REST API 傳送高密度訊息，並不如使用 WebSocket 有效率。 這需要您每次建置新的 HTTP 連線，且這是無伺服器模式的額外成本。
透過 REST API 廣播
所有用戶端都會使用 Azure SignalR Service 建立 WebSocket 連線。 然後，某些用戶端會透過 REST API 開始廣播。 傳送訊息 (輸入) 全都是透過 HTTP Post 進行，與 WebSocket 相比效率不高。
| 透過 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 |
| 每秒輸入訊息 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| 每秒輸出訊息 | 2,000 | 4,000 | 20,000 | 100,000 | 200,000 | 400,000 | 1,000,000 | 2,000,000 |
| 輸入頻寬 | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| 輸出頻寬 | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2,000 MBps | 4,000 MBps |
透過 REST API 傳送給使用者
基準測試會先將使用者名稱指派給所有用戶端，再開始連線到 Azure SignalR Service。 在用戶端建立與 Azure SignalR Service 的 WebSocket 連線之後，他們就會開始透過 HTTP Post 傳送訊息給其他人。
| 透過 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 |
| 每秒輸入/輸出訊息 | 200 | 400 | 2,000 | 10,000 | 20,000 | 40,000 | 100,000 | 200,000 |
| 輸入/輸出頻寬 | 400 KBps | 800 KBps | 4 MBps | 20 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
效能測試環境
對於上述列出的所有使用案例，我們在 Azure 環境中進行了效能測試。 我們最多使用了 200 個用戶端 VM 和 100 個應用程式伺服器 VM。 以下是一些詳細資料：
用戶端 VM 大小：StandardDS2V2 (2 vCPU、7G 記憶體)
應用程式伺服器 VM 大小：StandardF4sV2 (4 vCPU、8G 記憶體)
Azure SignalR SDK 伺服器連線：15
效能工具
您可以在 GitHub 上找到 Azure SignalR Service 的效能工具。
下一步
在本文中，您已在一般使用案例中了解 Azure SignalR Service 效能的概觀。
若要取得服務內部項目及其調整的詳細資料，請閱讀下列指南：
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應