すべてのASP.Net Webサイトが遅い理由を発見しました。どうすればよいのかを考えています。

ASP.Net Webアプリケーションのすべてのリクエストがリクエストの最初にセッションロックを取得し、リクエストの最後にそれを解放することを発見しました！

最初に私がそうであったように、これの影響があなたに失われた場合、これは基本的に以下を意味します：

• ASP.Net Webページの読み込みに時間がかかる（データベースの呼び出しが遅いなどの理由で）場合があり、ユーザーは待機に飽き飽きしているため、別のページに移動することを決定します。ASP.Netセッションロックにより、新しいページ要求は、元の要求が非常に遅いロードを終了するまで強制的に待機します。ああ。

• UpdatePanelの読み込みが遅く、ユーザーがUpdatePanelの更新が完了する前に別のページに移動することにした場合...できません。ASP.netセッションロックにより、新しいページ要求は、元の要求が非常に遅いロードを完了するまで強制的に待機します。ダブルアレ！

それで、オプションは何ですか？これまでのところ私は思いつきました：

• ASP.NetがサポートするカスタムSessionStateDataStoreを実装します。私はコピーするほど多くを見つけていません、そしてそれは一種のリスクが高く、簡単に失敗するようです。
• 進行中のすべてのリクエストを追跡し、同じユーザーからリクエストが届いた場合は、元のリクエストをキャンセルします。ちょっと極端に思えますが、うまくいくと思います。
• セッションを使用しないでください！ユーザーに何らかの種類の状態が必要な場合は、代わりにキャッシュを使用し、認証されたユーザー名のキーアイテムなどを使用できます。再び極端なようです。

ASP.Net Microsoftチームがバージョン4.0のフレームワークにこのような巨大なパフォーマンスのボトルネックを残したとは本当に信じられません！明らかなものがないのですか？セッションにThreadSafeコレクションを使用するのはどれほど難しいでしょうか。

ページがセッション変数を変更しない場合は、このロックの大部分をオプトアウトできます。

<% @Page EnableSessionState="ReadOnly" %>

ページがセッション変数を読み取らない場合は、そのページに対して、このロックを完全に無効にすることができます。

<% @Page EnableSessionState="False" %>

どのページもセッション変数を使用していない場合は、web.configでセッション状態をオフにします。

<sessionState mode="Off" />

ロックを使用しない場合、「ThreadSafeコレクション」がスレッドセーフになるにはどうしたらよいと思いますか。

編集：「このロックのほとんどをオプトアウトする」とはどういう意味かを説明する必要があります。任意の数の読み取り専用セッションページまたは非セッションページを、互いにブロックすることなく、特定のセッションで同時に処理できます。ただし、読み取り/書き込みセッションページは、すべての読み取り専用リクエストが完了するまで処理を開始できません。実行中は、一貫性を維持するために、そのユーザーのセッションに排他的にアクセスする必要があります。1つのページが関連する値のセットをグループとして変更した場合はどうなるのか、個々の値のロックは機能しません。同時に実行されている他のページがユーザーのセッション変数の一貫したビューを確実に取得するようにするにはどうすればよいですか？

可能であれば、一度設定したセッション変数の変更を最小限に抑えることをお勧めします。これにより、ページの大部分を読み取り専用セッションのページにすることができ、同じユーザーからの複数の同時リクエストが互いにブロックしなくなる可能性が高くなります。

承知しました。JoelMuller氏のすべての情報提供に対して、非常に大きなプロップです。私の最終的な解決策は、このMSDN記事の最後に詳述されているカスタムSessionStateModuleを使用することでした。

http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstateutility.aspx

これは。。。でした：

• 実装が非常に速い（実際にはプロバイダーのルートに行くよりも簡単に見えた）
• 多くの標準ASP.Netセッション処理をそのまま使用しました（SessionStateUtilityクラス経由）。

これにより、アプリケーションの「スナップ感」に大きな違いが生じました。ASP.Netセッションのカスタム実装がリクエスト全体のセッションをロックすることはまだ信じられません。これは、ウェブサイトにそのような非常に遅い速度を加えます。私がしなければならなかったオンライン調査の量（および実際に経験豊富なASP.Net開発者との会話）から判断すると、多くの人がこの問題を経験しましたが、原因を突き止めた人はほとんどいません。多分私はスコット・グーに手紙を書くでしょう...

これが数人の人に役立つことを願っています！

