2013-09-27 27 views

回答

5

您应该保持如下的东西在你的心中,而设计Web API:

HTTP压缩 - HTTP压缩可 - 用于响应主体(Accept-Encoding:gzip)和用于请求主体(Content-Encoding:gzip)以提高HTTP API的网络性能 - 提供高速缓存控制头呃关于你的API响应。如果它们不可缓存,“Cache-Control:no-cache”将确保代理和浏览器能够理解这一点。如果它们是可缓存的,则需要考虑各种因素,例如缓存是否可以由代理共享,或者资源“新鲜”多久。

缓存验证 - 如果你有缓存API命中,你应该提供的Last-Modified或ETag头信息对你的反应,然后支持的If-Modified-由于对条件的要求或如果 - 无 - 匹配请求头。这将允许客户端检查他们的缓存副本是否仍然有效,并在不需要时阻止完整的资源下载。如果实施得当,您可以使您的条件请求比通常的请求更有效,并且还可以节省一些服务器端负载。

有条件修改 - ETag头还可用于启用对资源的条件修改。通过在您的GETs上提供一个ETag头,稍后POST,PATCH或DELETE请求可以提供一个If-Match头来检查他们是否正在更新或删除它们最后一次看到的相同状态的资源。

Chunk传输编码 - 如果您的内容响应较大,则Transfer-Encoding:Chunked是将响应传输到客户端的好方法。它将减少服务器和中间服务器的内存使用需求(特别是对于实现HTTP压缩),并且提供更快的首字节响应时间。

无状态 - 始终保持应用程序服务器不存在状态,以便轻松无忧地缩放它们。

批量操作 - 大多数客户端如果发出更少的请求来获取或修改更多数据,它们的性能会更好。在您的API中构建批量操作以支持这种用例是个好主意。

0

首先,你的架构很重要。 性能问题的80%根源是架构。我们不知道你的架构。

从我的角度来看,可以使用反向代理来促进应用程序服务器clusture上的负载平衡。在应用程序服务器层上,你有集群策略吗?你有缓存策略,以避免访问数据库?

.....

通常,您需要平衡体系结构的可扩展性,可靠性,可扩展性,安全性,可用性和性能。

0

使用protobuf通过电线串行化数据。

0

我只是做了一个测试,使用nuget包WebApiContrib.Formatting.ProtoBuf和文件大小从9.5 MB(JSON)下降到3,35 MB(protobuf)为25000个对象。

另外,对于大型查询结果,您可以使用SQL而不是EntityFramework。

如果使用AutoMapper从你的POCO转换为DTO,你可以手动设置的属性(更快的序列化)

,并尽量减少你的过滤器和的HttpModules,它是更轻,走得越快。(例如身份验证过滤器,...)