I have 2 specific scenarios that I can't get out of head regarding billing of windows azure.
Scenario 1: If I have 1 instance of say (web role, or work role, or reserved web-site) that sat idle for say 5 hours (by idle i mean no requests or processing or anything at all) will be billed for it? Or am I billed only for when I have activity on it?
Scenario 2: Am I billed for the actual size of my database or the size I declared when Ii created it?
This is quite hard to follow up and i would like to thank everyone in advance. Microsoft site is quite unclear and not straightforward about it.
1) each instance is like renting a car. That capacity is reserved for you and you're charged if its parked in the driveway (stopped), being driven in a parade, or cruising down the freeway at 60mph
2) a bit of both. The web and business editions have a minimum size you'll be billed at. But if you declare say a 150gb business Db, but only use 8, you'll only be billed at 10gb (the minimum).
For scenario 1, you are billed based on if the machine is allocated. So if you setup the machine once and leave it running, as long as it is running you are being billed. If you are just having a single server that needs to be available 24/7 (even though it might only do work for very short periods during the day), you need to account for about 720 hours per month at the bill rate for that machine size.
For scenario 2, you are billed based on the usages with minimums at certain tiers. See this document for more info: http://www.windowsazure.com/en-us/pricing/details/#data-management/
Related
We run a web service that gets 6k+ requests per minute during peak hours and about 3k requests per minute during off hours. Lots of data feeds compiled from 3rd party web services and custom generated images. Our service and code is mature, we've been running this for years. A lot of work by good developers has gone into our service's code base.
We're migrating to Azure, and we're seeing some serious problems. For one, we are seeing our Premium P1 SQL Azure database routinely become unavailable for 1-2 full entire minutes. I'm sorry, but this seems absurd. How are we supposed to run a web service with requests waiting 2 minutes for access to our database? This is occurring several times a day. It occurs less after switching from Standard level to Premium level, but we're nowhere near our DB's DTU capacity and we're getting throttled hard far too often.
Our SQL Azure DB is Premium P1 and our load according to the new Azure portal is usually under 20% with a couple spikes each hour reaching 50-75%. Of course, we can't even trust Azure's portal metrics. The old portal gives us no data for our SQL, and the new portal is very obviously wrong at times (our DB was not down for 1/2 an hour, like the graph suggests, but it was down for more than 2 full minutes):
Azure reports the size of our DB at a little over 12GB (in our own SQL Server installation, the DB is under 1GB - that's another of many questions, why is it reported as 12GB on Azure?). We've done plenty of tuning over the years and have good indices.
Our service runs on two D4 cloud service instances. Our DB libraries are all implementing retry logic, waiting 2, 4, 8, 16, 32, and then 48 seconds before failing completely. Controllers are all async, most of our various external service calls are async. DB access is still largely synchronous but our heaviest queries are async. We heavily utilize in-memory and Redis caching. The most frequent use of our DB is 1-3 records inserted for each request (those tables are queried only once every 10 minutes to check error levels).
Aside from batching up those request logging inserts, there's really not much more give in our application's db access code. We're nowhere near our DTU allocation on this database, and the server our DB is on has like 2000 DTU's available to be allocated still. If we have to live with 1+ minute periods of unavailability every day, we're going to abandon Azure.
Is this the best we get?
Querying stats in the database seems to show we are nowhere near our resource limits. Also, on premium tier we should be guaranteed our DTU level second-by-second. But, again, we go more than an entire solid minute without being able to get a database connection. What is going on?
I can also say that after we experience one of these longer delays, our stats seem to reset. The above image was a couple minutes before a 1 min+ delay and this is a couple minutes after:
We have been in contact with Azure's technical staff and they confirm this is a bug in their platform that is causing our database to go through failover multiple times a day. They stated they will be deploying fixes starting this week and continuing over the next month.
Frankly, we're having trouble understanding how anyone can reliably run a web service on Azure. Our pool of Websites randomly goes down for a few minutes a few times a month, taking our public sites down. If our cloud service returns too many 500 responses something in front of it is cutting off all traffic and returning 502's (totally undocumented behavior as far as we can tell). SQL Azure has very limited performance and obviously isn't ready for prime time.
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.
We're trying to understand the intricacies of monitoring data that Windows Azure Management API returns for Azure Websites (not Webroles)
For example, the image below describes a data point retrieved for CPUTime. It appears to indicate that during the 10:00pm thru 10:39pm range, I've used up 3.171 seconds of CPU. Is this translatable to CPU utilization (in percentage form) that we're all accustomed to seeing in Perfmon?
Does this get reset every clock hour and what is TimeGrain?
Interestingly, the "Count" indicates "1" - which to me implies the number of measurements in the timeslot, but even after subsequent calls are issued to the API, the Count stays at 1 (however the Total value changes).
Ultimately the goal is to translate the captured metric to standard CPU utilization % that everyone is accustomed in seeing during Perfmon monitoring.
I'm guessing that two relatively close measurements need to be taken, the delta between measurements computed (in milliseconds) and divided by the total span between the measurements (in milliseconds) - in order to produce a percentage value. Is this correct?
Azure Web Sites in 'Free' and 'Shared' mode is running in multi-tenant environment. You can't translate CpuTime to CPU utilization % in this case. In case of Reserved mode it is technically possible, but this value is not currently exposed. Please also note, if you upgrade your web site to 'Reserved' mode all other web sites will be also upgraded and share same reserved instances.
I subscribed to free 90 days azure trail offered by MS. I was excited and talked about it everywhere(including my blog http://techibee.com/windows-2012/free-try-windows-server-2012-in-azure-for-90-days/1876) about the free service offered by MS and how to make use of it. Well, my excitement lasted only for 7-8 days. Today I got a message from Azure team that my subscription disabled as my computer hours exceed the monthly limit.
I am just wondering how these compute hours are calculated in my case. I configured 2 VMs(2 medium) and using them to explore stuff. I never shutdown them since creation. Anyone has idea how these two VMs constituted to limits.
Another question I have is, since the subscription is disabled for this month, I am considering purchasing few more compute hours(pay-as-you-go). If I do that now, should I shutdown the VMs when I am not using them actively? will it stop the compute hours from increasing or they will continue to charge me for even shutdown hours. All I want is, I should get billed only when I am actively using it, when I am not connected to that host, I shouldn't. Looks like this is not happened in the trail program and their calculations seems different. Can anyone here given me some clarity?
From http://www.windowsazure.com/en-us/pricing/details/#header-3
Compute hours are charged whenever the Virtual Machine is deployed,
irrespective of whether it is running or not.
That's where all your hours went. You need to delete your VMs to prevent them using compute time.
With the free trial account you can configure only 1 VMs medium. Probably your offered expired early becouse you configured two.
Be aware that if you create a VM and you turn it off you will be charged the same as indicated when your turn off a VM.
I'm an msdn subscriber and I'm looking at Azure as a possible platform for a new website that will test the water of a new service. This website is expecting low to very low traffic at the time of launch. I've heard that this kind of traffic levels is very expensive for Azure but since they have this msdn offer, I thought I'd finally take a look at Azure.
In the offer, I'm looking at getting "750 small compute hours per month". From the reading I've done, this seems that, if I purchase nothing more than what's given (although the subscription itself is thousands of dollars of course), that an entire month would be covered. Since 24 (hours) x 31 (max days in a month) = 744 I'm still below my allotted 750 for the month.
Am I missing something else from this simple equation? Is there further aspects that could cause the site to be "turned off" temporarily that should be considered?
Yes, you can indeed run a small instance during a whole month. Or you can have 2 extra-small instances instead (having 2 instances means you're covered by the SLA).
There are 2 other things you need to consider:
Depending on your subscription you can have maximum 45GB of storage (blob/table/queue). If you use Virtual Machines you need to know that the system disk (and additional data disks) are persisted as blobs, so make sure not to reach the limit here.
There are also other limits active, but the most important one besides storage is the data transfer limit which is also very limited (max 35GB out).
If you're expecting very low traffic, did you ever consider Windows Azure Web Sites? You get 10 of those for free during 12 months. The free ones run on shared instances, but they are perfect to host the first low-traffic version of your app.