问题描述
我有一个REST API，通过它我很允许用户应用程序（蔚蓝的应用程序），以性能监视器数据发送到我的数据库。现在加载测试这个REST API我已经建立500 webrole的一个模拟器应用程序，每个（共5000实例）的10个实例，每1分钟的 50000（约）请求打算数据发布到REST API所以我需要扩展我的最佳实践REST API来处理这种大的负荷。
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.
以下是我的测试用例来扩展REST API
Following are my test cases to scale REST API
中 - 6实例=>可以处理300实例的请求
超大 - 2实例=>可以处理300实例的请求
现在我的问题是，这种类型的负载可以与水平缩放或垂直缩放处理？手段我应该需要增加没有实例与中等尺寸或小尺寸或我必须去，配有超大尺寸的实例吗？
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?
另外这个REST API将要发布数据的SQL Azure数据库（5 GB网络版），所以有关于处理请求任何限制？
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?
在上述情况下，所有的应用程序在同一区域考虑
推荐答案
您6中的实例= 12个核心，而2 XL实例= 16个内核。 Pricewise，最好是使用哟6媒介，而不是2 XLS。
Your 6 medium instances = 12 cores, while 2 XL instances = 16 cores. Pricewise, it is better yo use 6 mediums, and not 2 XLs.
另外，如果你动态地扩展，与XL只能通过8个内核的规模，同时与中您可以通过2个内核扩展。我会用中等的情况下，即使是很小的如果可能的话。并将目标水平缩放（a.k.a横向扩展） - 增加/减少实例的数量。
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.
我也会考虑某种缓冲数据发送到SQL之前，并没有直接使用Windows Azure SQL数据库（WASD）进行通信。使用这种类型的负载是柠可能每一秒命中WASD是要满足暂时的错误，由于重负载。考虑缓冲数据放入队列（无论是Azure存储队列，或Azure的服务总线队列），并具有辅助角色（可能有多个实例），分批处理队列中的消息。
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.
这类型的规模很可能是在CQRS模式更加敏感和可靠。你可以看一下有关CQRS和Windows Azure的更多信息和参考实现。
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.
这篇关于合适的方式来扩展REST API窗口天青处理成千上万的请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！