Je viens de découvrir pourquoi tous les sites Web ASP.Net sont lents, et j'essaie de trouver une solution.

Question

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

Au cas où vous n'auriez pas compris, comme je l'ai fait au début, cela signifie essentiellement ce qui suit :

• Chaque fois qu'une page Web ASP.Net met beaucoup de temps à se charger (peut-être en raison d'un appel lent à la base de données ou autre), et que l'utilisateur décide de naviguer vers une autre page parce qu'il est fatigué d'attendre, il ne le peut pas ! Le verrouillage de session ASP.Net oblige la nouvelle demande de page à attendre que la demande originale ait terminé son chargement péniblement lent. Arrrgh.

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

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

• Implémentez un SessionStateDataStore personnalisé, que ASP.Net prend en charge. Je n'en ai pas trouvé beaucoup à copier, et cela semble plutôt risqué et facile à gâcher.
• Gardez la trace de toutes les demandes en cours, et si une demande arrive du même utilisateur, annulez la demande initiale. Cela semble un peu extrême, mais cela pourrait fonctionner (je pense).
• N'utilisez pas la Session ! Lorsque j'ai besoin d'une sorte d'état pour l'utilisateur, je pourrais simplement utiliser Cache à la place, et les éléments clés sur le nom d'utilisateur authentifié, ou quelque chose comme ça. Encore une fois, cela semble un peu extrême.

Je ne peux vraiment pas croire que l'équipe ASP.Net de Microsoft ait laissé un tel goulot d'étranglement dans le cadre de travail à la version 4.0 ! Est-ce que j'ai raté quelque chose d'évident ? Serait-il difficile d'utiliser une collection ThreadSafe pour la session ?

Answer 1

Si votre page ne modifie aucune variable de session, vous pouvez vous passer de la plupart de ces verrouillages.

<% @Page EnableSessionState="ReadOnly" %>

Si votre page ne lit pas de variables 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, il suffit de désactiver l'état de session dans le web.config.

<sessionState mode="Off" />

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

Edit : Je devrais probablement expliquer ce que j'entends par "se retirer de la plupart de ce verrou". Un nombre quelconque de pages en lecture seule ou sans session peuvent être traitées en même temps pour une session donnée sans se bloquer mutuellement. Cependant, une page en lecture-écriture-session ne peut pas commencer à être traitée avant que toutes les requêtes en lecture seule soient terminées, et pendant qu'elle est en cours d'exécution, elle doit avoir un accès exclusif à la session de cet utilisateur afin de maintenir la cohérence. Le verrouillage de valeurs individuelles ne fonctionnerait pas, car que se passe-t-il si une page modifie un ensemble de valeurs connexes en tant que groupe ? Comment s'assurer que les autres pages exécutées en même temps obtiennent une vue cohérente des variables de la 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 faire en sorte que la majorité de vos pages soient des pages en lecture seule, ce qui augmenterait les chances que plusieurs requêtes simultanées du même utilisateur ne se bloquent pas mutuellement.

Answer 2

OK, un grand bravo à Joel Muller pour sa contribution. Ma solution finale était d'utiliser le module Custom SessionStateModule 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 (cela semblait même plus facile que de passer par le fournisseur).
• Utilisation d'une grande partie de la gestion de session standard d'ASP.Net (via la classe SessionStateUtility).

Cela a fait une énorme différence dans l'impression de "vivacité" de notre application. Je n'arrive toujours pas à croire que l'implémentation personnalisée de ASP.Net Session verrouille la session pour toute la requête. Cela ajoute une telle quantité de lenteur aux sites Web. À en juger par la quantité de recherches en ligne que j'ai dû faire (et les conversations avec plusieurs développeurs ASP.Net très expérimentés), beaucoup de gens ont connu ce problème, mais très peu en ont découvert la cause. Je vais peut-être écrire une lettre à Scott Gu...

J'espère que cela aidera quelques personnes !

Answer 3

J'ai commencé à utiliser le AngiesList.Redis.RedisSessionStateModule qui, en plus de l'utilisation de la (très rapide) Serveur Redis pour le stockage (j'utilise le Portail Windows -- bien qu'il existe également un Port MSOpenTech ), il n'effectue absolument aucun verrouillage sur 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 un contrôle de verrouillage/de concordance par vos propres moyens.

La décision de MS de verrouiller par défaut toutes les sessions ASP.NET pour pallier à une mauvaise conception des applications est une mauvaise décision, à mon avis. D'autant plus qu'il semble que la plupart des développeurs n'aient pas réalisé ou ne réalisent pas que les sessions étaient verrouillées, sans parler du fait que les applications doivent apparemment être structurées de manière à ce que l'état de la session soit en lecture seule autant que possible (opt-out, si possible).

Answer 4

J'ai préparé une bibliothèque à partir des liens postés dans ce fil. Elle 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 voulez implémenter le support de Memcached ou Redis, installez ce paquet. Ensuite, héritez du module LockFreeSessionStateModule et mettre en œuvre 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 capturées dans l'implémentation actuelle.

Quelques fournisseurs de sessions sans verrouillage utilisant Redis :

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

Answer 5

À moins que votre application n'ait des besoins particuliers, je pense que vous avez deux approches :

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

La session est non seulement thread-safe mais aussi state-safe, en ce sens que vous savez que tant que la requête en cours n'est pas terminée, chaque variable de session ne sera pas modifiée par une autre requête active. Pour ce faire, vous devez garantir cette session SERONT VERROUILLÉS jusqu'à ce que la demande en cours soit terminée.

Vous pouvez créer un comportement semblable à celui d'une session de plusieurs façons, mais s'il ne verrouille pas la session actuelle, il ne s'agit pas d'une "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 que cela ne puisse pas résoudre ce problème entièrement, car cela ne peut être utilisé que par une méthode de pooling et non asynchrone.