I have ASMX webservice with 1 MSSQL Database and a Single Table.
I have currently deployed it to Azure in the App Service
I have upgraded from Free Trial to Pay Per Use Plan.
I'm really confused with the App Service Plan
The ASMX Service is called by a Desktop application and it only has a few methods,just to fetch and return data from database.At max 100 users will be using it and may be a maximum of 1000 method calls may be made.
What does 60 minutes/day mean? The webservice can function for only 60 minutes?
I'm really confused.Please advice
Think of the minutes listed similar to a consumption plan on Azure Functions. When your website is responding to requests, it active and your "on the clock." When the site has been idle for a while, it will effectively go to sleep and you are "off the clock." Free and shared tiers are not "Always On". If your compute minute usage exceeds the quota (60 or 240 minutes), then Azure will return a 403 message to the browser and your site is unavailable until the quota resets for the next day. Free and Shared plans are really not designed for production. If you think you can squeeze your 1000 method calls into those time limits, great...it may be a cheaper solution. But you should expect the possibility of a 403 being returned and your request not being fulfilled. If your desktop app is important and really needs this service, you are probably better off paying for Basic (B1).
Related
I'm experiencing a really strange problem.
My API is taking a long time to response and I can't see why from AppInsights.
Attached is the end-to-end transaction view. It shows that the API call took 16.7 seconds. It's clear that a dependency call took 3.8 seconds. Some DB operation took several ms. But what's causing the long delay? What happened in the red rectangle marked with question mark?
The web app is hosted with a P1V2 app service plan. The plan is shared by 3 API apps. Could this be a problem?
The web app is hosted with a P1V2 app service plan. The plan is shared by 3 API apps. Could this be a problem?
No, that couldn't be the problem because the P1V2 app service plan is a premium service plan. We can reduce the cost consumption by combining multiple apps into a single app service plan. We can add multiple apps to an existing plan as long as the plan has enough resources.
Here are my few observations.
The P1-V2 service plan will have 3.5 GB of RAM and 1 VCore processor. We need to cross-check the utilization logs once.
APIs are calling token methods Get/msi/token, and there onwards it's forward to the PUT call on the portal; there it's taking close to 16 seconds.
The one mentioned in the red box is not an issue because it takes only 16 milliseconds to execute SQL.
Question regarding pricing tiers for Azure Sql database and if the cheapest plan ($4.90/month) offloads resources after a specific time period for non use.
If my Azure Sql Server database doesn't get queried for a specific period of time, ex. 30 minutes. Will Azure offload the resources for the database, until it gets a new request?
This would be similar to an app service running the basic (free) plan. After ~30 minutes the site resources get offloaded from memory (I think). So, when I go to the site, instead of loading up immediately, it takes about 5-10 seconds, then if I hit the site again, because it's loaded back into memory, it will load immediately.
Does this same thing happen with Sql Server running in Azure with the cheap $4.90/month plan? It seems like it does! If I don't hit my app service (website), now upgraded to the S1 plan so no offloading, and come back a day later and hit a page that has to fetch database results to display on the page, it will take approx. 5-10 seconds, but then if I refresh the page again or hit another page that needs to query the DB, the queried data comes back instantly!
No it should not do that. You reserve capacity in vCores or DTUs, and that is what you should get. But different management operations (like maintenance, capacity restructuring, moving workloads from faulty hardware) will evict your workload from the underlying host it is running on and spin it up on another hardware. It would be transparent to you if not for the flushed cache. Of course this should not happen every time your application goes idle, but can be the case from time to time.
If you are using DTU purchasing model, I would recommend switching to vCore based model as it's the recommended one. Then take a look at the CPU Used metric. As long as the line of the metric is continuous you have allocated CPU, when the line becomes dotted it indicates that the db is paused, but the dotted behavior should only apply for serverless.
You can set your Azure SQL Database as serverless. It is the only Azure SQL Database (PaaS) option that can be auto-paused after a specific time of inactivity has passed, the minimum time of inactivity is 1 hour. You also get billed by the minute instead of by the hour. Here you will find step-by-step tutorial how you create a serverless database.
Make sure you set the auto-pause delay setting.
I have 2 questions first related to hosting, second related to sdk/library to use:
I need to write a kind of work allocation service scheduler to people, which will run say every 1 hour to run compute intensive logic in background and push the results in our database. The input may be number of days to create schedule for, number of people available, count of tasks to be done. So primarily its compute intensive.
Should i host it in App Service or in Azure Function (TimerTrigger)? This scheduler run as total background job and never called from UI or any backend API.
If i go App service way i have choice of either Hangfire or WebJob. How should i decide which is good for me.
Certainly quick execution with lesser cost is my criteia to move ahead.
One consideration for Azure function is how long the processing will take. Azure functions have a maximum time limit that depends on hosting plan. When you create a function app in Azure, you must choose a hosting plan for your app. There are three hosting plans available for Azure Functions: Consumption plan, Premium plan, and Dedicated (App Service) plan. An overview of hosting plans and their timeout durations is here: Azure Functions scale and hosting.
Unlimited duration is in Premium plan or Dedicated plan (Unlimited execution duration - 60 minutes guaranteed).
Maximum duration for Consumption plan is 10 minutes.
I have several ASP.NET web apps running on an S1 instance. I also have a WordPress site running as well. They were all working fine. Suddenly I am getting "The service is unavailable" for every one of my web sites. (I have other site on the free F1 tier that are working fine.)
Has anyone else experienced this? Is this normal?
It seems that you've achieved your free quota. Check if the other web site are running in the same subscription, because as long as I know, when you reach the free quotas, all of your web sites will stop.
https://azure.microsoft.com/en-us/blog/bandwidth-quota-changes-to-the-free-offer-of-azure-app-service/
While Thiago's answer isn't directly correct for web apps running on an S1 instance, his answer is helpful for those on F1 instances.
The included bandwidth on F1 instances have a daily quota of 165 MB per day across all Web Apps (10 Max) per region. This is summed up to be 5GB of bandwidth per month per region. This quota is enforced on a daily basis and your Web Apps will be suspended for the reminder of the day if met.
Azure Subscription Limits
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