Quel est l’avantage d’utiliser async avec MVC5?
Quelle est la différence entre:
public ActionResult Login(LoginViewModel model, ssortingng returnUrl) { if (ModelState.IsValid) { IdentityResult result = IdentityManager.Authentication.CheckPasswordAndSignIn(AuthenticationManager, model.UserName, model.Password, model.RememberMe); if (result.Success) { return Redirect("~/home"); } else { AddErrors(result); } } return View(model); } et:
[HttpPost] [AllowAnonymous] [ValidateAntiForgeryToken] public async Task Login(LoginViewModel model, ssortingng returnUrl) { if (ModelState.IsValid) { IdentityResult result = await IdentityManager.Authentication.CheckPasswordAndSignInAsync(AuthenticationManager, model.UserName, model.Password, model.RememberMe); if (result.Success) { return Redirect("~/home"); } else { AddErrors(result); } } return View(model); }
Je vois que le code MVC a maintenant async mais quelle est la différence. Est-ce qu’on donne une bien meilleure performance que l’autre? Est-il plus facile de déboguer des problèmes avec l’un que l’autre? Dois-je modifier d’autres contrôleurs pour que mon application ajoute Async?
- Configurez Microsoft.AspNet.Identity pour autoriser l’adresse e-mail en tant que nom d’utilisateur
- ASP.NET Identity default Mot de passe Hasher, comment ça marche et est-il sécurisé?
- Quelles sont les revendications dans ASP .NET Identity
- ASP.NET_SessionId + OWIN Les cookies ne sont pas envoyés au navigateur.
- Comment obtenir l’utilisateur actuel et comment utiliser la classe User dans MVC5?
- Appel Webapi non autorisé renvoyant la page de connexion au lieu de 401
- Quelle est l’interface IUserSecurityStampStore d’ASP.NET Identity?
- ASP.NET Identity DbContext confusion
- Comment puis-je modifier les noms de table lors de l’utilisation de Visual Studio 2013 ASP.NET Identity?
- ASP.NET MVC 5 – Identité. Comment obtenir l’application utilisateur actuelle
Les actions asynchrones ne sont utiles que lorsque vous effectuez des opérations liées aux E / S, telles que les appels de serveur à distance. L’avantage de l’appel asynchrone est que, pendant l’opération d’E / S, aucun thread de travail ASP.NET n’est utilisé. Alors, voici comment fonctionne le premier exemple:
- Lorsqu’une demande frappe l’action, ASP.NET extrait un thread du pool de threads et commence à l’exécuter.
- La méthode
IdentityManager.Authentication.CheckPasswordAndSignInest appelée. Ceci est un appel bloquant -> pendant tout l’appel, le thread de travail est en danger.
Et voici comment fonctionne le deuxième appel:
- Lorsqu’une demande frappe l’action, ASP.NET extrait un thread du pool de threads et commence à l’exécuter.
-
IdentityManager.Authentication.CheckPasswordAndSignInAsyncest appelé et renvoie immédiatement. Un port d’achèvement d’E / S est enregistré et le thread de travail ASP.NET est publié sur le pool de threads. - Plus tard, une fois l’opération terminée, le port d’achèvement des E / S est signalé, un autre thread est créé à partir du pool de threads pour terminer le retour de la vue.
Comme vous pouvez le voir dans le second cas, les threads de travail ASP.NET ne sont utilisés que pendant une courte période. Cela signifie qu’il y a plus de threads disponibles dans le pool pour servir d’autres requêtes.
Pour conclure, utilisez des actions asynchrones uniquement lorsque vous disposez d’une véritable API asynchrone. Si vous faites un appel bloquant dans une action asynchrone, vous en détruisez tout le bénéfice.
Normalement, une seule requête HTTP serait gérée par un seul thread, supprimant complètement ce thread du pool jusqu’à ce qu’une réponse soit renvoyée. Avec la TPL, vous n’êtes pas lié par cette contrainte. Toute requête entrant commence une suite avec chaque unité de calcul requirejse pour calculer une réponse capable de s’exécuter sur n’importe quel thread du pool. Avec ce modèle, vous pouvez gérer beaucoup plus de requêtes simultanées qu’avec ASP.Net standard.
Si c’est une nouvelle tâche qui sera générée ou non, et si elle doit être attendue ou non. Pensez toujours à ces 70 ms, soit env. le max. heure à laquelle tout appel de méthode devrait prendre. Si c’est plus long, alors votre interface utilisateur ne sera probablement pas très sensible.
Dans les applications Web qui détectent un grand nombre de demandes simultanées au démarrage ou qui ont une charge en rafale (lorsque la concurrence augmente soudainement), rendre ces appels de service Web asynchrones augmentera la réactivité de votre application. Une requête asynchrone prend le même temps de traitement qu’une requête synchrone. Par exemple, si une demande effectue un appel de service Web nécessitant deux secondes, la demande prend deux secondes, qu’elle soit synchrone ou asynchrone. Toutefois, lors d’un appel asynchrone, un thread n’est pas bloqué pour répondre aux autres demandes pendant qu’il attend la première demande. Par conséquent, les requêtes asynchrones empêchent la mise en queue des demandes et la croissance du pool de threads lorsqu’il existe de nombreuses demandes concurrentes appelant des opérations de longue durée.