I'm a part of building a service controlling Ev Charging Stations. The protocol is called OCPP and the underlying transport protocol is web sockets.
The stations are calling the host and the web socket is then being upheld, both server and client are initiating commands.
We have implemented the protocol and all that, the question we're looking into is how do we scale and host the web sockets (pressure load of with queue, etc is not the question).
We're currently on Azure and we have in our prototypes used Azure App Service which works fine, however, we have presently not looked into the limitations when it comes to scaling.
We have looked at Azure Pub Sub, however, it doesn't seem compatible with OCPP.
The question is what type of hosting we should look for to host the web sockets?
The documentation says that the number of Websockets is unlimited starting with the Standard plan but take a good look at the side note:
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).
Related
I'm trying to find the optimal cloud architecture to host a software on Microsoft Azure.
The scenario is the following:
A (containerised) REST API is exposed to the users through which they can submit POST and GET requests. POST requests trigger a backend that needs a robust configuration to operate properly and GET requests are sent to fetch the result of the backend, if any. This component of the solution is currently hosted on an Azure Web App Service which does the job perfectly.
The (containerised) backend (triggered by POST requests) perform heavy calculations during a short amount of time (typically 5-10 minutes are allotted for the calculation). This backend needs (at least) 4 cores and 16 Gb RAM, but the more the better.
The current configuration consists in the backend hosted together with the REST API on the App Service with a plan that accommodates the backend's requirements. This is clearly not very cost-efficient, as the backend is idle ~90% of the time. On top of that it's not really scalable despite an automatic scaling rule to spawn new instances based on the CPU use: it's indeed possible that if several POST requests come at the same time, they are handled by the same instance and make it crash due to a lack of memory.
Azure Functions doesn't seem to be an option: the serverless (consumption plan) solution they propose is restricted to 1.5 Gb RAM and doesn't have Docker support.
Azure Container Instances neither, because first the max number of CPUs is 4 (which is really few for the needs here, although acceptable) and second there are cold starts of approximately 2 minutes (I imagine due to the creation of the container group, pull of the image, and so on). Despite the process is async from a user perspective, a high latency is not allowed as the result is expected within 5-10 minutes, so cold starts are a problem.
Azure Batch, which at first glance appears to be a perfect fit (beefy configurations available, made for hpc, cost effective, made for time limited tasks, ...) seems to be slow too (it takes a couple of minutes to create a pool and jobs don't run immediately when submitted).
Do you have any idea what I could use?
Thanks in advance!
Azure Functions
You could look at Azure Functions Elastic Premium plan. EP3 has 4 cores, 14GB of RAM and 250GB of storage.
Premium plan hosting provides the following benefits to your functions:
Avoid cold starts with perpetually warm instances
Virtual network connectivity.
Unlimited execution duration, with 60 minutes guaranteed.
Premium instance sizes: one core, two core, and four core instances.
More predictable pricing, compared with the Consumption plan.
High-density app allocation for plans with multiple function apps.
https://learn.microsoft.com/en-us/azure/azure-functions/functions-premium-plan?tabs=portal
Batch Considerations
When designing an application that uses Batch, you must consider the possibility of Batch not being available in a region. It's possible to encounter a rare situation where there is a problem with the region as a whole, the entire Batch service in the region, or your specific Batch account.
If the application or solution using Batch always needs to be available, then it should be designed to either failover to another region or always have the workload split between two or more regions. Both approaches require at least two Batch accounts, with each account located in a different region.
https://learn.microsoft.com/en-us/azure/batch/high-availability-disaster-recovery
So I've been going through Azure Signal R Service for blazor apps and I've noticed they have their pricing according to units as well. The free version allows up to one unit where as the standard version has up to 100 units. I'm currently clueless as to what a "Unit" is, with this regard so it would be nice if someone would be kind enough to give a brief explanation on this. P.s: I am relatively new to Blazor however I have experience with .Net Core & Asp.Net Mvc .
A unit is a sub-instance that processes your SignalR messages. Units are used to increase the performance and connections count.
An instance is what you need to create first to use SignalR.
Think unit this way: Let’s say you have a web server that is not enough to handle the web traffic. You can add two more servers to load balance the traffic. This increases the performance and number of requests your environment can handle. In this example, the environment is an INSTANCE. Each server is a UNIT. Before adding new servers, you have 1 instance and 1 unit in that instance. After adding new servers, you have 1 instance and 3 units in that instance.
SignalR Pricing
In FREE plan, you can use only 1 unit and this unit can handle maximum 20 concurrent connections
In STANDARD plan, you can use 100 units. Each unit can handle 1,000 concurrent connections
(Please note the difference: The unit in FREE plan supports maximum 20 connections while a unit in STANDARD plan supports 1,000 connections. In terms of pricing, FREE plan unit and STANDARD plan unit are not the same)
Source: What is the difference between SignalR unit and instance? How SignalR pricing works?
Azure SignalR Unit has to be thought as a nodes available for processing messages for you app.
As you can see on the screenshot below, you can only select multiple units when using the "Standard" pricing tier (the free tier only allows one Unit with limited throughput).
When you select the Standard tier, you can then add up to 100 Units, which theoretically can allow you to
handle 1000 connections per Unit (with 100 Units, then 100,000 connections),
manage 1 million messages per day (with 100 Units, then 100 million connections).
You can scale up to you needs anytime, all depends on your app!
We've updated from Basic to Standard for our two instance App Service apps, and I'm getting this warning:
Based on this the Standard plan should have unlimited websocket?
https://azure.microsoft.com/en-us/documentation/articles/azure-subscription-service-limits/#app-service-limits
What is the meaning of this?
Unlimited in this case means that there is not going to be any artificial throttling of your site. However, a physical machine is only capable of handling a certain number of sockets before it runs out, and at the end of the day every instance of your site is running on just that, a physical machine.
If you're running out of sockets either try scaling out your site to multiple instances or better yet take a closer look at your application to see if there are ways to reduce the number of sockets simultaneously in use.
I currently have a web application deployed to "Web Sites" - This is configured in standard mode and it performs really well from what I have seen so far.
I have a few questions:
1)My instance size is currently small - however I can scale out to 10 instances. Does this also mean that if I change my instance size to medium or large, I can still have 10 instances?
2)What is the maximum number of instances I can have for an azure web site?
3)Is there any SLA for a single azure instance?
4)Is it possible to change the instance size programatically or is better to just change the instance count
1) Yes
2) 10 for standard.
3) Yes, for Websites Basic and Standard, MS guarantee a 99.9% monthly availability.
4) It depends on a lot of factors. The real question is "Is it better for your app to scale up or scale out?"
Yes, the default limit is 10 instances regardless of the size.
The default limit is 10 instances, but you can contact Azure Support to have the limit increased. Default and "real" limits for Azure services are documented here.
According to the Websites pricing page Free and Shared sites have no SLA and Basic and Standard sites have 99.9% uptime SLA. Having a single instance means that during the 0.1% outage time (43.8 minutes per month) your site will be down. If you have multiple instances then most likely at least one will be up at any given time.
Typically instance auto-scaling is used to handle variation in demand while instance size would be used for application performance. If you only get 100 requests per day but each request is slow because it's maxing out CPU then adding more instances won't help you. Likewise if you're getting millions of requests that are being processed quickly but the volume is maxing out your resources then adding more instances is probably the better solution.
I have a WCF service that receives requests from a Sivlerlight client, it reads or writes to a SQL database and then it sends the response back to the client.
With 6 or 7 clients delay starts to increase and I would like to check if the more instances I have, the lesser delay (because of load balancing).
I am trying to implement the autoscaling application block but the rules for storage (such as queue lenght) or CPU usage aren't useful for me because I don't use a storage account and although I have 10 clients connected to the service, the instance CPU usage barely reaches 10%.
How could I set a rule to start a new instance when a certain number of connections is reached?
You can capture IIS's Requests Current performance counter and send it to Windows Azure Diagnostics.
I'm fairly certain that WASABi can scale your WCF/WebRole application based on any performance counter. If for some reason WASABi cannot auto-scale you based on that performance counter or you need more features later, you can try AzureWatch (personal plug)
But either way, ASP.NET\Requests Current (if you're using IIS to hose your WCF) seems like the performance counter you need.