问题
I have one REST API through which i am allowing to user applications(azure app) to send perfmon data to my DB. Now to load test this REST API I had built one simulator application of 500 webrole with 10 instances of each(total 5000 instances) and every 1 min 50000 (approx) requests are going to post data to REST API and so i require to scale my REST API with best practices to handle this much load.
Following are my test cases to scale REST API
Medium - 6 Instances => can handle 300 instances's requests
Extra large - 2 instance => can handle 300 instances's requests
Now my question is this type of load can be handle with horizontal scaling or with vertical scaling? means should i need to increase no of instances with medium size or small size or i have to go with extra large size instance?
Also this REST API is going to post data SQL Azure database (5 gb web edition) so is there any limitation regarding to handle requests?
on above case all applications consider in same region
回答1:
Your 6 medium instances = 12 cores, while 2 XL instances = 16 cores. Pricewise, it is better yo use 6 mediums, and not 2 XLs.
Plus, if you scale dynamically, with XL you can only scale by 8 cores, while with medium you can scale by 2 cores. I would use Medium instances, even small if possible. And will target horizontal scaling (a.k.a scale out) - increasing/decreasing number of instances.
I would also consider some kind of buffering data before sending to SQL, and not directly communicate with Windows Azure SQL Database (WASD). With this type of load it is verry likely that every second hit to WASD is going to meet transient error due to heavy load. Consider buffering data into Queue (either Azure Storage Queue, or Azure Service Bus Queue) and having a Worker role (possibly with multiple instances), processing the queue messages in batches.
This type scale is very likely to be more responsive and reliable in CQRS pattern. You can look at the CQRS Journey Project for more info and reference implementation on the CQRS and Windows Azure.
回答2:
This was a comment but I ran out of room.
If you are designing for speed and scale of a REST API to receive the PERFMON data then why would you slow API down with a call to SQL rather than a call to a QUEUE?
If SQL can't keep up processing a single queue then SQL will also not be able to keep up with calls from 6 REST services. In the end SQL insert is limited by disk IO. If designed properly a single process can send data to SQL as fast as SQL can take it.
50,000 inserts a minute is a lot so look at how you design the index and how design the insert. For sure you don't want a index that will fragment. If the raw data has a sequential key then can use that as the PK. Otherwise use Iden as the PK.
If you batch up the inserts you can increase throughput. Batching does not necessary increase latency. If it ready for the next insert and there is only one in the queue then insert a batch of 1. There will be a sweet spot for inserts (like 100 - 1000).
What I do is build up the insert in the foreground and then insert asynch. If you can build the insert faster than the asynch insert then SQL is fully loaded. Since you are building the syntax in memory and inserting to disk building the syntax will be faster unless you have some complex processing to build the syntax. Yes look to federated to split up the disk IO but start with optimizing that insert. Drapper is popular. I often use table value parameters. insert into table values() is not going to be the fastest option but it may keep up with 50,000 / minute.
Protect the REST API with a queue. Then optimize processing that queue.
I would say Azure Table Storage but it is limited to 5,000 entities per second total and 500 entities / second / partition. With those throughput limits I don't think you can call ATS highly scalable.
回答3:
It seems that this a more an issue of scaling out storage and that you want to be as near real time as possible.
In which case if SQL federation does not cut it, a tenant based approach with multiple databases, each reserved for one or more user applications, could work.
来源：https://stackoverflow.com/questions/11862963/suitable-way-to-scale-rest-api-in-window-azure-to-handle-thousands-of-requests