Je viens de découvrir pourquoi tous les sites Web ASP.Net sont lents et j'essaie de savoir quoi faire à ce sujet

Je viens de découvrir que chaque demande dans une application Web ASP.Net obtient un verrou de session au début d'une demande, puis le libère à la fin de la demande!

Au cas où les implications de cela seraient perdues pour vous, comme c'était le cas pour moi au début, cela signifie essentiellement ce qui suit:

• Chaque fois qu'une page Web ASP.Net prend beaucoup de temps à charger (peut-être en raison d'un appel lent à la base de données ou autre), et l'utilisateur décide qu'il souhaite naviguer vers une autre page parce qu'il est fatigué d'attendre, IL NE PEUT PAS! Le verrou de session ASP.Net force la nouvelle demande de page à attendre que la demande d'origine ait terminé son chargement douloureusement lent. Arrrgh.

• Chaque fois qu'un UpdatePanel se charge lentement, et l'utilisateur décide de naviguer vers une autre page avant la fin de la mise à jour du UpdatePanel ... IL NE PEUT PAS! Le verrou de session ASP.net force la nouvelle demande de page à attendre que la demande d'origine ait terminé son chargement douloureusement lent. Double Arrrgh!

Quelles sont donc les options? Jusqu'à présent, j'ai trouvé:

• Implémentez un SessionStateDataStore personnalisé, pris en charge par ASP.Net. Je n'en ai pas trouvé trop à copier, et cela semble assez risqué et facile à gâcher.
• Gardez une trace de toutes les demandes en cours et, si une demande provient du même utilisateur, annulez la demande d'origine. Semble un peu extrême, mais cela fonctionnerait (je pense).
• N'utilisez pas Session! Lorsque j'ai besoin d'une sorte d'état pour l'utilisateur, je peux simplement utiliser le cache à la place et les éléments clés sur le nom d'utilisateur authentifié, ou quelque chose de ce genre. Cela semble encore un peu extrême.

Je ne peux vraiment pas croire que l'équipe ASP.Net Microsoft aurait laissé un goulot d'étranglement de performances aussi énorme dans le cadre de la version 4.0! Suis-je en train de manquer quelque chose d'évident? À quel point serait-il difficile d'utiliser une collection ThreadSafe pour la session?

Si votre page ne modifie aucune variable de session, vous pouvez désactiver la plupart de ce verrou.

<% @Page EnableSessionState="ReadOnly" %>

Si votre page ne lit aucune variable de session, vous pouvez désactiver complètement ce verrou pour cette page.

<% @Page EnableSessionState="False" %>

Si aucune de vos pages n'utilise de variables de session, désactivez simplement l'état de la session dans le web.config.

<sessionState mode="Off" />

Je suis curieux, que pensez-vous qu'une "collection ThreadSafe" ferait pour devenir thread-safe, si elle n'utilise pas de verrous?

Edit: je devrais probablement expliquer par ce que je veux dire par "désactiver la plupart de ce verrou". N'importe quel nombre de pages en lecture seule ou sans session peut être traité pour une session donnée en même temps sans se bloquer. Cependant, une page de session en lecture-écriture ne peut pas commencer le traitement tant que toutes les demandes en lecture seule ne sont pas terminées et, pendant son exécution, elle doit avoir un accès exclusif à la session de cet utilisateur afin de maintenir la cohérence. Le verrouillage des valeurs individuelles ne fonctionnerait pas, car que se passe-t-il si une page modifie un ensemble de valeurs associées en tant que groupe? Comment garantiriez-vous que d'autres pages exécutées en même temps obtiennent une vue cohérente des variables de session de l'utilisateur?

Je vous suggère d'essayer de minimiser la modification des variables de session une fois qu'elles ont été définies, si possible. Cela vous permettrait de créer la majorité de vos pages en lecture seule, augmentant ainsi les chances que plusieurs demandes simultanées du même utilisateur ne se bloquent pas.

OK, donc gros accessoires à Joel Muller pour toutes ses contributions. Ma solution ultime a été d'utiliser le SessionStateModule personnalisé détaillé à la fin de cet article MSDN:

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

C'était:

• Très rapide à mettre en œuvre (semblait en fait plus facile que de suivre la voie du fournisseur)
• Utilisé une grande partie de la gestion de session ASP.Net standard prête à l'emploi (via la classe SessionStateUtility)

Cela a fait une énorme différence dans le sentiment de "snapiness" à notre application. Je n'arrive toujours pas à croire que l'implémentation personnalisée de ASP.Net Session verrouille la session pour toute la demande. Cela ajoute une telle quantité de lenteur aux sites Web. À en juger par la quantité de recherches en ligne que j'ai eu à faire (et les conversations avec plusieurs développeurs ASP.Net vraiment expérimentés), beaucoup de gens ont rencontré ce problème, mais très peu de gens sont allés au fond de la cause. J'écrirai peut-être une lettre à Scott Gu ...

J'espère que cela aide quelques personnes!

J'ai commencé à utiliser le AngiesList.Redis.RedisSessionStateModule , qui en plus d'utiliser le serveur Redis (très rapide) pour le stockage (j'utilise le port Windows - bien qu'il y ait aussi un port MSOpenTech ), il ne bloque absolument pas la session .

À mon avis, si votre application est structurée de manière raisonnable, ce n'est pas un problème. Si vous avez réellement besoin de données verrouillées et cohérentes dans le cadre de la session, vous devez spécifiquement implémenter vous-même un contrôle de verrouillage / simultané.

