Azure SignalR Service 中的訊息和連線
Azure SignalR Service 的計費模型是以連線數目和來自服務的輸出訊息數目為基礎。 本文說明如何定義及計算訊息和連線，以供計費。
訊息格式
Azure SignalR Service 所支援的格式與 ASP.NET Core SignalR 相同：JSON 和 MessagePack。
訊息大小
下列限制適用於 Azure SignalR Service 訊息：
- 用戶端訊息：
- 針對長輪詢或伺服器端事件，用戶端無法傳送大於 1MB 的訊息。
- 服務的 WebSocket 沒有大小限制。
- 應用程式伺服器可以設定用戶端訊息大小的限制。 預設值為 32 KB。 如需詳細資訊，請參閱 ASP.NET Core SignalR 的安全性考量。
- 對於無伺服器，訊息大小會受限於上游實作方式，但建議使用 1MB 以下。
- 伺服器訊息：
- 伺服器訊息大小沒有限制，但建議使用 16 MB 以下。
- 應用程式伺服器可以設定用戶端訊息大小的限制。 預設值為 32 KB。 如需詳細資訊，請參閱 ASP.NET Core SignalR 的安全性考量。
- 無伺服器：
- Rest API：訊息本文為 1 MB，標頭為 16 KB。
- WebSocket、管理 SDK 持續模式沒有限制，但建議使用 16 MB 以下。
針對 WebSocket 用戶端，大型訊息會分割成各自不超過 2 KB 的較小訊息，且個別地傳輸。 SDK 會處理訊息的分割和組合。 開發人員不需要投入這方面的人力。
訊息過大會對傳訊效能造成負面影響。 請盡可能使用較小的訊息，並經由測試來決定每個使用案例的的最佳訊息大小。
如何計算訊息以供計費
傳送至服務的訊息是輸入訊息，而從服務傳出的訊息是輸出訊息。 僅對來自 Azure SignalR Service 的輸出訊息進行計費。 用戶端與伺服器之間的 Ping 訊息會予以忽略。
系統會將大於 2 KB 的訊息計算為多則 2 KB 的訊息。 Azure 入口網站中的訊息計數圖表會在每個中樞達到 100 則訊息時更新一次。
例如，假設您有一個應用程式伺服器和三個用戶端：
當應用程式伺服器將 1 KB 訊息廣播至所有連線的用戶端，從應用程式伺服器到服務的訊息會視為免費輸入訊息。 從服務傳送到每個用戶端的三則訊息是輸出訊息並進行計費。
當用戶端 A 將 1 KB 的輸入訊息傳送至用戶端 B，而不需要透過應用程式伺服器時，該訊息是免費的輸入訊息。 從服務路由到用戶端 B 的訊息會以輸出訊息的形式計費。
如果您有三個用戶端和一個應用程式伺服器，當一個用戶端傳送 4 KB 的訊息給伺服器以廣播至所有用戶端時，計費的訊息計數將是 8：
- 從服務到應用程式伺服器的一則訊息。
- 從服務到用戶端的三則訊息。 每則訊息分別計為兩則 2 KB 的訊息。
如何計算連線
Azure SignalR Service 會建立應用程式伺服器和用戶端連線。 根據預設，每個應用程式伺服器會以一個中樞有五個初始連線，而每個用戶端有一個用戶端連線的設定開始。
例如，假設您有兩個應用程式伺服器，並且在程式碼中定義了五個中樞。 伺服器連線計數為 50：(2 個應用程式伺服器 * 5 個中樞 * 每個中樞 5 個連線)。
Azure 入口網站中顯示的連線計數包括伺服器、用戶端、診斷和即時追蹤連線。 連線類型會在下列清單中進行定義：
- 伺服器連線：將Azure SignalR Service 和應用程式伺服器連線。
- 用戶端連線：將Azure SignalR Service 和用戶端應用程式連線。
- 診斷連線：一種用戶端連線的特殊類型，可產生更詳細的記錄檔，這可能會影響效能。 這種用戶端的設計目的是為了進行疑難排解。
- 即時追蹤連線：連線到即時追蹤端點，並接收 Azure SignalR Service 的即時追蹤資訊。
即時追蹤連線不會視為用戶端連線或伺服器連線。
ASP.NET SignalR 會以不同的方式計算伺服器連線。 除了您定義的中樞以外，它還包含一個預設中樞。 根據預設，每個應用程式伺服器另需 5 個初始伺服器連線。 預設中樞的初始連線計數會與其他中樞保持一致。
服務和應用程式伺服器會維持同步連線狀態，並針對伺服器連線進行調整以取得更好的效能並提高服務穩定性。 因此，您可能會在執行服務中看到伺服器連線數目的變更。