Azure SignalR Service 的效能指南
使用 Azure SignalR Service 的主要優點之一，是輕鬆地調整 SignalR 應用程式。 在大規模案例中，效能是一個重要因素。
本文章說明：
- 影響 SignalR 應用程式效能的因素。
- 不同使用案例中的一般效能。
- 您可以用來產生效能報告的環境和工具。
使用計量快速評估
您可以輕鬆地在 Azure 入口網站 中監視您的服務。 從 SignalR 實體的 [計量] 頁面，您可以選取 [伺服器負載計量] 以查看您服務的「壓力」。
此圖表顯示 SignalR 服務的運算壓力。 您可以測試您的案例，並檢查此計量，以決定是否要相應增加。 如果伺服器負載低於 70%，SignalR 服務內的延遲仍然很低。
注意
如果您使用單位 50 或更大 ，而且 您的案例主要傳送至小型群組（群組大小 <20）或單一連線，您必須檢查 傳送至小型群組 或 傳送至連線 以供參考。 在這些情況下，伺服器負載中不包含大量路由成本。
字詞定義
輸入：Azure SignalR 服務的傳入訊息。
輸出：來自 Azure Signalr 服務的傳出訊息。
帶寬：1 秒內所有訊息的總大小。
默認模式：建立 Azure SignalR Service 實例時的預設工作模式。 Azure SignalR Service 預期應用程式伺服器會在接受任何用戶端連線之前，先與其建立連線。
無伺服器模式：Azure SignalR Service 只接受用戶端連線的模式。 不允許任何伺服器連線。
概觀
Azure SignalR Service 會針對不同的效能容量定義七個標準層。 本指南回答下列問題：
每個層級的一般 Azure SignalR 服務效能為何（單位）？
Azure SignalR Service 是否符合訊息輸送量的需求（例如每秒傳送 100,000 則訊息）。
針對特定案例，如何選取適當的階層？
哪種應用程式伺服器 （VM 大小） 適合我？ 我應該部署多少個？
為了回答這些問題，本指南會先提供影響效能的因素的高階說明。 然後，它會說明一般使用案例中每個層的輸入和輸出訊息上限：回應、廣播、傳送至群組，以及傳送至連線（點對點聊天）。
本指南無法涵蓋所有案例（以及不同的使用案例、訊息大小、訊息傳送模式等等）。 但它提供一些方法來協助您：
- 評估輸入或輸出訊息的近似需求。
- 藉由檢查效能數據表來尋找適當的階層。
效能深入解析
本節說明效能評估方法，然後列出影響效能的所有因素。 最後，它會提供方法來協助您評估效能需求。
方法
輸送量 和 延遲 是效能檢查的兩個典型層面。 針對 Azure SignalR 服務，每個 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 服務容量受限於計算資源：CPU、記憶體和網路。 例如，對 Azure SignalR Service 的更多聯機會導致服務使用更多記憶體。 對於較大的訊息流量（例如，每個訊息大於 2,048 個字節），Azure SignalR 服務需要花費更多 CPU 週期來處理流量。 同時，Azure 網路頻寬也會限制流量上限。
傳輸類型
傳輸類型是影響效能的另一個因素。 這三種類型為：
- WebSocket：WebSocket 是透過單一 TCP 連線的雙向和全雙工通訊協定。
- Server-Sent-Event：Server-Sent-Event 是將訊息從伺服器推送至用戶端的單向通訊協定。
- 長輪詢：長時間輪詢需要用戶端定期透過 HTTP 要求從伺服器輪詢資訊。
針對相同條件下的相同 API，WebSocket 具有最佳效能、Server-Sent-Event 速度較慢，而 Long-Polling 是最慢的。 Azure SignalR Service 預設會建議 WebSocket。
訊息路由成本
訊息路由成本也會限制效能。 Azure SignalR 服務扮演訊息路由器的角色，它會將訊息從一組用戶端或伺服器路由傳送至其他用戶端或伺服器。 不同的案例或 API 需要不同的路由原則。
針對 回應，用戶端會將訊息傳送至本身，而路由目的地本身也是。 此模式具有最低的路由成本。 但是，針對廣播、傳送至群組和傳送至連線，Azure SignalR 服務必須透過內部分散式數據結構查閱目標連線。 此額外處理會使用更多CPU、記憶體和網路頻寬。 因此，效能會變慢。
在預設模式中，應用程式伺服器也可能成為特定案例的瓶頸。 Azure SignalR SDK 必須叫用中樞，同時透過活動訊號訊號與每個客戶端維持即時連線。
在無伺服器模式中，用戶端會透過 HTTP 張貼傳送訊息，這不像 WebSocket 那麼有效率。
通訊協定
另一個因素是通訊協定：JSON 和 MessagePack。 MessagePack 的大小較小，且傳遞速度比 JSON 快。 不過，MessagePack 可能無法改善效能。 Azure SignalR Service 的效能對通訊協定並不敏感，因為它不會在從用戶端轉送至伺服器訊息期間將訊息承載譯碼，反之亦然。
尋找適當的 SKU
如何評估輸入/輸出容量，或尋找哪一層適合特定使用案例？
假設應用程式伺服器足夠強大，而且不是效能瓶頸。 然後，檢查每一層的輸入和輸出頻寬上限。
快速評估
如需快速評估，請假設下列預設設定：
- 傳輸類型為 WebSocket。
- 訊息大小為 2,048 個字節。
- 每1秒就會傳送一則訊息。
- Azure SignalR 服務處於預設模式。
每一層都有自己的輸入頻寬和輸出頻寬上限。 在輸入或輸出連線超過限制之後，無法保證順暢的使用者體驗。
Echo 會提供輸入頻寬上限，因為它的路由成本最低。 廣播 會定義輸出訊息頻寬上限。
請勿 超過下列兩個數據表中的反白顯示值。
| 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
inbound連線ions ：傳送訊息的連線數目。
outbound連線ions ：接收訊息的連線數目。
messageSize ：單一訊息的大小（平均值）。 小於 1,024 個位元組的小型訊息對效能的影響類似于 1,024 位元組的訊息。
sendInterval ：傳送一則訊息的時間。 通常是每則訊息 1 秒，這表示每秒傳送一則訊息。 較小的間隔表示在一段時間內傳送更多訊息。 例如，每則訊息 0.5 碼錶示每秒傳送兩則訊息。
連線： 每個層級的 Azure SignalR Service 認可最大閾值。 如果連線號碼進一步增加，它就會遭受連線節流。
注意
您必須相應增加至 SKU 進階版_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/記憶體會影響傳送至小型群組 的整體效能 。
資料表 中列出的群組計數、群組成員計數不是硬性限制 。 系統會選取這些參數值來建立穩定的基準測試案例。 例如，將每個 conneciton 指派給不同的群組是可以的。 在此設定下，效能會接近 傳送至連線 。
大型群組
對於 傳送至大型群組 ，輸出頻寬會在達到路由成本限制之前成為瓶頸。 下表列出輸出頻寬上限，這幾乎與 廣播 的輸出頻寬相同。
| 傳送至大型群組 | 單位 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 服務的連線時，每個用戶端都會呼叫特殊的中樞以取得自己的連線識別碼。 效能基準會收集所有連線識別碼、隨機顯示，並將其重新指派給所有用戶端做為傳送目標。 用戶端會持續將訊息傳送至目標連線，直到效能測試完成為止。
傳送至連線 的 路由成本類似于傳送至小型群組 的成本。
隨著連線數目增加，路由成本會成為限制整體效能的重要因素。 值得注意的是，單位 20 會標示服務達到路由瓶頸的臨界值。 單位元數目的進一步增加不會產生效能改善，除非有轉移至 進階版_P2（unit > =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 服務為 signalR ASP.NET 提供相同的效能容量。
無伺服器模式
用戶端和 Azure SignalR 服務涉及無伺服器模式。 每個用戶端都代表單一連線。 用戶端會透過 REST API 將訊息傳送至另一個用戶端，或將訊息廣播至所有用戶端。
透過 REST API 傳送高密度訊息並不像使用 WebSocket 那麼有效率。 每次都需要您建置新的 HTTP 連線，這是無伺服器模式的額外成本。
透過 REST API 廣播
所有客戶端都會使用 Azure SignalR 服務建立 WebSocket 連線。 然後，某些用戶端會透過 REST API 開始廣播。 與 WebSocket 相比，傳送訊息（輸入）全都是透過 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 服務效能的概觀。
若要取得服務內部和調整的詳細數據，請閱讀下列指南：