À mon avis, décider que chaque session ASP.NET devrait être verrouillée par défaut juste pour gérer une mauvaise conception d'application est une mauvaise décision. Surtout parce qu'il semble que la plupart des développeurs ne réalisent / ne réalisent même pas que les sessions ont été verrouillées, et encore moins que les applications doivent apparemment être structurées afin que vous puissiez faire un état de session en lecture seule autant que possible (opt-out, si possible) .

J'ai préparé une bibliothèque basée sur les liens publiés dans ce fil. Il utilise les exemples de MSDN et CodeProject. Merci à James.

J'ai également apporté des modifications conseillées par Joel Mueller.

Le code est ici:

https://github.com/dermeister0/LockFreeSessionState

Module HashTable:

Install-Package Heavysoft.LockFreeSessionState.HashTable

Module ScaleOut StateServer:

Install-Package Heavysoft.LockFreeSessionState.Soss

Module personnalisé:

Install-Package Heavysoft.LockFreeSessionState.Common

Si vous souhaitez implémenter la prise en charge de Memcached ou Redis, installez ce package. Héritez ensuite la classe LockFreeSessionStateModule et implémentez des méthodes abstraites.

Le code n'est pas encore testé en production. Il faut également améliorer la gestion des erreurs. Les exceptions ne sont pas prises dans l'implémentation actuelle.

Certains fournisseurs de sessions sans verrouillage utilisant Redis:

• https://github.com/angieslist/AL-Redis (suggéré par gregmac dans ce fil.)
• https://github.com/welegan/RedisSessionProvider (NuGet: RedisSessionProvider)
• https://github.com/efaruk/playground/tree/master/UnlockedStateProvider (NuGet: UnlockedStateProvider.Redis)

Sauf si votre application a des besoins particuliers, je pense que vous avez 2 approches:

1. Ne pas utiliser de session du tout
2. Utilisez la session telle quelle et effectuez le réglage fin comme l'a mentionné Joel.

La session est non seulement sécurisée pour les threads mais également pour les états, de manière à ce que, jusqu'à ce que la demande en cours soit terminée, chaque variable de session ne changera pas d'une autre demande active. Pour que cela se produise, vous devez vous assurer que la session SERA VERROUILLÉE jusqu'à ce que la demande en cours soit terminée.

Vous pouvez créer une session comme un comportement de plusieurs façons, mais si elle ne verrouille pas la session en cours, elle ne sera pas «session».

Pour les problèmes spécifiques que vous avez mentionnés, je pense que vous devriez vérifier HttpContext.Current.Response.IsClientConnected . Cela peut être utile pour éviter les exécutions et les attentes inutiles sur le client, bien qu'il ne puisse pas résoudre ce problème entièrement, car cela ne peut être utilisé que par une méthode de regroupement et non par async.

Si vous utilisez la mise à jour Microsoft.Web.RedisSessionStateProvider(à partir de 3.0.2), vous pouvez l'ajouter à votre web.configpour autoriser les sessions simultanées.

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

La source

Pour ASPNET MVC, nous avons fait ce qui suit:

1. Par défaut, définissez SessionStateBehavior.ReadOnlytoutes les actions du contrôleur en remplaçantDefaultControllerFactory
2. Sur les actions du contrôleur qui doivent être écrites dans l'état de session, marquez avec l'attribut pour le définir sur SessionStateBehavior.Required

Créez ControllerFactory personnalisé et remplacez 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
{ }

Connectez la fabrique de contrôleurs créée à global.asax.cs

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

Maintenant, nous pouvons avoir les deux read-onlyet l' read-writeétat de session en un seul 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);
    }
}

Remarque: l'état de session ASPNET peut toujours être écrit même en mode lecture seule et ne lèvera aucune forme d'exception (il ne se verrouille tout simplement pas pour garantir la cohérence), nous devons donc faire attention à marquer AcquireSessionLockdans les actions du contrôleur qui nécessitent l'écriture de l'état de session.

Marquer l'état de session d'un contrôleur comme étant en lecture seule ou désactivé résoudra le problème.

Vous pouvez décorer un contrôleur avec l'attribut suivant pour le marquer en lecture seule:

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

l' énumération System.Web.SessionState.SessionStateBehavior a les valeurs suivantes:

• Défaut
• désactivé
• Lecture seulement
• Obligatoire

Juste pour aider quiconque avec ce problème (verrouillage des requêtes lors de l'exécution d'un autre depuis la même session) ...

Aujourd'hui, j'ai commencé à résoudre ce problème et, après quelques heures de recherche, je l'ai résolu en supprimant la Session_Startméthode (même si elle était vide) du fichier Global.asax .

Cela fonctionne dans tous les projets que j'ai testés.

Après avoir lutté avec toutes les options disponibles, j'ai fini par écrire un fournisseur SessionStore basé sur un jeton JWT (la session se déplace à l'intérieur d'un cookie, et aucun stockage backend n'est nécessaire).

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

Avantages:

• Remplacement direct, aucune modification de votre code n'est nécessaire
• Évoluez mieux que tout autre magasin centralisé, car aucun backend de stockage de session n'est nécessaire.
• Plus rapide que tout autre stockage de session, car aucune donnée n'a besoin d'être récupérée à partir d'un stockage de session
• Ne consomme aucune ressource de serveur pour le stockage de session.
• Implémentation non bloquante par défaut: la demande simultanée ne se bloquera pas et ne bloquera pas la session
• Faites évoluer votre application horizontalement: comme les données de session voyagent avec la demande elle-même, vous pouvez avoir plusieurs têtes Web sans vous soucier du partage de session.