IIS与ASP.NET静态文件处理程序的比较

Question

我正在使用ASP.NET Web构建一个文档管理服务，性能是值得关注的。

基于IIS / ASP.NET ImageResizer模块的作者Nathanael的ASP.NET，我开发了一些关于服务静态文件的“最佳”性能所必需的一些先入为主的概念。这方面的规定是：

1. 使用HttpModule，因为它在ASP.NET管道中非常早期(更少的管道=更优化)，并且比HttpHandler更容易处理这类事情。
2. Response.WriteFile(filename)优于Response.Write(memBuffer)，其中memBuffer是内存中的C#缓冲区.
3. URL重写(即Context.RewritePath(virtualPath))优于Response.WriteFile(filename)，因为它将使用IIS静态文件处理程序，该处理程序得到了很好的优化。

麻烦的是，由于一些奇怪的缓存问题，我仍然无法找到(这里)的底部，我的URL重写技术本身并没有表现出来。

因此，现在我想知道一个更以Web为中心的实现，如下所示：

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解决方案，这显然会使事情变得更加整洁，因为服务的文件服务部分可以与控制器中的其他操作一起使用，但是它的执行和扩展效果如何呢？我思考的因素：

1. 网络带宽。在这里大概没什么区别，所有的技术都在写同样数量的字节。
2. 向传出网络流写入的速度。 IIS静态文件处理程序在这方面可能比ASP.NET管道要好一些？也许整合管道的问题就少了些？该服务将服务于消费者级的一对百gbit线路之间的任何东西，最高可达gbit LAN。
3. 内存的使用。--我假设StreamContent实现不会像那样高效。
4. CPU的使用。和内存一样，我假设StreamContent比IIS处理程序的要求要高一些。
5. 服务器端缓存。提供了这种功能(而且正是因为它本身似乎没有行为而给我带来麻烦)，但是假设我可以让它表现出自己的行为，这将在StreamContent实现之前提供好处。不过，我不太担心这个方面，因为服务更有可能响应许多不同的文件请求，而不是重复地响应相同的请求。

我不能把服务器场放在一起来测试它以获得真正的性能数字，而且我也怀疑将小规模的测试结果分解会给出任何准确的结果。所以，从那些知道的人看来，我能预料到什么样的差异？我已经准备好放弃URL重写实现了，但是如果它会给我带来显著的性能影响，我将坚持下去。

Answer 1

不确定您是否打算在Azure中托管，但如果您是，则可以为您的图像使用专用的公共blob存储容器。然后使用CDN服务为您提供(和缓存)静态文件。这将使问题从API转移到CDN中，CDN用于处理静态资源。