如何使用 .NET 在 Azure 上实现高性能 REST API? [英] How to achieve high-performance REST API on Azure with .NET?

问题描述

我们在 Windows Azure 上托管了一个 .NET Web 角色，该角色仅提供 REST API 和少数网络方法.

We have a .NET Web Role hosted on Windows Azure that only serves a REST API with only a hand few web methods.

API 被其他云托管应用(不是浏览器)大量使用.每个方法都是无状态的，支持直接扩展，并且通常与 Blob 或表存储交互.

API is used rather aggressively by other cloud hosted apps (not browsers). Each method is stateless which enable direct scaling out, and typically interacts with the Blob or Table Storage.

与大多数经典 API 不同的是，上传到 API 的数据量通常比从 API 下载的数据量大得多.然后，平均消息的大小通常也很大(即超过 100kB).

Then contrary to most classical API, the amount of data uploaded to the API is typically much larger than the data downloaded from the API. Then, the size the average message is typically quite big as well (i.e. above 100kB).

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

So far, we are using WCF on top of ASP.NET Forms with POX messages (Plain Old Xml). The front-end performance are not very good, culprits are:

• XML 冗长 ==> 带宽限制.
• ASP.NET + WCF + WcfRestContrib 解析/序列化消息很慢 ==> CPU 限制.

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

I am wondering what is the best strategy to achieve the highest possible front-end performance to reduce the number of VMs needed to support the workload.

我正在考虑的可能策略:

Possible strategies that I am considering:

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

• Discard XML in favor of ProtoBuf.
• Add upstream GZip compression (classical HTTP compression only applies downstream).
• Discard WCF entirely in favor of raw HttpHandlers.

是否有人对各种替代方案进行了基准测试，以充分利用每个 Azure VM 的这种用途?

Does anyone has benchmarked the various alternatives to achieve the most of each Azure VM for such usage?

Ps:隐式引用 Lokad Forecasting API 但尝试过用更一般的方式表达问题.

Ps: Implicitly referring the Lokad Forecasting API but tried to phrase the question in a more general way.

推荐答案

在您的 POC 中，我认为您可以在测试某些场景时从方程式中删除 Azure.

In your POCs, I think you can remove Azure from the equation as you test through some of the scenarios.

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

If this is truly bandwidth, compression is certainly an option, but it can be problematic if this web service will be opened up to the "public" rather than simply used by applications under your control. This is especially true in a heterogenous environment.

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

A less verbose format is an option, as long as you have a good means of RESTfully communicating failures due to bad formatting. XML makes this very easy. Lacking experience in ProtoBuf, it does appear to have some safety in this area, so it could be a very good option if bandwidth is your problem and may solve the speed of parsing issue. I would POC it outside of Azure first and then put it in.

如果您有证据表明 WCF 开销是一个问题，我只会运行原始 HttpHandler 方向.Azure 很难在配置中进行如此多的调试，以至于我不相信添加原始 HttpHandlers 的额外问题是正确的方向.

I would only run the raw HttpHandler direction if you have evidence WCF overhead is an issue. Azure is hard enough to debug with so much being in config that I am not convinced adding the additional issue of raw HttpHandlers is the proper direction to go.

这篇关于如何使用 .NET 在 Azure 上实现高性能 REST API?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！