We have developed application using aspnetzero and have configured hangfire for background jobs. We use periodic jobs provided by aspnetzero framework and in memory cache.
We have certain background jobs which are heavy and at times CPU usage goes high (60%). To avoid impact on web users, we are thinking of using auto-scale option of azure app services.
I have found below few things that I need to consider when using auto-scale.
In memory cache
periodic background jobs
signal-r (chat and notification).
Can someone help me understand what is best to use in place of in memory cache, periodic jobs and signal-r service?
Has anybody used auto-scale for aspnetzero app?
Do I have to consider anything else when using auto-scale option?
Thanks.
Related
I'm interested in deploying CPU intensive web app to an Azure App Service instance. I can't find any details around CPU usage and/or limits for Azure app service. My concern is that not having insight into the CPU specs/limitations for my app will not allow me to plan on how to accurately plan the physical cloud-based infrastructure (using Azure app service).
My app will be using the OpenCV computer vision library to do heavy image processing, face detection, and face recognition with hundreds/thousands of high quality images. This is naturally a CPU-intensive process. In a traditional setting (or on-premise Virtual Machine setup), I would at least know the specs on the machine (I.E. cpu specs, etc).
In summary, my question is two-fold:
1) Why doesn't azure app service say anything about the CPUs inside of their PaaS (App Service) context? If they do, where can i learn more about CPU limitations for this?
2) In the context of my application, is my CPU-based question irrelevant? I do read online that certain Azure App Service tiers do auto-scaling (meaning load balancing across more servers for better performance). Will this be sufficient for my need where multiple end-users are processing many photos to do face detection and recognition?
Microsoft represent the performance of the a VM in terms of ACU (https://learn.microsoft.com/en-us/azure/virtual-machines/windows/acu). There are limited number of VM's Available in Azure App Service plan.
App Service plan has both scale up and scale out option. Scale out can be done based on the different rules.
But always do remember that the application architecture will dictate how it will use the scale out option.
Note : I would suggest to use VM if it GPU or CPU intensive, as you will get more option.
As i know standard app service are running on A Series VM but based on the scenario that you explained i suggest you to go with Premium App Service Plan that runs on Dv2 VM's. Hope below article will help you out:
I Suggest you to check the app service overview link and it says what kind of VM is running on back end so you can cross check with the VM specs and you can find the CPU details there.
App Service Plan Overview
App Service Limitation
App Service Overview
I am using Azure Function app service plan to serve client requests. Reason for selecting Azure service plan is, requests are long-running and takes more than 10 minutes.
I am looking for implementing Azure architecture which will be cost-effective and perform better for a large number of requests.
Any suggestions on what Azure components I can use or what architecture I should follow.
More details and characteristics about the workload are really necessary to offer up any solid suggestions (e.g. is it memory, cpu intensive? Is it dependent on downstream resources etc). Depending on your workload Functions and\or App Services may not be a right fit.
At a high level consider if refactoring this 10 minute process is an option. Many times long running tasks are in actuality many smaller tasks that can be broken down so their individual execution times are reasonable and you can then make use of the scaling aspects of Serverless (Azure Functions). If this is the case but breaking it down is too complex to orchestrate consider using something like Durable Functions or Logic Apps to provide that orchestration for you.
Generally speaking if I have long running requests it typically means its async from a user perspective and latency isn't an issue so another option is to have an Http Trigger (API) on an Azure Function running on a consumption plan so it will scale as needed and that accepts the request and places it on a queue but the queue listener is on dedicated compute without time restrictions (e.g. Function on App Service Plan, Azure Container Instances, etc). Keep in mind you need to be careful about your queue length as you could get lots of requests in your queue but only limited resources to process them on your dedicated compute within an acceptable time frame.
At the end of the day though "cost effective" AND "performant" is often a tough ask (outside Serverless) and my suggestion is to refactor your workload if you can.
I am writing an Azure hosted MVC website for a gym booking system. I need to be able to maintain membership expiry, suspensions as well as gym class attendence (i.e. logging to the database if a session has been missed). Each of these tasks requires a "c# service function" to be run that will go through the database, perform some checks and update records as and when required.
I need this to run pretty regularly to ensure that missed sessions are logged asap. Should I be developing this as an Azure WebJob and running it continuously? Should i be doing it in another manner? If I could get some suggestions on routes to take that would be massively appreciated.
Thanks
You have a few options: Web Jobs, Scheduler, and Worker Roles.
Web Jobs are a nice addon to an existing azure web app and have the benefit of no additional cost. Web Jobs use Scheduler under the covers if you choose to schedule the Web Job to run at an interval other than continuously. Here is a nice answer that describes the differences between the two.
Worker Roles would be the next logical step up from a Web Job. Worker Roles are dedicated Cloud Service VMs that can provide more dedicated power and offer greater scaling capabilities. Worker Roles can also do much more than just run jobs.
For the application you have described, if you are already running on Azure App Services (Web App) it sounds like a continuously running Web Job would be the correct choice.
I'm trying to figure out a solution for recurring data aggregation of several thousand remote XML and JSON data files, by using Azure queues and WebJobs to fetch the data.
Basically, an input endpoint URL of some sort would be called (with a data URL as parameter) on an Azure website/app. It should trigger a WebJobs background job (or can it continuously running and checking the queue periodically for new work), fetch the data URL and then callback an external endpoint URL on completion.
Now the main concern is the volume and its performance/scaling/pricing overhead. There will be around 10,000 URLs to be fetched every 10-60 minutes (most URLs will be fetched once every 60 minutes). With regards to this scenario of recurring high-volume background jobs, I have a couple of questions:
Is Azure WebJobs (or Workers?) the right option for background processing at this volume, and be able to scale accordingly?
For this sort of volume, which Azure website tier will be most suitable (comparison at http://azure.microsoft.com/en-us/pricing/details/app-service/)? Or would only a Cloud or VM(s) work at this scale?
Any suggestions or tips are appreciated.
Yes, Azure WebJobs is an ideal solution to this. Azure WebJobs will scale with your Web App (formerly Websites). So, if you increase your web app instances, you will also increase your web job instances. There are ways to prevent this but that's the default behavior. You could also setup autoscale to automatically scale your web app based on CPU or other performance rules you specify.
It is also possible to scale your web job independently of your web front end (WFE) by deploying the web job to a web app separate from the web app where your WFE is deployed. This has the benefit of not taking up machine resources (CPU, RAM) that your WFE is using while giving you flexibility to scale your web job instances to the appropriate level. Not saying this is what you should do. You will have to do some load testing to determine if this strategy is right (or necessary) for your situation.
You should consider at least the Basic tier for your web app. That would allow you to scale out to 3 instances if you needed to and also removes the CPU and Network I/O limits that the Free and Shared plans have.
As for the queue, I would definitely suggest using the WebJobs SDK and let the JobHost (from the SDK) invoke your web job function for you instead of polling the queue. This is a really slick solution and frees you from having to write the infrastructure code to retrieve messages from the queue, manage message visibility, delete the message, etc. For a working example of this and a quick start on building your web job like this, take a look at the sample code the Azure WebJobs SDK Queues template punches out for you.
From what I understand both run small repeatable tasks in the cloud.
What reasons and in what situations might I want to choose one over the other?
Some basic information:
WebJobs are good for lightweight work items that don't need any customization of the environment they run in and don't consume very much resources. They are also really good for tasks that only need to be run periodically, scheduled, or triggered. They are cheap and easy to setup/run. They run in the context of your Website which means you get the same environment that your Website runs in, and any resources they use are resources that your Website can't use.
Worker Roles are good for more resource intensive workloads or if you need to modify the environment where they are running (ie. a particular .NET framework version or something installed into the OS). Worker Roles are more expensive and slightly more difficult to setup and run, but they offer significantly more power.
In general I would start with WebJobs and then move to Worker Roles if you find that your workload requires more than WebJobs can offer.
If we are to measure "power" as computational power, then in a virtual environment, this translates to how many layers are on top of the physical machine (the metal). The user code on a virtual machine runs on top of a hypervisor, which manages the physical machine. This is the thickest layer. Whenever possible the hypervisor tries to simply serve as a pass-through to the metal.
There is fundamentally little overhead for WebJobs. It is sandboxed, OS is maintained, and there are services & modules to make sure it runs. But the application code is essentially as close to the metal as in Worker Roles, since they use the same hypervisor.
If what you want to measure is "flexibility", then use Worker Roles, since it is not managed or sandboxed, it is more flexible. You are able to use more sockets, define your own environment, install more packages, etc.
If what you want is "features", then WebJobs has a full array of features. Including, virtual-networking to on-prem resources, staging environments, remote debugging, triggering, scheduling, easy connection to storage and service bus, etc...
Most people want to focus on solving their problem, and not invest time in infrastructure. For that, you use WebJobs. If you do find that you need more flexibility, or the security sandbox is preventing you from doing something that can't be accomplished any other way, then move to Worker Roles.
It is even possible to build hybrid solutions where some parts are done in WebJobs and others are done in Worker Roles, but that's out of the scope of this question. (hint: WebJobs SDK)
Somethings to remember when choosing to use a Web Job or a Worker Role:
A Worker Role is self hosted on a dedicated VM, a Web Job is hosted in a Web App container.
A Worker Role will scale independently, a Web Job will scale along with the Web App container.
Web Jobs are perfect for polling RSS feeds, checking for and processing messages and for sending notifications, they are lightweight and cheaper than Worker Roles but are less powerful.