is it possible to turn off an azure media services end-point when idle, and turn it on again by demand (either by ways of configuration or programmatically?)
the purpose of this being saving costs on the end-point when not used.
There are several billing meters which apply for azure media services See https://azure.microsoft.com/en-us/pricing/details/media-services/ for all details.
Main price components:
Storage - you are paying based on how many space consumed by your assets. You can delete assets which are you no longer planning to use to avoid extra charges.
Encoding without reserved units - usage charges based on size of processed data. Your are not paying if system is in idle state.
Encoding with reserved Units - Same as #2 plus you are paying for allocation of resources.Reserved units help you to encode multiple jobs in a same time. Use portal to increase/decrease number of reserved units or REST/API, Client SDK to configure this parameter - https://msdn.microsoft.com/en-US/library/azure/dn859236.aspx#update_EncodingReservedUnitType
Live channels - For all live channel types, billing is based on the amount of time the channel is in running state and not based on the incoming and processed data. You can stop or delete channel to avoid incurring charges. See https://msdn.microsoft.com/en-us/library/azure/dn783458.aspx#stop_channels
Streaming units - Provides dedicated bandwidth capacity for both on-demand and live streaming. Pricing per unit. You can start/stop/scale streaming endpoint through portal or rest api - see https://msdn.microsoft.com/en-us/library/azure/dn783468.aspx
Content Protection - charges based on licences/keys issued through a service.
Related
I see strange requests when uploading blobs to storage. The only methods I use is PutBlob and SetBlobTier. But metrics shows large amount of GetBlobProperties requests with time interval about 1 hour. It seems like Azure makes some extra requests for statistic purposes. It happens only when uploading process is running. At attached diagram you can see 4 peaks of GetBlobProperties requests.
Does anybody know what is it? Another question is, will I be billed for this requests?
Any API call is considered to be a transaction:
Transactions – Each individual Blob, Table and Queue REST request to the storage service is considered as a potential transaction for billing. Applications can then control their transaction costs by controlling how often and how many requests they send to the storage service. We analyze each request received and then classify it as billable or not billable based upon our ability to process the request and the request’s outcome.
For that specific transaction, my guess is you're using Blob Archive(correct me if i'm wrong), the prices are as below:
It will be considered as All other Operations(per 10,000) pricing.
What could be causing it?
Due to a bug in our system, some internal transactions are miscategorized as customer requests when blobs transition between cold and archive storage tiers. These unexpected transactions will also be visible in both Azure Monitor as well as Storage Analytics logging. We are working on a fix for this and will deploy it as soon as possible. We apologize for any inconvenience and confusion this may have caused.
I'm looking at high scale Azure table operations, and I am looking for documentation that describes the maxIOPS to expect from Azure instance sizes for Azure Web App, Function, etc.
The Web Roles and corresponding limitation is well documented. For example see this comment in the linked question
so, we ran our tests on different instance sizes and yes that makes a huge difference. at medium we get around 1200 writes per second, on extra large we get around 7200. We are looking at building a distributed read/write controller possibly using the dcache as the middle man. – JTtheGeek Aug 9 '13 at 22:39
Question
What is the corresponding limitation for the Web Apps (logic, mobile, etc) and Azure Table IOPS
According to the official document that total Request Rate (assuming 1 KB object size) per storage account Up to 20,000 IOPS, entities per second, or messages per second. We also can get the VM Max IOPS limitations from the Azure VM size document. Web Apps are based on service plan, in the service plan we could choose different price tiers that have different VM sizes. It maybe could use for reference. More Azure limitation please refer to Azure subscription and service limits, quotas, and constraints.
I'm a bit confused by Azure price calculator. In particular it doesn't explain the bandwidth pricing.
I'm considering Azure for a restful api that is going to use blobs for most data storage together with a sql server database for a subset that is easier to manage with a relational approach.
In this application a lot of data will enter the system through the ReST api, but a small fraction will be exposed to the clients (mainly as summary reports). Still the total bandwidth required should be in the order of 50 GiB/mo.
In the Azure's pricing page related to data transfer I see the pricing is only related to outgoing data, but I cannot figure how this relates to a ReST api that will be hosted in Azure App Service.
I mean, it could just mean that I'm going to pay for the bandwidth consumed by HTTPS responses (and not by HTTPS requests), but it seems a bit hard to estimate what this pricing is going to be.
Within a given region, there are no transfer costs at all. You mentioned using App Service, blobs, and SQL Database. As long as those services are within a single region, there are zero bandwidth costs as data flows between them and any other service within that region.
Bandwidth is billed specifically for outbound transfer. So, essentially you're metered for all data leaving a given region.
If you look at the page Data Transfers Pricing Details
Data Transfers refer to data moving in and out of Azure data centres other than those explicitly covered by the Content Delivery Network or ExpressRoute pricing.
Inbound data transfers
(i.e. data going into Azure data centres): Free
Outbound data transfer prices are set at a sliding scale depending on location and bandwidth used.
inbound traffic is free so the data coming in can be removed from the equation. Outbound is not free, and you saw the pricing page.
Data transfer is everything that is going out from every operation you execute.
And it is hard to estimate the traffic pricing - i would recommend to register the Azure trial and test it for a month and see how it is going. Because your data is not only what is returned, there is a lot of payloads coming with that.
But if you estimate 10 GB/month of outbound traffic, then it will start from $0.087 per GB starting from fifth GB (because first 5 are free). There are different regions described at the pricing page as well, so you should apply the pricing according to the region where your website is.
I need to design an AZURE architecture for a service. Some key features:
the user load can reach up to 50K requests per second
the architecture should be scalable
the service requires real time user notifications
some requests must be queued as there are limits for specific calls (user should know that an operation is pending)
global availability
My first idea is:
MVC as a client entry point (azure web site)
WEB API as a backend (azure web site)
Service Bus (for requests queueing)
Web Jobs (workers for queued requests)
Azure DB for data storage
SignalR hub for live notifications
Azure Traffic Manager
What do you think about the above? Any suggestions / best practices to make this highly scalable and available?
First of all, just to make sure: 50k requests per second? Are you sure that's not 50k concurrent users or some such? 50k/second is near Twitter volume. About a 1/10th of Google requests/sec volume - which is HUGE.
50k concurrent users usually translates to 500-600 requests/second (assuming 10 page views per 15-minute user session)
Now, onto your question:
I would reconsider using Azure Service Bus for such a high volume system and consider Event Hubs (as Panagiotis pointed out) or stick with a simpler but more scalable Azure Storage Queues for messaging. You will need to design out a queue strategy where-by you will spread messages across multiple queues to not overflow single queues that live in single storage partitions.
I would also consider Azure Web Roles instead of Azure Websites to host IIS and to run queue processing. Websites are limited to 10 servers only per load-balanced endpoint. There are also limitations on the number of cores. With requests of 50k/sec you'll need a decent amount of horse power to run thru queues and serve traffic and 10 servers might not be enough.
Which Azure DB are you referring to? Azure Document DB? SQL Azure DB?
The notification hub REST API documentation mentions a quota for notification hubs in a given namespace. I couldn't find on the documentation nor the pricing page what are the boundaries for the quota for each plan.
Empirically, i now know that on the free/basic tier the limit is 100 notification hubs per namespace.
The maximum number of resources of type NotificationHub has been reached or exceeded. Actual: 100, Max allowed: 100.
Can the quotas be raised? What are the costs?
My current system uses hubs for multitenancy and before jumping to refactor the architecture are there any limits not mentioned on the pricing page?
Do service bus have quotas on the number of namespaces?
Do registrations (devices) have quotas/rate limit for each notification hub?
Send operations:
To increase quotas and start using some advanced features you could
go https://manage.windowsazure.com, then pick any your Notification
Hub and set Basic or Standard pricing tire on the Scale tab. Basic is
$10 per month, Standard - $200. Note that pricing tire is actually
changed on namespace level and all quotas are enforced against
namespace.
Also if you try to call Send operations in parallel from several
senders then you would see that bandwidth is wider because requests
are very likely to be routed to different nodes.
Also if you are going to send a really big volume of notifications
and each notification is targeted to 1 or very few devices, then
write to support asking to enable Inbox for your namespace.
Other quotas:
At most 100 (by my best knowledge) namespaces per regular subscription, you can upgrade it to premium with no limit by writing to support.
At most 100 hubs per namespace, you can increase it by writing to support.
Number of devices is not actually limited, even for Free tire '500 active devices' limitation is not enforced... for now :)
Registration rate is limited, quotas start from 2000 per namespace per minute and depends on pricing tire.
Also:
Some official pricing details: http://azure.microsoft.com/en-us/pricing/details/notification-hubs/