Question 108180 in Azure Question posted in
The official documentation to get you started can be found here.

SignalR connection limits in Azure Web App

I’m using ASP.NET Core SignalR in one of my ASP.NET Core MVC applications (.NET 6) which is hosted on Azure as a web app.

I’m struggeling to find information on how many concurrent connections my web app can handle before SignalR can’t accept more connections.

I know that Azure provides a paid Azure SignalR service for which billing starts at 1000 concurrent connections. Does this indicate that my setup can only work with up to 1000 connections? So far, 400 concurrent connections have worked perfectly.

Tags:

3

Answers


  1. 0

    enter image description here

    • In Azure portal we have a Pricing tier and Features seems to be that is the maximum limit and we have a feature – Autoscale as per the below screenshot.

    enter image description here

    • As far as i know and as per the Azure Portal we can’t exceed more than 1000 connections, but if you want to have more you can raise a Azure feature request as well as Support ticket.
    Login or Signup to reply.
  2. 0

    There are a few variables in play here, so nobody can tell you "Above X connections in a self-hosted SignalR solution, you need to use a SignalR service." Depending on how your solution is provisioned, one component or another may be the limiting factor.

    For example, the App Service service limits show the maximum number of web sockets per Web App instance. For the Basic tier, it’s 350. When you need 351, your options are:

    • Scale up your App Service Plan to Standard or higher.
    • Add an additional instance and use a Redis or Service Bus backplane.
    • Use SignalR service.
    • Disable websockets from SignalR and rely on something like long polling, which is limited by server resources.

    After you go to the Standard service tier and scale out to multiple Web App instances, you can get pretty far hosting SignalR yourself. We’ve run over 5K concurrently connected clients this way with four Standard S3 instances. Four is a misleading number because we needed the horsepower for other portions of our app, not just SignalR.

    When hosting SignalR yourself, it imposes some constraints and there are various creative ways you can hang yourself. For example, using SignalR netcore, you’re required to have an ARR affinity token for a multi-instance environment. That sucks. And I once implemented tight polling reconnect after a connection was closed from the front end. It was fun when our servers went down for over two minutes, came back up, and we had a few thousand web browsers tight polling trying to reconnect. And in the standard tier Web App, it’s really hard to get a handle on just what percentage of memory and CPU multiple websocket connections are consuming.

    So after saying all of this, the answer is "it depends on a lot of things." Having done this both ways, I’d go ahead and use SignalR service.

    Login or Signup to reply.
  3. 0

    Firstly, I don’t think it’s right to try to calculate the limitation concurrent connections for azure app service. You used asp.net core Signalr and publish the app to azure app service without using Azure Signalr Service. So the limitation is based on azure app service. And we also know that asp.net core Signalr used websocket connections, so we should check the allowed Web sockets per instance value for the app service pricing tier. But, there’re also some other configurations:

    If you scale an app in the Basic tier to two instances, you have 350
    concurrent connections for each of the two instances. For Standard
    tier and above, there are no theoretical limits to web sockets, but
    other factors can limit the number of web sockets. For example,
    maximum concurrent requests allowed (defined by
    maxConcurrentRequestsPerCpu) are: 7,500 per small VM, 15,000 per
    medium VM (7,500 x 2 cores), and 75,000 per large VM (18,750 x 4
    cores).

    If there’re other azure web app in your app service, it will also influence the connection limitation, that why we always recommend putting Signalr app in a separate app service/server.

    By the way, even we can calculate a definite quantity for connection limitation, we can’t ignore the bandwidth limiatation, just imagining each signalr message has 1Mb in size.

    Another point, in this section:

    An app that uses SignalR needs to keep track of all its connections,
    which creates problems for a server farm. Add a server, and it gets
    new connections that the other servers don’t know about. For example,
    SignalR on each server in the following diagram is unaware of the
    connections on the other servers. When SignalR on one of the servers
    wants to send a message to all clients, the message only goes to the
    clients connected to that server.

    So when you choose to publish your .net 6 Signalr app to Azure web app, it is always recommended using Azure Signalr Service except your number of connections is small all the time and the message size is not "big" and your pricing tier is relatively high. Otherwise, even the connection counts don’t reach the limitaion, your app may also meet bandwidth performance issue.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search