我有一个REST API，我允许用户应用程序（azure app）将perfmon数据发送到我的数据库。现在加载测试这个REST API我已经构建了一个500 webrole的模拟器应用程序，每个模拟器应用程序包含10个实例（总共5000个实例），每1分钟 50000（大约）个请求将数据发布到REST API所以我需要使用最佳实践扩展我的REST API以处理这么多负载。
以下是我的扩展REST API的测试用例
中 - 6个实例=＆gt;可以处理300个实例的请求
特大号 - 2个实例=＆gt;可以处理300个实例的请求
现在我的问题是这种类型的负载可以通过水平缩放或垂直缩放来处理吗？意味着我是否需要增加中等大小或小尺寸的实例，或者我必须使用超大尺寸的实例？
此REST API也将发布数据SQL Azure数据库（5 GB网页版），因此处理请求有任何限制吗？
在上述情况下，所有应用程序都考虑在同一区域
答案 0 :(得分：2)
您的6个中型实例= 12个内核，而2个XL实例= 16个内核。价格方面，最好使用6种介质，而不是2种XL。
另外，如果您动态扩展，使用XL只能扩展8个内核，而中型扩展可以扩展2个内核。我会使用Medium实例，如果可能的话甚至很小。并将目标水平缩放（a.k.a缩小） - 增加/减少实例数量。
在发送到SQL之前，我还会考虑某种缓冲数据，而不是直接与Windows Azure SQL数据库（WASD）通信。对于这种类型的负载，很可能每次击中WASD都会遇到由于负载过重而导致的瞬态误差。考虑将数据缓冲到队列（Azure存储队列或Azure服务总线队列）并具有工作者角色（可能具有多个实例），批量处理队列消息。
这种类型的量表很可能在CQRS模式中更具响应性和可靠性。您可以查看CQRS Journey Project以获取有关CQRS和Windows Azure的更多信息和参考实现。
答案 1 :(得分：1)
这是一个评论，但我没有了房间。
如果您正在设计REST API的速度和规模以接收PERFMON数据，那么为什么要通过调用SQL而不是调用QUEUE来降低API速度？
如果SQL无法继续处理单个队列，那么SQL也无法跟上来自6个REST服务的调用。最后，SQL插入受磁盘IO的限制。如果设计得当，单个进程可以像SQL一样快地将数据发送到SQL。
每分钟50,000次插入很多，所以看看如何设计索引以及如何设计插入。肯定你不想要一个会碎片化的索引。如果原始数据具有顺序密钥，则可以将其用作PK。否则使用Iden作为PK。
如果批量插入，则可以提高吞吐量。批处理不一定会增加延迟。如果它准备好进行下一个插入并且队列中只有一个插入，则插入一批1个。插入物将有一个最佳位置（如100 - 1000）。
我所做的是在前台构建插入，然后插入异步。如果您可以比异步插入更快地构建插入，那么SQL已完全加载。由于您要在内存中构建语法并插入磁盘构建，因此除非您有一些复杂的处理来构建语法，否则语法会更快。是的，希望联合分割磁盘IO，但首先要优化该插入。 Drapper很受欢迎。我经常使用表值参数。插入表值（）不是最快的选项，但它可以跟上50,000 /分钟。
使用队列保护REST API。然后优化队列处理。
我会说Azure表存储但它限制为每秒5,000个实体和500个实体/秒/分区。有了这些吞吐量限制，我认为你不能称之为ATS高度可扩展性。
答案 2 :(得分：0)
这似乎是一个扩展存储的问题，并且您希望尽可能接近实时。
在这种情况下，如果SQL联合没有删除它，那么基于租户的方法可以使用多个数据库，每个数据库都保留给一个或多个用户应用程序。