ASP.NET Web API StreamContent与IIS静态文件处理程序

Question

我把一起使用的ASP.NET Web API文档管理服务,以及性能的一些担忧.

基于IIS/ASP.NET ImageResizer模块的作者Nathanael Jones撰写的这篇文章,我对服务静态文件的"最佳"性能所需的内容有了一些先入之见.正是这样:

1. 使用a,HttpModule因为它在ASP.NET管道的早期(较少的管道=更优化),并且结果更容易处理这类事情而不是HttpHandler.
2. Response.WriteFile(filename)比Response.Write(memBuffer)memBuffer是内存中的C#缓冲区更好.
3. URL重写(即Context.RewritePath(virtualPath))更好Response.WriteFile(filename),因为它将使用IIS静态文件处理程序,这是经过优化的.

麻烦的是,由于一些奇怪的缓存问题,我仍然无法达到(这里)的底部,我的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解决方案,这显然会使事情变得更加简洁,因为服务的文件服务部分可以与控制器中的其他操作一起使用,但它的执行和扩展程度如何？我思考的因素:

1. 网络带宽.据推测,这里没有区别,所有技术都写入相同数量的字节.
2. 写入传出网络流的速度.IIS静态文件处理程序在这方面可能比ASP.NET管道好一点？也许整合管道问题少了？该服务将用于消费级别的几百kbits DSL线路之间的任何服务,最高可达gbit LAN.
3. RAM使用情况.我假设StreamContent实现不如IIS静态文件处理程序那么高效.
4. CPU使用率.与RAM一样,我假设StreamContent比IIS静态文件处理程序要求更高.
5. 服务器端缓存.IIS静态文件处理程序提供了这个(并且正是让我烦恼的原因,因为它似乎并不表现自己),但假设我可以让它自己行动,这将在StreamContent实现之前提供好处.我不是很担心这方面,因为服务更有可能响应很多不同的文件请求,而不是相同的重复.

我无法组建一个服务器场来测试它以获得真实的性能数据,而且我怀疑将小规模测试结果分解会给出任何准确的结果.那些知情人士,我可以期待什么样的差异？我几乎已经准备好放弃URL重写实现,但如果它会给我一个明显的性能影响,我会坚持下去.

Answer 1

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