I am using Azure SignalR service instance. SignalR service currently only supports 1000 concurrent connections per service instance per unit. If the number of concurrent SignalR connections exceed 1000, the service instances will have to be increased manually, and reduced manually as the users decrease.
Looking for a suitable solution to auto-scale (scale up and scale down) the SignalR service instances based on the demand.
If any idea, please share. Thanks.
Azure SignalR service doesn't support any auto-scaling capabilities out of the box.
If you want to automatically increase or decrease the number of units based on the current number of concurrent connections, you will have to implement your own solution. You may for example try to do this using a Logic App as suggested here.
The common approach is otherwise to increase the number of units manually using the portal, the REST API or the Azure CLI.
They solved the disconnection issue when scaling, according to https://github.com/Azure/azure-signalr/issues/1096#issuecomment-878387639
And for the auto-scaling feature they are working on it, and in the mean-time here are 2 ways of doing so:
Using Powershell function https://gist.github.com/mattbrailsford/84d23e03cd18c7b657e1ce755a36483d
Using Logic App https://staffordwilliams.com/blog/2019/07/13/auto-scaling-signalr-service-with-logic-apps/
Azure SignalR Service supports autoscale as of 2022 if you select premium pricing tear.
Go to Scale up on the SignalR Service and select Premium pricing
tear.
Go to Scale out and create a custom autoscale.
The examples says that you can scale up if the metric "Connection Quota Utilization" is over 70% (should be about 700 out of your 1000 connections for your first unit). You can also scale down with a similar rule. The examples says to scale down when the connection quota is under 20%.
20% from the example seems a bit restrictive, but I guess its to avoid unneeded scaling. The client connections should be closed and reconnected while scaling down, so doing so very frequently is probably a bad idea.
https://learn.microsoft.com/en-us/azure/azure-signalr/signalr-howto-scale-autoscale
Related
I have a durable function app to handle xml file in blob which size is between a few megabytes and hundreds of megabytes.
The requirement requires up to 20 files to be process at the same time.
I've scaled out the durable function app to 4 instances, but when requests increase rapidly, only 2 instances encountered the problem of too high CPU, while the other 2 did not.
This results in very slow file processing.
Is there a problem with azure's built-in load balance?
See this picture to check the high CPU issue
Generally, the scaling logic in Azure Functions currently works well when the function is triggered by things like queues or Event Hubs.
if you're running your Function in an App Service (also known as a Dedicated Plan), it will by default only scale instances within the possibilities of the App Service Plan you defined.
Using an App Service plan, you can manually scale out by adding more VM instances. You can also enable autoscale, though autoscale will be slower than the elastic scale of the Premium plan. [...] You can also scale up by choosing a different App Service plan.
If you run your Function App on Consumption Plan (the true serverless hosting plan option since it enables scaling to zero)
For further information check the below provided links.
Azure Functions Scalability Issue.
Azure Functions Hosting Plan.
Consumption Plan Scaling Issues.
Actually I am getting System.OutOfMemoryException for blob trigger azure function.Do i need to scale up or Scale out App Service Plan to fix this problem.
What is the difference between these two?
For your original question, if your function is running on consumption plan, Scale up App Service Plan of your Azure service.The plan you already have less Memory and if you have multiple functions running in App Service Plan then scale out.
From the docs,
Scale up means :
A scale up operation is the Azure Web Sites cloud equivalent of moving
your non-cloud web site to a bigger physical server. So, scale up
operations are useful to consider when your site is hitting a quota,
signaling that you are outgrowing your existing mode or options. In
addition, scaling up can be done on virtually any site without
worrying about the implications of multi-instances data consistency.
Two examples of scale up operations in Windows Azure Web Sites are:
Scale Out means:
A scale out operation is the equivalent of creating multiple copies of
your web site and adding a load balancer to distribute the demand
between them. When you scale out a web site in Windows Azure Web Sites
there is no need to configure load balancing separately since this is
already provided by the platform.
Digram depicting the difference between the two :
You need to scale up your app service plan.
"Scale up" means upgrade the capacity of the host where the app is hosted. Ex: Increase the memory from 1.75GB to 3.5GB.
"Scale out" means upgrade the capacity of the app by increasing the number of host instances.
In Short Scale Up is vertical scaling, where you add more resources to increase capacity of the underlaying Hardware/Infrastructure.
Where, Scale Out is horizontal scaling, where you add more instance of the same app to process/handle request simultaneously.
If you choose Scale Out, you will get more VMs and balance your workloads to those VMs. If you choose Scale Up, your VM will get more punch to handle current workloads. More VMs or more power to your current VM
I have a question with a decision a previously employed architect has made in our deployment plan.
Currently our software has allot of outbound connections. In order to support the load (which is not too impressive to be fair) it has been chosen to have 1 app service plan, with 2 app services that are each filled to the max with webjobs of the same application that simply reads blob storage and posts the content to both the same and different endpoints. Each webjob is configured to post to a particular endpoint which can be the same as another.
Now I do not have much experience with azure, so I do not know if there is a particular limitation in the way webjobs are hosted that this solves.
I wish to simplify this deployment plan by simply reducing the amount of webjobs back to one and make it run multithreaded.
But I'm a little worried that by doing so, I am limiting the amount of connections possible from that webjob to both the same endpoint and in total.
Does anyone have experience with this?
Thanks in advance
I think (the information in) articles like this one might have had something to do with that choice: Starving outgoing connections on Windows Azure Web Sites. Please be advised this is a relatively old article.
A lot has changed since, although there still are some limitations: App Service limits.
IP Connections for...
Free: 600
Shared: 600
Basic: Depends on instance size
Standard: Depends on instance size
Premium (v2): Depends on instance size
Isolated: 16,000
The maximum IP connections are per instance and depend on the instance size:
- 1,920 per B1/S1/P1V2 instance
- 3,968 per B2/S2/P2V2 instance
- 8,064 per B3/S3/P3V2 instance.
Context: I am designing the auto-scaling (scale out) configuration for my .NET Framework 4.7 web app hosted on a Microsoft Azure App Service. I am using the P3V2 pricing tier. The application is CPU-bound. The app's 30 day CPU average is 30% usage while running on 2 instances, according to the stats indicated in the App Service plan. We occasionally have traffic spikes which will overwhelm the 2 instances: I want to implement auto-scaling.
I want to take into account the App Service Provisioning + App Startup Time when designing the metrics thresholds that decide when my app service scales out. I need to make my thresholds low enough to give Azure time to spin up a new app service instance but not so low that I am paying unnecessarily for processing power that's not needed. Budget is a significant factor.
Question: How long does it take for an Azure App Service instance to be available after a scale out? In other words, how long does it take for an Azure App Service to scale out?
P.S. I recognize that there is a lot more to scaling in/out that I am not addressing here. I'm trying my best to be succinct. :)
Generally, not long at all. By that I mean typically under one minute, but the time will vary depending on several factors, such as application size, time of day, region of deployment.
You could scale out manually and inspect the run history logs on the scale out tab.
FYI you can also use Azure Monitor to create auto-scale policies, in case this is of any use to you.
Hi I have a web app deployed as a Cloud Service on Windows Azure. Now I am performing some load/stress test against this app. In the Azure Management Portal I have configured the web role to scale automatically when the CPU goes over 40%.
I start the tests with only one instance of this web role. As the test progresses, I have set the number of concurrent users to increase over time up to 2000 users.
After I start the test, I connect via remote desktop to the web role instance on Azure and I monitor the CPU usage. After 10 mins or so, the CPU is constantly at 100% (and in fact my requests in the test take a very long time to complete) but if I check the CPU of the very same web role on the Azure management portal it says 1, 2 or 6, there was a peak of 70% but it sunk back immediately (but never the values I see in its task manager when I am connected in remote desktop) or even does not display any value (I go to the dashboard page of my cloud service), which means the graph is not updated any more.
Furthermore, and this is the point of my question, NO SCALING of the web role instances is performed whatsoever.
Any ideas where/what I am missing? Feel free to ask if my explanation is incomplete.
Autoscaling on the CPU metric for a Cloud Service or Virtual Machine doesn't occur as fast as you are expecting (~10+ minutes). In this scenario, the CPU metric is averaged across all instances of the services for a period of 1 hour. Therefore, your autoscaling actions will not be immediate.
You can read more about this and some recommendations for configuring your autoscale settings here.
If you want to tighten this up a little more then take a look at this post where I show how to set the TimeWindow using the Monitoring Service Management Library. You may be able to get closer to what you want taking this approach.
A few things to consider:
1) As Rick pointed out, by default CPU is taken at an hour average
2) If you start at only 1 server, and then autoscale up to 2, your first server will get yanked out of load balancer during the scale operation. You should really always have a minimum of 2 servers at all time.
3) Feel free to check out AzureWatch (link in my profile).. it was designed to perform decently advanced scaling scenarios and allows you to configure scaling rules without touching APIs