ASP.NET Web API を使用してドキュメント管理サービスを作成していますが、パフォーマンスに懸念があります。
IIS / ASP.NET ImageResizer モジュールの作成者である Nathanel Jones によるこの記事に基づいて、静的ファイルを提供する際の「最適な」パフォーマンスに何が必要かについて、いくつかの先入観を作成しました。その存在の正確さ：
- を使用する
HttpModuleのは、ASP.NET パイプラインの初期段階にあり (パイプラインが少ない = 最適化されている)、HttpHandler. Response.WriteFile(filename)Response.Write(memBuffer)memBuffer がメモリ内の C# バッファーである場合よりも優れています。- URL 書き換え (つまり) は、十分に最適化された IIS 静的ファイル ハンドラーを使用するため、
Context.RewritePath(virtualPath)よりも優れています。Response.WriteFile(filename)
問題は、いくつかの奇妙なキャッシュの問題のおかげで、まだ (ここで) の底にたどり着けないことです。私の 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 パイプラインよりも少し優れているのでしょうか? 統合されたパイプラインの問題は少ないのでしょうか? このサービスは、消費者レベルの数百キロビットの DSL 回線からギガビット LAN まで、あらゆるものでサービスを提供します。
- RAM の使用量。StreamContent の実装は、IIS の静的ファイル ハンドラーほど効率的ではないと思います。
- CPU使用率。RAM と同様に、StreamContent は IIS の静的ファイル ハンドラーよりも少し要求が厳しいと思います。
- サーバー側のキャッシュ。IIS静的ファイルハンドラーはこれを提供します（そして、それ自体が動作していないように見えるため、まさに私を悩ませています）が、それ自体を動作させることができると仮定すると、StreamContentの実装よりも先に利点が得られます. この点についてはそれほど心配していませんが、サービスは同じリクエストを繰り返し行うのではなく、多くの異なるファイル リクエストに応答する可能性が高いためです。
私はこれをテストして実際のパフォーマンスの数値を得るためにサーバーファームをまとめる立場にありません.小規模なテスト結果を因数分解しても正確な結果が得られるかどうかは疑問です. 知っている人からすれば、どのような違いが期待できるでしょうか。URL 書き換えの実装を放棄する準備がほとんど整っていますが、それによってパフォーマンスが大幅に低下する場合は、我慢します。