AngiesList.Redis.RedisSessionStateModuleの使用を開始しました。これは、ストレージに（非常に高速な）Redisサーバーを使用する以外に（Windowsポートを使用していますが、MSOpenTechポートもあります））とは、セッションをロックしません。 。

私の意見では、アプリケーションが合理的な方法で構成されている場合、これは問題ではありません。セッションの一部として実際にロックされた一貫性のあるデータが必要な場合は、独自にロック/同時実行チェックを実装する必要があります。

MSは、貧弱なアプリケーション設計を処理するためだけにすべてのASP.NETセッションをデフォルトでロックする必要があると決定することは、私の意見では悪い決定です。特に、ほとんどの開発者はセッションがロックされていることに気付いていない、または知らないように思われるため、可能な限り読み取り専用のセッション状態を実行できるようにアプリを構造化する必要があることは言うまでもありません（可能な場合はオプトアウト） 。

このスレッドに投稿されたリンクを元にライブラリを用意しました。MSDNとCodeProjectの例を使用しています。ジェームスに感謝します。

Joel Muellerのアドバイスを受けて修正も加えました。

コードはここにあります：

https://github.com/dermeister0/LockFreeSessionState

HashTableモジュール：

Install-Package Heavysoft.LockFreeSessionState.HashTable

ScaleOut StateServerモジュール：

Install-Package Heavysoft.LockFreeSessionState.Soss

カスタムモジュール：

Install-Package Heavysoft.LockFreeSessionState.Common

MemcachedまたはRedisのサポートを実装する場合は、このパッケージをインストールしてください。次に、LockFreeSessionStateModuleクラスを継承し、抽象メソッドを実装します。

コードはまだ本番環境でテストされていません。エラー処理を改善する必要もあります。現在の実装では例外は捕捉されていません。

Redisを使用する一部のロックフリーセッションプロバイダー：

• https://github.com/angieslist/AL-Redis（このスレッドでgregmacが推奨）
• https://github.com/welegan/RedisSessionProvider（NuGet：RedisSessionProvider）
• https://github.com/efaruk/playground/tree/master/UnlockedStateProvider（NuGet：UnlockedStateProvider.Redis）

アプリケーションに特別な必要がない限り、2つのアプローチがあると思います。

1. セッションをまったく使用しない
2. セッションをそのまま使用し、ジョエルが述べたように微調整を実行します。

セッションはスレッドセーフであるだけでなく状態セーフでもあり、現在のリクエストが完了するまで、すべてのセッション変数が別のアクティブなリクエストから変更されることはありません。これが発生するためには、セッションがロックされることを確認する必要があります、現在のリクエストが完了するまでれる。

動作のようなセッションはさまざまな方法で作成できますが、現在のセッションをロックしない場合、「セッション」にはなりません。

あなたが言及した特定の問題については、HttpContext.Current.Response.IsClientConnectedを確認する必要があると思います。これは、この問題を完全に解決できるわけではありませんが、プールの方法でのみ使用でき、非同期では使用できないため、クライアントでの不要な実行と待機を防ぐのに役立ちます。

更新されたMicrosoft.Web.RedisSessionStateProvider（から始まる3.0.2）を使用している場合は、これをに追加して、web.config同時セッションを許可できます。

<appSettings>
    <add key="aspnet:AllowConcurrentRequestsPerSession" value="true"/>
</appSettings>

ソース

ASPNET MVCの場合、次のことを行いました。

1. デフォルトでは、SessionStateBehavior.ReadOnlyオーバーライドすることですべてのコントローラーのアクションを設定しますDefaultControllerFactory
2. セッション状態への書き込みが必要なコントローラーアクションで、属性にマークを付けて設定します SessionStateBehavior.Required

