我正在 Visual Studio 2012 中开发 web api,并为每个 api 调用返回 JSON 结果。
如何提高WEB API的性能?
在设计 Web API 时,您应该牢记以下几点:
HTTP 压缩——HTTP 压缩可用于响应正文(Accept-Encoding:gzip)和请求正文(Content-Encoding:gzip),以提高 HTTP API 的网络性能
HTTP 缓存— 在您的 API 响应中提供 Cache-Control 标头。如果它们不可缓存,“Cache-Control: no-cache”将确保代理和浏览器理解这一点。如果它们是可缓存的,则需要考虑多种因素,例如缓存是否可以由代理共享,或者资源“新鲜”多长时间。
缓存验证——如果您有可缓存的 API 命中,您应该在响应中提供 Last-Modified 或 ETag 标头,然后支持条件请求的 If-Modified-Since 或 If-None-Match 请求标头。这将允许客户端检查他们的缓存副本是否仍然有效,并在不需要时阻止完整的资源下载。如果实施得当,您可以使您的条件请求比通常的请求更高效,并且还可以节省一些服务器端负载。
条件修改- ETag 标头也可用于启用资源的条件修改。通过在 GET 上提供 ETag 标头,以后的 POST、PATCH 或 DELETE 请求可以提供 If-Match 标头,以检查它们是否正在更新或删除与上次看到资源相同的状态。
分块传输编码——如果您有大量内容响应,传输编码:分块是一种将响应流式传输到客户端的好方法。它将减少您的服务器和中间服务器的内存使用要求(尤其是实现 HTTP 压缩),并提供更快的首字节响应时间。
无状态——始终保持应用程序服务器无状态,以便它们可以轻松无痛地扩展。
批量操作——如果大多数客户端可以发出更少的请求来获取或修改更多数据,它们的性能会更好。将批量操作构建到您的 API 中以支持这种用例是一个好主意。
这个话题太大了。有什么具体的细节吗?
大多数 ASP.NET 性能提示可能适用于 web api:http: //msdn.microsoft.com/en-us/library/cc668225.aspx
使用 protobuf 通过网络对数据进行序列化。
首先,您的架构很重要。性能问题的 80% 根本原因是架构问题。我们不了解您的架构。
在我看来,反向代理可用于促进应用服务器集群的负载平衡。在应用服务器层,你有集群策略吗?你有缓存策略来避免访问数据库吗?
......
通常,您需要平衡架构可伸缩性、可靠性、可扩展性、安全性、可用性和性能。
性能取决于您使用 Web API 框架所做的工作。也许你应该看看 MVC 分析工具:http: //msdn.microsoft.com/fr-fr/library/2s0xxa1d.aspx
我刚刚做了一个测试,使用 nuget 包 WebApiContrib.Formatting.ProtoBuf 并且文件大小从 25000 个对象的 9,5 mb(json)减少到 3,35 mb(protobuf)。
此外,对于大型查询结果,您可以使用 SQL 而不是 EntityFramework。
如果您使用 AutoMapper 从 POCO 转换为 DTO,则可以手动设置属性(序列化速度更快)
并最小化您的过滤器和HttpModules,它越轻,它运行得越快..(例如身份验证过滤器,...)