À partir de votre propre lien :
Seules les opérations liées à l'E/S sont de bons candidats pour devenir des méthodes d'action asynchrones sur une classe de contrôleur asynchrone. Une opération liée à l'E/S est une opération qui ne dépend pas du processeur local pour être terminée. Lorsqu'une opération liée à l'E/S est active, le processeur attend simplement que les données soient traitées (c'est-à-dire, téléchargées) depuis un stockage externe (une base de données ou un service distant). Les opérations liées à l'E/S s'opposent aux opérations liées au processeur, où l'achèvement d'une tâche dépend de l'activité du processeur.
Les pages asynchrones ne sont pas gratuites, elles ont un coût. Elles sont généralement bonnes lorsque votre page effectue un appel externe à un service ou exécute une opération longue, non liée au processeur. Sinon, vous risquez de saturer le processeur, ce qui vous laisserait dans une situation pire qu'avant la mise en asynchrone.
L'idée est d'utiliser l'asynchrone lorsque vous utilisez un thread du pool de threads de votre application pour effectuer un travail non intensif en CPU (en attente d'une réponse d'un service long en cours). De cette manière, votre application peut continuer à traiter les demandes et ne commence pas à mettre en file d'attente de nouvelles demandes, drainant lentement la réactivité de votre application.
Voici un autre lien avec des informations sur quand/quand ne pas utiliser les pages asynchrones.
Modifier
En ce qui concerne ce qui est considéré comme "longue durée", vous obtenez la réponse médiocre "Cela dépend". Pour le savoir, vous devriez profiler votre application, voir combien de vos demandes "longues durées" font que les demandes ultérieures soient mises en file d'attente, au lieu d'être traitées, par IIS. La décision revient à se retrouver dans une situation où payer le coûteux péage du changement de contexte est inférieur au retour que vous allez obtenir en le faisant. Si votre goulet d'étranglement est une certaine page ou un service qui cause le blocage des demandes entrantes, il est probablement judicieux de commencer à envisager un travail asynchrone. Mais, vous pourriez aussi faire trop de travail dans la demande et cela pourrait être un "code smell" indiquant que vous devriez refactoriser votre code.
En fin de compte, Cela dépend.
Voici un extrait de MSDN.
En général, utilisez des pipelines asynchrones lorsque les conditions suivantes sont remplies :
-
Les opérations sont liées au réseau ou à l'E/S au lieu d'être liées au processeur.
-
Les tests montrent que les opérations bloquantes sont un goulot d'étranglement dans les performances du site et que IIS peut traiter plus de demandes en utilisant des méthodes d'action asynchrones pour ces appels bloquants.
-
La parallélisme est plus important que la simplicité du code.
-
Vous voulez fournir un mécanisme permettant aux utilisateurs d'annuler une demande longue.
Alors que le lien concerne MVC, l'idée est également valable pour d'autres variantes d'ASP.NET.
