【发布时间】：2013-02-10 23:26:40
【问题描述】：
我正在使用 ASP.NET Web API 组合一个文档管理服务，性能是一些的问题。
基于 IIS / ASP.NET ImageResizer 模块的作者 Nathanael Jones 的this article，我对提供静态文件的“最佳”性能所必需的条件形成了一些先入之见。那就是：
- 使用
HttpModule，因为它处于 ASP.NET 管道的早期阶段（更少的管道 = 更优化），并且结果证明比HttpHandler更容易处理这类事情。 -
Response.WriteFile(filename)优于Response.Write(memBuffer)，其中 memBuffer 是内存中的 C# 缓冲区。 - URL 重写（即
Context.RewritePath(virtualPath)）优于Response.WriteFile(filename)，因为它将使用经过良好优化的 IIS 静态文件处理程序。
问题是，由于一些奇怪的缓存问题，我仍然无法深入了解 (here)，我的 URL 重写技术无法正常工作。
所以现在我想知道一个更以 Web API 为中心的实现，如下所示：
public Task<HttpResponseMessage> DoTheFoo()
{
return Task<HttpResponseMessage>.Factory.StartNew(() =>
{
var response = new HttpResponseMessage();
response.Headers.Add("Content-Disposition", "inline; filename=\"" + attachmentFileName + "\"");
response.Headers.Add("content-type", mimeType);
response.Content = new StreamContent(File.OpenRead("somefile.doc"));
return response;
});
}
对于 Web API 解决方案，这显然使事情变得更整洁，因为服务的文件服务部分可以与控制器中的其他操作一起使用，但它的执行和扩展性能如何？我思考的因素：
- 网络带宽。这里大概没有区别，所有技术都写入相同数量的字节。
- 写入传出网络流的速度。 IIS 静态文件处理程序在这方面可能比 ASP.NET 管道好一点？集成管道的问题可能更少？该服务将在消费者级别的数百 kbits DSL 线路到千兆位 LAN 之间提供服务。
- RAM 使用情况。我假设 StreamContent 实现不会像 IIS 静态文件处理程序那样高效。
- CPU 使用率。 与 RAM 一样，我假设 StreamContent 会比 IIS 静态文件处理程序要求更高一些。
- 服务器端缓存。 IIS 静态文件处理程序提供了这一点（这正是给我带来麻烦的原因，因为它似乎并没有表现自己），但假设我可以让它表现自己，那就行了在 StreamContent 实施之前提供好处。我并不担心这方面，因为该服务更有可能响应许多不同文件请求，而不是重复相同的请求。
我无法组建一个服务器群来测试它以获得真实的性能数据，我怀疑将小规模测试结果分解会给出任何准确的结果。那么从知情人士那里，我可以期待什么样的差异？我几乎准备放弃 URL 重写实现，但如果它会给我带来明显的性能影响，我会坚持下去。
【问题讨论】：
-
如果您将 Varnish 放在前面，我只会考虑使用 Web API/WCF/MVC 解决方案；从 RAM 和并发的角度来看，这很糟糕。 ImageResizer 的 DiskCache 对非图像数据开放——你考虑过只使用它吗？
-
缓存的性能改进（据我所知，Varnish 是一种缓存工具）实际上是我最不关心的问题。正如我上面所说：“服务更有可能响应许多不同的文件请求，而不是重复相同的请求”。如果没有任何重复请求，缓存将无效。此外，每个请求都需要处理授权规则，我认为考虑到 Varnish 的工作方式，会导致问题吗？
-
@ComputerLinguist 从 RAM 和并发的角度来看，您将 Web API 描述为“糟糕”。但它如何与替代品相提并论？我不是在谈论 Varnish 在缓存场景中声称的“300 - 1000 倍”性能提升，除了缓存之外，我正在查看未缓存请求的原始性能，因为我相信我的大部分服务工作都会在这撒谎。
-
这与缓存无关，它与线程模型和上下文切换有关。如果您只是将大量静态字节从一个地方推送到另一个地方，那么性能瓶颈类似于缓存机制。
-
IIS 更擅长向客户端发送静态内容。使用 WebAPI 和 MVC，您必须仔细监控缓冲； ASP.NET 很容易通过在内存中复制您正在服务的文件（每个客户端）来“帮助您”。理论上，如果一切都完美的话，您应该能够在本机代码中接近 25% 的 IIS 文件服务效率。
标签： performance iis asp.net-web-api httpmodule