Azure SignalR Service 中的訊息和連線

  • 發行項

Azure SignalR 服務的計費模型是以連線數目和來自服務的輸出訊息數目為基礎。 本文說明如何定義和計算計費的訊息和連線。

訊息格式

Azure SignalR Service 支援與核心 SignalR：JSON 和 MessagePack 相同的格式 ASP.NET 。

訊息大小

下列限制適用于 Azure SignalR 服務訊息：

  • 用戶端訊息：
    • 對於長時間輪詢或伺服器端事件，用戶端無法傳送大於 1 MB 的訊息。
    • 服務 WebSocket 沒有大小限制。
    • 應用程式伺服器可以設定用戶端訊息大小的限制。 預設值為 32 KB。 如需詳細資訊，請參閱 ASP.NET Core SignalR 中的安全性考慮。
    • 針對無伺服器，訊息大小會受限於上游實作，但建議使用低於 1 MB。
  • 伺服器訊息：
    • 伺服器訊息大小沒有限制，但建議使用低於 16 MB。
    • 應用程式伺服器可以設定用戶端訊息大小的限制。 預設值為 32 KB。 如需詳細資訊，請參閱 ASP.NET Core SignalR 中的安全性考慮。
    • 無伺服器：

對於 WebSocket 用戶端，大型訊息會分割成不超過 2 KB 且個別傳輸的較小訊息。 SDK 會處理訊息分割和組合。 不需要開發人員工作。

大型訊息會對傳訊效能造成負面影響。 盡可能使用較小的訊息，並測試以判斷每個使用案例的最佳訊息大小。

如何計算訊息以進行計費

傳送至服務的訊息是輸入訊息，而傳出服務的訊息是輸出訊息。 只有來自 Azure SignalR 服務的輸出訊息才會計入計費。 用戶端與伺服器之間的 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 服務和應用程式伺服器。
  • 用戶端連線 ：連線 Azure SignalR 服務和用戶端應用程式。
  • 診斷連線 ：特殊類型的用戶端連線，可產生更詳細的記錄檔，可能會影響效能。 這種用戶端是針對疑難排解而設計的。
  • 即時追蹤連線 ：連線即時追蹤端點，並接收 Azure SignalR 服務的即時追蹤。

即時追蹤連線不會計入用戶端連線或伺服器連線。

ASP.NET SignalR 會以不同的方式計算伺服器連線。 除了您定義的中樞之外，它還包含一個預設中樞。 根據預設，每個應用程式伺服器都需要五個以上的初始伺服器連線。 預設中樞的初始連線計數會與其他中樞保持一致。

服務和應用程式伺服器會持續同步處理線上狀態，並調整伺服器連線，以取得更佳的效能和服務穩定性。 因此，您可能會在執行中的服務中看到伺服器連線數目的變更。