Je viens de découvrir pourquoi tous les ASP.Net les sites web sont lents, et je suis en train de travailler sur ce qu'il faut faire

Si votre page ne modifie pas les variables de session, vous pouvez vous désinscrire de la plupart de ce verrou.

<% @Page EnableSessionState="ReadOnly" %>

Si votre page n'a pas pour lire toutes les variables de session, vous pouvez vous désinscrire de ce verrou entièrement, pour cette page.

<% @Page EnableSessionState="False" %>

Si aucun de vos pages utiliser des variables de session, il suffit de tourner hors d'état de session dans le site web.config.

<sessionState mode="Off" />

Je suis curieux, qu'en pensez-vous "un des Threads de la collection" pour devenir "thread-safe", si ce n'est pas utiliser des verrous?

Edit: je devrais sans doute expliquer par ce que j'entends par "exclusion de la plupart de ce verrou". N'importe quel nombre de lecture seule session ou pas de session de pages peuvent être traitées pour une session donnée en même temps sans bloquer les uns les autres. Cependant, une lecture-écriture-session de page ne peut pas commencer le traitement jusqu'à ce que toutes les demandes en lecture seule, et alors qu'il est en cours d'exécution, il doit disposer d'un accès exclusif à la session de cet utilisateur dans le but de maintenir la cohérence. Verrouillage sur les valeurs individuelles ne marcherait pas, parce que si on change de page d'un ensemble de valeurs liées en tant que groupe? Comment vous assurez-vous que d'autres pages en cours d'exécution dans le même temps, serait d'obtenir une vue cohérente de l'utilisateur, les variables de session?

Je suggère que vous essayez de réduire la modification des variables de session une fois qu'ils ont été définis, si possible. Cela vous permettra de faire la majorité de vos pages en lecture seule session de pages, ce qui augmente les chances que plusieurs demandes simultanées d'un même utilisateur ne serait pas bloquer les uns les autres.

J'ai commencé à utiliser le AngiesList.Redis.RedisSessionStateModule, qui part en utilisant le (très rapide) Redis serveur pour le stockage (je suis en utilisant le windows port -- mais il y a aussi un MSOpenTech port), il ne fait absolument pas le verrouillage de la session.

À mon avis, si votre application est structurée d'une manière raisonnable, ce n'est pas un problème. Si vous avez réellement besoin verrouillé et la cohérence des données dans le cadre de la session, vous devez mettre en œuvre un verrou/contrôle d'accès concurrentiel sur votre propre.

MS décider que chaque ASP.NET la session doit être verrouillé par défaut uniquement pour gérer la mauvaise conception de l'application est une mauvaise décision, à mon avis. Surtout parce qu'il semble comme la plupart des développeurs ne sont pas/ne réalisent même pas les sessions ont été verrouillés et, a fortiori, que les applications apparemment besoin d'être structuré de sorte que vous pouvez le faire en lecture seule session de l'etat autant que possible (opt-out, si possible).

À moins que votre application a spécialement besoin, je pense que vous avez 2 méthodes:

1. Ne pas utiliser de session à tous les
2. Session d'utilisation et d'effectuer fine tuning comme joel mentionné.

Session n'est pas seulement "thread-safe", mais aussi " l'état fort, d'une manière que vous savez que jusqu'à ce que la requête en cours est terminée, chaque variable de session ne changeront pas à partir d'une autre requête active. Pour que cela arrive, vous devez assurer cette session SERA VERROUILLÉ jusqu'à ce que la requête en cours est terminée.

Vous pouvez créer une session, comme le comportement de nombreuses façons, mais si elle ne permet pas de verrouiller la session en cours, il ne sera pas 'session'.

Pour les problèmes que vous avez mentionnés, je pense que vous devriez vérifier HttpContext.Actuel.Réponse.IsClientConnected. Ceci peut être utile pour éviter des exécutions et l'attend sur le client, bien qu'il ne peut pas résoudre ce problème, car cela peut être utilisé que par une mise en commun, et non pas async.

Pour ASPNET MVC, nous avons fait le suivant:

1. Par défaut, SessionStateBehavior.ReadOnly sur l'ensemble du contrôleur de l'action en substituant DefaultControllerFactory
2. Sur les actions du controller qui ont besoin de l'écriture à l'état de session, marque avec l'attribut de la mettre à l' SessionStateBehaviour.Required

Créer des ControllerFactory et remplacer GetControllerSessionBehaviour.

    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
{ }

Crochet jusqu'à la création de la fabrique de contrôleurs dans global.asax.cs

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

Maintenant, nous pouvons avoir les deux read-only et read-write l'état de session dans 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: ASPNET état de session peut toujours être écrit de même en readonly
mode et de ne pas jeter n'importe quelle forme d'exception (Il n'a tout simplement pas de verrouillage de
garantir la cohérence), de sorte que nous devons faire attention à la marque AcquireSessionLock dans du contrôleur actions qui nécessitent l'écriture de l'état de la session.

Juste pour aider quelqu'un à ce problème (demandes verrouillage lors de l'exécution d'un autre de 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 le Session_Start méthode (même vides) de la Mondiale.asax fichier.

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