6

ロングポーリングアクションを実行するようにAsyncControllerセットアップしました。これはすべて正常に機能しますが、同僚は、新しい接続ごとに増加するように見えるサーバー上のメモリ リークに気付きました。

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

さらに調査した結果、 my をこれ以外のことを行わないAsyncController標準に置き換えても、これは引き続き発生することがわかりました。Controller

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

この場合、メモリ使用量はそれほど多くありませんが、動作はまったく同じように見えます。

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

私の質問は、IIS はこれを意図的に行っているのでしょうか? おそらくこれは、後で必要になった場合に備えてぶらぶらしている接続スレッドに割り当てられていたのでしょうか? これは IIS、ASP.NET、または MVC 4 のバグですか?

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

ただし、(将来) 何千ものクライアントを接続する必要があるため、同僚がこれをシステム アーキテクチャの重大な問題として提起しました。彼は、代わりに WCF を使用することを提案しています。おまけの質問ですが、WCF を使用するとこれらの問題は解決しますか?

4

2 に答える 2

1

このテーマについては、MS フィールド エンジニアによる素晴らしい記事があります。役立つかもしれません。

于 2013-02-27T15:25:35.997 に答える
0

さらに実験とテストを重ねた結果、残念ながらこれを防ぐことはできないことがわかりました。これは、設計によるものか、IIS の根深い問題のようです。

低レベルのオプションを使用するようにメソッドを変更IHttpAsyncHandlerしました。同じことを行うために an を実装します。MVCのカスタム HttpHandler ルートを使用して、以前とまったく同じ URL を使用できるようにしました。問題はまだ存在していましたが、規模はわずかに小さくなりました。

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

次に、完全に空の WCF サービスを試してみましたが、これも返され{ ready: false }ました。同じ問題ですが、今回はさらに小規模です。

リンク@rusevの回答が示唆するように：

メモリの断片化やその他の自然な劣化は避けられず、リサイクルによってアプリケーションが定期的にクリーンアップされます。

これが問題の原因である可能性があります。MVC コントローラーを使用するとオーバーヘッドが増えるため、断片化がより速く発生することが想像できます。HttpHandler や WCF サービスなどの下位レベルのメソッドを使用すると、接続ごとに使用するメモリが少なくなるため、断片化が少なくなります。

于 2013-03-01T16:22:09.623 に答える