如何使用.NET在Azure上实现高性能REST API？

Question

我们在Windows Azure上托管了.NET Web角色,仅使用少量Web方法提供REST API.

其他云托管应用程序(而非浏览器)使用API​​相当积极.每种方法都是无状态的,可以直接扩展,并且通常与Blob或表存储交互.

然后,与大多数传统API相反,上传到API的数据量通常比从API 下载的数据大得多.然后,平均消息的大小通常也很大(即超过100kB).

到目前为止,我们在带有POX消息的ASP.NET Forms上使用WCF(Plain Old Xml).前端性能不是很好,罪魁祸首是:

• XML是详细的==>带宽限制.
• ASP.NET + WCF + WcfRestContrib缓慢解析/序列化消息==> CPU限制.

我想知道什么是实现最高前端性能的最佳策略,以减少支持工作负载所需的VM数量.

我正在考虑的可能策略:

• 丢弃XML以支持ProtoBuf.
• 添加上游 GZip压缩(经典HTTP压缩仅适用于下游).
• 完全放弃WCF以支持原始HttpHandler.

是否有人对各种替代方案进行了基准测试,以实现每个Azure VM的大部分用途？

Ps:隐含地引用Lokad Forecasting API,但试图以更一般的方式表达问题.

Answer 1

在您的 POC 中，我认为您可以在测试某些场景时将 Azure 从等式中删除。

如果这确实是带宽，那么压缩当然是一种选择，但如果此 Web 服务向“公众”开放而不是简单地由您控制下的应用程序使用，则可能会出现问题。在异构环境中尤其如此。

只要您有一种很好的方法来解决由于格式错误而导致的 RESTful 通信失败，就可以选择不太详细的格式。XML 使这变得非常容易。由于缺乏 ProtoBuf 的经验，它似乎在这方面确实有一定的安全性，因此如果带宽是您的问题，它可能是一个非常好的选择，并且可以解决解析速度问题。我会先在 Azure 之外对其进行 POC，然后再将其放入。

如果您有证据表明 WCF 开销是一个问题，我只会运行原始 HttpHandler 方向。Azure 的调试非常困难，因为配置中有太多内容，我不相信添加原始 HttpHandlers 的额外问题是正确的方向。