カスタムControllerFactoryを作成してオーバーライドしますGetControllerSessionBehavior。

    protected override SessionStateBehavior GetControllerSessionBehavior(RequestContext requestContext, Type controllerType)
    {
        var DefaultSessionStateBehaviour = SessionStateBehaviour.ReadOnly;

        if (controllerType == null)
            return DefaultSessionStateBehaviour;

        var isRequireSessionWrite =
            controllerType.GetCustomAttributes<AcquireSessionLock>(inherit: true).FirstOrDefault() != null;

        if (isRequireSessionWrite)
            return SessionStateBehavior.Required;

        var actionName = requestContext.RouteData.Values["action"].ToString();
        MethodInfo actionMethodInfo;

        try
        {
            actionMethodInfo = controllerType.GetMethod(actionName, BindingFlags.IgnoreCase | BindingFlags.Public | BindingFlags.Instance);
        }
        catch (AmbiguousMatchException)
        {
            var httpRequestTypeAttr = GetHttpRequestTypeAttr(requestContext.HttpContext.Request.HttpMethod);

            actionMethodInfo =
                controllerType.GetMethods().FirstOrDefault(
                    mi => mi.Name.Equals(actionName, StringComparison.CurrentCultureIgnoreCase) && mi.GetCustomAttributes(httpRequestTypeAttr, false).Length > 0);
        }

        if (actionMethodInfo == null)
            return DefaultSessionStateBehaviour;

        isRequireSessionWrite = actionMethodInfo.GetCustomAttributes<AcquireSessionLock>(inherit: false).FirstOrDefault() != null;

         return isRequireSessionWrite ? SessionStateBehavior.Required : DefaultSessionStateBehaviour;
    }

    private static Type GetHttpRequestTypeAttr(string httpMethod) 
    {
        switch (httpMethod)
        {
            case "GET":
                return typeof(HttpGetAttribute);
            case "POST":
                return typeof(HttpPostAttribute);
            case "PUT":
                return typeof(HttpPutAttribute);
            case "DELETE":
                return typeof(HttpDeleteAttribute);
            case "HEAD":
                return typeof(HttpHeadAttribute);
            case "PATCH":
                return typeof(HttpPatchAttribute);
            case "OPTIONS":
                return typeof(HttpOptionsAttribute);
        }

        throw new NotSupportedException("unable to determine http method");
    }

AcquireSessionLockAttribute

[AttributeUsage(AttributeTargets.Method)]
public sealed class AcquireSessionLock : Attribute
{ }

作成したコントローラーファクトリを global.asax.cs

ControllerBuilder.Current.SetControllerFactory(typeof(DefaultReadOnlySessionStateControllerFactory));

これで、1つのに両方read-onlyとread-writeセッション状態を含めることができますController。

public class TestController : Controller 
{
    [AcquireSessionLock]
    public ActionResult WriteSession()
    {
        var timeNow = DateTimeOffset.UtcNow.ToString();
        Session["key"] = timeNow;
        return Json(timeNow, JsonRequestBehavior.AllowGet);
    }

    public ActionResult ReadSession()
    {
        var timeNow = Session["key"];
        return Json(timeNow ?? "empty", JsonRequestBehavior.AllowGet);
    }
}

注：ASPNETセッション状態は、読み取り専用モードでもAcquireSessionLock書き込みが可能であり、いかなる形式の例外もスローしません（一貫性を保証するためにロックされません）。そのため、セッション状態の書き込みを必要とするコントローラーのアクションをマークするように注意する必要があります。

コントローラのセッション状態を読み取り専用または無効としてマークすると、問題が解決します。

コントローラを次の属性で装飾して、読み取り専用にすることができます。

[SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly)]

System.Web.SessionState.SessionStateBehaviorの列挙型の値は次のとおりです。

• デフォルト
• 無効
• 読み取り専用
• 必須

この問題で誰かを助けるために（同じセッションから別のものを実行するときにリクエストをロックする）...

今日、私はこの問題の解決を開始し、数時間の調査の後Session_Start、Global.asaxファイルからメソッドを（空であっても）削除することで解決しました。

これは、私がテストしたすべてのプロジェクトで機能します。

利用可能なすべてのオプションに取り組んだ後、私は最終的にJWTトークンベースのSessionStoreプロバイダーを記述しました（セッションはCookie内を移動するため、バックエンドストレージは必要ありません）。

http://www.drupalonwindows.com/en/content/token-sessionstate

利点：

• ドロップイン置換、コードの変更は不要
• セッションストレージバックエンドが不要なため、他の集中型ストアよりも優れた拡張性。
• セッションストレージからデータを取得する必要がないため、他のセッションストレージよりも高速
• セッションストレージ用のサーバーリソースを消費しません。
• デフォルトのノンブロッキング実装：同時リクエストはお互いをブロックせず、セッションをロックしません
• アプリケーションを水平方向にスケーリングします。セッションデータはリクエスト自体と共に移動するため、セッションの共有を気にすることなく、複数のWebヘッドを使用できます。