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