このブログでも扱いましたが、Windows Azure Web サイトの WebSocket サポートはインスタンスモードによって同時接続数に上限が設定されています。
この上限ですが、超えた場合には 503 が返るとありますが、アプリケーションで WebSocket を使っている時に突然死するのは避けたいですね。
とりあえずは、実際に SignalR のサンプルアプリケーションを無料モードの Web サイトへデプロイして、上限を超えた時の挙動を確認してみました。サンプルアプリケーションは NuGet で公開されている、公式のものをそのまま使いました。
Install-Package Microsoft.AspNet.SignalR.Sample
Web サイトへデプロイを行い、ブラウザで複数ページを開くことで接続を確立させます。
1-5 接続目までは 101 Switching Protocols が返ってきており、WebSocket への切り替えに成功しています。
そして 6 接続目からは先程の記事に書いてある通り、503 が返るので WebSocket への切り替えに失敗しているようです。
しかし、SignalR のサンプルアプリケーションは正常に動作します。通信を確認すると、WebSocket の確立に失敗した後に Server-Sent Event での接続を確立し、そのままアプリケーションは処理を続けていました。
つまり、SignalR を使っている限りは同時接続数の上限をあまり考える必要は無さそうです。ただし、クロスドメイン通信が必要な部分では、SignalR 側で CORS と JSONP の設定を適切に行っておかないと、WebSocket の時だけ接続出来てしまうことになります。
これは同時接続数が増えないと表に出てこないので、開発中は動くのに本番では動かないという厄介なバグになってしまいそうです。
ちなみに環境変数から、現在の Web サイトに設定されている WebSocket 同時接続数の上限を取得することが出来ます
// WebSocket の同時接続数上限を取得 Environment.GetEnvironmentVariable("WEBSOCKET_CONCURRENT_REQUEST_LIMIT")
Web サイトの環境変数からはいろいろな情報を取れるので、暇な人は Kudu の Runtime Environment を確認してみると面白いかもしれません。
