MVC 4各接続のIISメモリリーク

Question

長いポーリングアクションを実行するようにAsyncControllerが設定されています。これはうまくいきますが、同僚は新しい接続ごとに増加するように見えるサーバー上のメモリリークに気づいています。

私はこのページから何千回もリクエストする小さなアプリケーションを作成しました。私はIISプロセスのメモリ使用量を監視しています。各接続はメモリ使用量を増加させますが、クライアントの接続が切断されても、すべての使用率が低下しません。

public class WaitController : Controller 
{ 
    public JsonResult Member(string oauth_token, int service_id, bool busy = false) 
    { 
     return Json(new 
     { 
      ready = false, 
     }, JsonRequestBehavior.AllowGet); 
    } 
} 

これでは、ない同じくらいありますがメモリ使用量：

は、さらなる調査の後、私はこれが、何もしない標準Controllerと私のAsyncControllerを交換する際に、これはまだでも起こることがわかりました、その行動はまったく同じように見える。

私はメモリプロファイラを実行して10,000の接続の違いを表示しましたが、そこにはほとんど何もありません。ほとんどのメモリはExpiresEntry[]のインスタンスによってSystem.Web.CachingまたはSystem.Runtime.Cachingに取り込まれていますが、これらはIISワーカープロセスのメモリ増加と比較して何もありません。

私の質問はです。IISはこれを設計していますか？おそらく、これは接続スレッド用に割り当てられていたでしょう。これはIIS、ASP.NET、またはMVC 4のバグですか？

MVC 4のWebAPI機能を柔軟に使用できるようにすることが決定されました。これは、柔軟性があり、保守性が高く、将来の保証が得られ、AJAX経由でアクセスされるためです。 MVC 4でもWebサイトを構築しているので、開発の観点からも意味をなさないように思えました。

しかし、私たちは（今後）何千ものクライアントを接続する必要があるため、これをシステムアーキテクチャの重要な問題として提起しています。彼は代わりにWCFを使うことを提案している。だから、ボーナスの質問 - これらの問題を解決するWCFを使用しますか？

Answer 1

この項目については、MSフィールドエンジニアのarticleがあります。助けになるかもしれない。

Answer 2

もっと実験してテストした結果、残念ながらこれを防ぐことはできません。これは、設計上の問題か、IISに根本的な根本的な問題のいずれかと思われます。

下位レベルのオプションを使用するように私のメソッドを変更しました。同じことを行うにはIHttpAsyncHandlerを実装してください。以前使用していたのとまったく同じURLを使用できるように私はcustom HttpHandler route for MVCを使用しました。問題はまだ存在していましたが、わずかに小さいスケールでした。

次に完全に空白のIHttpHandlerを試してみましたが、それは単に{ ready: false }（私のコードはタイムアウト時のように）を返します。他のコードはHttpHandlerには含まれていませんが、同じ問題が引き続き発生します。

次に完全に空白のWCFサービスを試しましたが、これも{ ready: false }です。同じ問題ですが、今度はもっと小さな規模です。

リンク@rusevの答えがわかるように：

メモリの断片化やその他の自然劣化は避けられないことやリサイクルは、アプリケーションを定期的にクリーンアップされることが保証されます。

これは問題の原因かもしれません。私は、MVCコントローラを使用するときにオーバーヘッドが増えるため、断片化がより速く起こることが想像できます。 HttpHandlerやWCFサービスなどの低レベルのメソッドを使用すると、接続あたりのメモリ使用量が少なくなり、フラグメンテーションが少なくなります。