J'utilise async / attendre en MVC, mais seulement lorsque j'ai plus d'une tâche (Watierall).
Je comprends qu'avoir une seule tâche est bon d'avoir l'interface utilisateur libre, en cas de formulaire WPF ou Windows, mais il est logique que MVC n'ait qu'une tâche et attendre cela?
Je l'ai beaucoup vu en code, en MVC, mais je ne reçois pas les avantages.
3 Réponses :
Cela dépend de ce que vous essayez d'atteindre. Par exemple, si vous avez plusieurs appels à plusieurs services, vous pouvez toujours le faire de manière à ce que seul le dernier appel facilite le reste du système "attendre".
Vous pouvez optimiser votre code d'une manière que x appelle asynchroneusement Les services commencent (presque) en même temps sans devoir «attendre» l'un pour l'autre. J'espère que cela aide.
C'est, merci. Mais si je n'ai qu'un seul service. J'appelle à une action qui appelle à un seul service. Est-il recommandé de faire tous les asynchronisation (le service et l'action dans le contrôleur)? - En gros, c'est ce que je veux savoir. Et si je dois faire des tâches, il est sage en fonction de l'attente d'un ou d'attendre l'autre?
bonne question. L'utilisation de méthodes asynchrones consiste à utiliser efficacement les ressources et à donner une bonne expérience utilisateur. Chaque fois que vous devez appeler sur une ressource pouvant prendre le temps de collecter, il est bon d'utiliser un appel ASYNC.
Cela fera quelques choses. Premièrement, tandis qu'un thread de travailleur attend des données, il peut être mis sur "Hold" afin de parler et que le thread de travailleur peut faire autre chose jusqu'à ce que les données soient renvoyées, une erreur est renvoyée ou l'appel est juste terminé.
Cela vous donnera le deuxième avantage. L'interface que l'utilisateur utilise pour appeler la ressource sera libérée, temporairement, pour faire d'autres choses. Et dans l'ensemble, moins de ressources de serveur sont consommées par des processus inactifs.
Je recommanderais de regarder les vidéos sur cette page ici: HTTPS : //channel9.msdn.com/series/three-essential-tips-for-async
C'est probablement l'explication la plus rapide qui puisse aider à sauter votre apprentissage sur Async.
Pouvez-vous expliquer cela? "Cela vous donnera le deuxième avantage. L'interface que l'utilisateur utilise pour appeler la ressource sera libérée, temporairement, pour effectuer d'autres choses. Et globalement, moins de ressources du serveur sont consommées par des processus inactifs."
Pensez à aller à une banque. Il y a trois caisses disponibles. Il y a 50 personnes en ligne pour voir un caissier. Si le caissier doit gérer tous les processus, tels que des processus nécessitant une signature de gestionnaire, par exemple, la ligne se déplace très lentement. Mais si le caissier pouvait expédier le client à un représentant secondaire, ils peuvent prendre le prochain client. Une fois que le représentant obtient la signature du gestionnaire, le caissier pourrait ensuite ramener cette personne une fois qu'ils ont terminé avec leur client actuel. Ceci dans une version simplifiée est ce qui se passe.
Cela s'appliquerait si c'était une application d'interface utilisateur WPF (Windows Forms, WPF). Si c'est ASP.NET, vous parlez au site Web de votre banque, pas votre caissier de banque. Vous n'avez aucun moyen de savoir ce qu'ils font et de la façon dont là-bas.
Donc, pour MVC, ça ne vaut pas la peine. À droite? Parce que l'interface utilisateur ne gèle pas comme sur les formulaires WPF / Windows
En fait, pour MVC, il devient plus important. Il existe une quantité finie de ressources attribuées par un serveur pour le traitement des appels. Retour à l'histoire de Teller ci-dessus. À l'aide d'ASYNC correctement vous permettra de conserver toutes les threads attribués à différentes couches occupées avec des tâches et de ne pas avoir de tâches qui attendent d'autres choses à compléter. Une fois que les ressources sont épuisées, les nouvelles demandes Web doivent attendre leur tour, comme debout en ligne à la banque.
Les demandes HTTP sont traitées par des filets de piscine de fil.
Si vous bloquez un fil, il ne sera pas en mesure de faire d'autres travaux. Étant donné que le nombre total de threads est limité, cela peut conduire à la famine de la piscine de thread et de nouvelles demandes sera refusée - 503.
Utilisation du code ASYNC, le thread est renvoyé dans le pool de threads, devenant disponible pour gérer de nouvelles demandes ou les continuations du code ASYNC.
Comme sur le client UIS, sur le serveur, le code ASYNC est tout sur la réactivité, pas la performance. Les demandes prendront plus de temps mais votre serveur sera en mesure de gérer plus de demandes.
Est-ce un "oui" (utilise toujours une tâche asynchrone
NON. Seulement si vous avez quelque chose d'asynchrone à invoquer. N'utilisez pas la tâche .Run , car il n'utilisera que davantage de fils de piscine de fil.
Merci, Paulo. Mais si tout ce que j'ai dans une action est un simple linq à SQL. Devrais-je utiliser Tolistasync () au lieu de tolisser () et faire la tâche d'action
Oui, car au lieu d'être bloqué en attente de la réponse de la base de données, le thread peut être utilisé pour gérer une autre demande.
waiterall est la méthode de blocage, ce n'est pas une bonne idée d'utiliser avec le code asynchrone"Je crois comprendre qu'avoir une seule tâche est bon d'avoir l'interface utilisateur libre" - Où avez-vous entendu ça?
Vous devriez lire sur
async attendre . C'est une abstraction qui fuit et vous devez savoir comment cela fonctionne sous la capuche pour l'utiliser avec succès.Démarrer ici et lisez tout articles dans cette section. Ensuite, lisez Stephen Cleary's Articles sur Async / Await.
Si vous exécutez une application Web, vous exécutez une application très multi-threadée. Chaque demande ASP.NET est desservie par un fil de piscine différent. Ce que
attendre est vous permettant de Stepez votre fil de l'exécution et faites du travail. Dans une application Web, vous ne devez vraiment être queattendre ing d'opérations d'E / S, mais, Async et vous vous attendez vous permettant de faire ces opérations à l'éloignement du fil de la requête.