Après cette question, cela me met à l'aise lors de l'utilisation d'opérations asynchrones dans ASP.NET MVC. J'ai donc écrit deux articles de blog à ce sujet:
J'ai trop de malentendus dans mon esprit sur les opérations asynchrones sur ASP.NET MVC.
J'entends toujours cette phrase: l' application peut mieux évoluer si les opérations s'exécutent de manière asynchrone
Et j'ai aussi beaucoup entendu ce genre de phrases: si vous avez un volume de trafic énorme, vous feriez peut-être mieux de ne pas effectuer vos requêtes de manière asynchrone - consommer 2 threads supplémentaires pour traiter une demande enlève des ressources aux autres demandes entrantes.
Je pense que ces deux phrases sont incohérentes.
Je n'ai pas beaucoup d'informations sur le fonctionnement de threadpool sur ASP.NET mais je sais que threadpool a une taille limitée pour les threads. Donc, la deuxième phrase doit être liée à cette question.
Et je voudrais savoir si les opérations asynchrones dans ASP.NET MVC utilisent un thread de ThreadPool sur .NET 4?
Par exemple, lorsque nous implémentons un AsyncController, comment se structure l'application? Si j'obtiens un trafic énorme, est-ce une bonne idée d'implémenter AsyncController?
Y a-t-il quelqu'un là-bas qui peut enlever ce rideau noir sous mes yeux et m'expliquer l'accord sur l'asynchronie sur ASP.NET MVC 3 (NET 4)?
Éditer:
J'ai lu ce document ci-dessous près de centaines de fois et je comprends le problème principal, mais j'ai toujours de la confusion car il y a trop de commentaires incohérents.
Utilisation d'un contrôleur asynchrone dans ASP.NET MVC
Éditer:
Supposons que j'ai une action de contrôleur comme ci-dessous (pas une implémentation de AsyncController
cependant):
public ViewResult Index() {
Task.Factory.StartNew(() => {
//Do an advanced looging here which takes a while
});
return View();
}
Comme vous le voyez ici, je lance une opération et l'oublie. Ensuite, je rentre tout de suite sans attendre qu'il soit terminé.
Dans ce cas, cela doit-il utiliser un thread de threadpool? Si tel est le cas, une fois terminé, qu'advient-il de ce fil? Est-ce qu'il GC
entre et nettoie juste après la fin?
Éditer:
Pour la réponse de @ Darin, voici un exemple de code asynchrone qui communique avec la base de données:
public class FooController : AsyncController {
//EF 4.2 DbContext instance
MyContext _context = new MyContext();
public void IndexAsync() {
AsyncManager.OutstandingOperations.Increment(3);
Task<IEnumerable<Foo>>.Factory.StartNew(() => {
return
_context.Foos;
}).ContinueWith(t => {
AsyncManager.Parameters["foos"] = t.Result;
AsyncManager.OutstandingOperations.Decrement();
});
Task<IEnumerable<Bars>>.Factory.StartNew(() => {
return
_context.Bars;
}).ContinueWith(t => {
AsyncManager.Parameters["bars"] = t.Result;
AsyncManager.OutstandingOperations.Decrement();
});
Task<IEnumerable<FooBar>>.Factory.StartNew(() => {
return
_context.FooBars;
}).ContinueWith(t => {
AsyncManager.Parameters["foobars"] = t.Result;
AsyncManager.OutstandingOperations.Decrement();
});
}
public ViewResult IndexCompleted(
IEnumerable<Foo> foos,
IEnumerable<Bar> bars,
IEnumerable<FooBar> foobars) {
//Do the regular stuff and return
}
}