I am experimenting with the Azure Computer Vision service and it is working well.
The only issue is that I want to be able to process 6,000 files relatively quick.
Now Azure imposes a 10-Transaction Per Second limit which is fine, but how can I scale the service?
I was thinking of spinning up multiple instances, but it seems like an ugly way to solve this issue.
Please let me know the best way to tackle this issue.
Thanks!
Please contact Azure support for scaling your Azure Computer Vision resource.
You can directly ask the support to have an upper limitation.
Submit a support request from Azure for that:
Related
I have managed to get the C# and db setup using ListMappings. However, when I try to deploy the split/merge tool to Azure cloud classic the service it states 'The requested VM tier is currently not available in East US for this subscription. Please try another tier or deploy to a different location.' We tried a few other regions with the same result. Do you know if there is a workaround or updated version? Is the split / merge service even still relevant? Has anyone got this service to run on Azure lately?
https://learn.microsoft.com/en-us/azure/azure-sql/database/elastic-scale-overview-split-and-merge
The answer to the question on whether it is still relevant, in my opinion is ...no. Split\merge is no longer relevant with the maturation of elastic pools. Elastic pools with one data base per tenant seem the sustainable way to implement multi tenancy with legacy code. The initial plan was to add keys to each of our tables to have multiple tenants per database. Elastic pools give us the same flexibility without having to make breaking changes our existing code.
Late post here, but we are implementing ElasticScale for a client to split ~50 clients into a database-per-tenant model. I don't think the SplitMerge tool will be used over the long term, just for the initial data migration from one db to many shards, but it has been handy for that purpose. We are using the ElasticScale SDK to allow a single API to route queries to the appropriate shard(s) based on sharding key. Happy to compare notes with you if you are still working on this.
We have been developing a RESTful web api using node and MongoDB. For hosting options, we decided to use Azure through BizSpark. We used DocumentDB with protocol support for MongoDB.
The problem now is DocumentDB is consuming all the credit causing a downtime and we haven't started making money yet. We are now considering switching from DocumentDB to MongoDB. The question now becomes, what is the cheapest way to host MongoDB on Azure?
So far on our research, we have found two options:
Using a VM (Linux or Windows)
Using a worker role
Please advice if there are other options, and how easy can it be to switch between these options at a later stage.
You can use the Azure calculator to get estimates between DocumentDB and a VM with the settings your company needs to see which one is cheaper.
If you are using Bizspark, remember that you have 5 accounts in which you can distribute all your costs to optimize in a better way.
Personal recommendations(subjective view):
Remember that if you are using the PAAS solution(DocumentDB) you
get full functionality out of the box, you don't have to set it up
and you can escale it very easily and plug in to very powerful tools
like PowerBi out of the box.
In the case of IAAS solution(vms) you have to install, mantain and
create all the connection settings for this to work. If you want to
scale you have to me more dedicated, since you have to scale it
through the use of more vms, traffic managers and more robust
architecture. If this is the path you are taking I would recommend
using containers like Docker inside the VM and their power to
manage this.
I split one Azure cloud service into multiple cloud services assuming this would help performance issues, but after I'm done with the implementations and I'm increasing the number of instances i.e. scaling up for every cloud service I'm still having performance worse than single cloud service. Scaling up doesn't seem to bring positive effect. I have different queues across every cloud service, that's one area I can think of causing this problem, but why scaling up doesn't work at all?
As other people noted there is not enough information in your email for us to help. One guide I can point you to for storage is a scalability and performance checklist which has some good tips in it. See here: https://azure.microsoft.com/en-us/documentation/articles/storage-performance-checklist/.
I am a newbie to web development
I would like to host my site in azure.
There are so many subscriptions plans.
So which subscription is reasonably good and give me price details of that?
Thanks in advance
Windows Azure has few types of hosting. For a website you might want to look at the following -
Web Sites - You can host right away without modification of your existing project.
Cloud Services - I used this, but it requires changes such as Caching.
Here is the calculator based on your need.
FYI: Rule of thumb is you need a least two instances in Production to minimize the downtime.
If you are a newbie , I would strongly suggest using azure websites for now, and you can always move to a custom solution using webroles/caching Etc later if you feel it doesn't cater all your needs..
Azure websites pricing can be obtained from here :
https://azure.microsoft.com/en-us/pricing/details/web-sites/
Again on what parameters would you choose the right package, you are the best judge for that since you know what traffic are you expecting and how much memory etc you need
We have got an application running fine on On premises and plan to move it to IaaS on Ms Azure, do we need to make any changes to it or will it work as is?
I agree with the above post. You have not detailed if you are using Virtual Machines (Sql server or going to use Azure SQL). You will have to make choices about fail-over and geo redundancy, cloud services, etc. There are IP restrictions that may affect you (I don't know since I am not sure what you are moving). More than anything, I always warn people about the cost, it is difficult to understand. Here is an article series I wrote on Azure & SharePoint, you can skip the SharePoint stuff but the cost/limitation/VMs and such would still apply.
http://www.matthewjbailey.com/sharepoint-azure-guide/
We've managed a lift-and-shift of an on-premise Windows app into Azure, but I wouldn't say it's been without its pain. The above comments definitely ring true; you need to provide a bit more of an overview of what the current application does so that people can help answer your question.
In my experience, the only stumbling blocks to moving on-premise into Azure are:
Hardware requirements; i.e. if your application requires some specific hardware
Cost: It's not always cheaper to move large systems into Azure
Licensing: Make sure that your existing licensing is compatible with a cloud system which you don't control