Je crée une nouvelle API net core 2.2 à utiliser avec un client JavaScript. Certains exemples dans Microsoft ont le contrôleur ayant toutes les méthodes asynchrones et d'autres non. Les méthodes de mon API doivent-elles être asynchrones. Utilisera IIS si cela est un facteur. Un exemple de méthode impliquera d'appeler une autre API et de renvoyer le résultat tandis qu'une autre fera une requête de base de données en utilisant entity Framework.
3 Réponses :
Il est recommandé d'utiliser async pour les méthodes de votre contrôleur, surtout si vos services font des choses comme accéder à une base de données. Que vos méthodes de contrôleur soient asynchrones ou non n'a pas d'importance pour IIS, le moteur d'exécution .net les invoquera. Les deux fonctionneront, mais vous devriez toujours essayer d'utiliser async lorsque cela est possible.
Ok merci, j'ai un collègue qui fait la plupart du travail jusqu'à présent et il ne fait aucune méthode asynchrone. Quand j'essaye d'ajouter async, c'est comme sauter à travers un terrier de lapin parce qu'alors je dois changer beaucoup d'autres choses et certaines des méthodes qu'il a écrites, je ne sais pas comment je vais les rendre asynchrones, elles impliquent une fonction générique. Merci quand même pour les conseils.
Ouais, c'est en fait tout à fait normal. La conversion d'un programme non asynchrone en programme asynchrone a été comparée à la «propagation d'un virus» msdn.microsoft.com/en-us/magazine/jj991977.aspx Le problème de base est le fait que s'il est facile d'appeler du code synchrone à partir d'une fonction asynchrone, il n'est pas si facile d'appeler une fonction asynchrone à partir du code synchrone. Cela signifie que vous devez démarrer tous vos éléments asynchrones à la racine de votre pile d'appels.
Tout d'abord, vous devez comprendre ce que fait async. En termes simples, cela permet au thread traitant la demande d'être renvoyé au pool pour traiter d'autres demandes, si le thread entre dans un état d'attente. Ceci est presque invariablement causé par des opérations d'E / S, telles que l'interrogation d'une base de données, l'écriture / la lecture d'un fichier, etc. Les travaux liés au processeur tels que les calculs nécessitent une utilisation active du thread et ne peuvent donc pas être traités de manière asynchrone. Un autre avantage de l'async est la possibilité «d'annuler» le travail. Si le client ferme la connexion prématurément, cela déclenchera un jeton d'annulation qui peut être utilisé par les méthodes asynchrones prises en charge pour annuler le travail en cours. Par exemple, en supposant que vous ayez passé le jeton d'annulation dans un appel à quelque chose comme ToListAsync () , et que le client ferme la connexion, EF verra cela et annulera ultérieurement la requête. C'est en fait un peu plus complexe que cela, mais vous voyez l'idée.
Par conséquent, vous devez simplement évaluer si async est bénéfique dans un scénario particulier. Si vous allez effectuer des E / S et / ou souhaitez pouvoir annuler le travail en cours, passez à l'asynchrone. Sinon, vous pouvez vous en tenir à la synchronisation, si vous le souhaitez.
Cela dit, bien qu'il y ait un léger coût de performance pour l'asynchrone, il est généralement négligeable, et les avantages qu'il offre en termes d'évolutivité valent généralement le compromis. En tant que tel, il est préférable de toujours rester asynchrone. De plus, si vous faites quoi que ce soit de manière asynchrone, votre action doit également être asynchrone. Par exemple, tout ce que fait EF Core est asynchrone. Les méthodes "sync" ( ToList plutôt que ToListAsync ) se contentent de bloquer les méthodes asynchrones. En tant que tel, si vous effectuez une requête via EF, utilisez async. Les méthodes de synchronisation ne sont là que pour prendre en charge certains scénarios limités où il n'y a pas d'autre choix que de traiter la synchronisation, et dans de tels cas, vous devez exécuter dans un thread séparé ( Task.Run ) pour éviter les blocages.
<₹UPDATE
Je dois également mentionner que les choses sont un peu floues avec les actions et en particulier les gestionnaires de pages Razor. Il existe un pipeline de requêtes complet, dont une action / un gestionnaire fait partie. Avoir une action "sync" n'empêche pas de faire quelque chose de asynchrone dans votre vue, ou dans un gestionnaire de règles, un composant de vue, etc. L'action elle-même ne doit être asynchrone que si elle effectue elle-même une sorte de travail asynchrone.
Les gestionnaires de pages Razor, en particulier, seront souvent synchronisés, car très peu de traitement se produit généralement dans le gestionnaire lui-même; tout est dans les processus subordonnés.
Async est un concept très important à comprendre et Microsoft se concentre trop sur cela. Mais parfois, nous ne réalisons pas l'importance de cela. Chaque fois que vous n'utilisez pas Async, vous bloquez le fil de l'appelant.
Pourquoi utiliser Async
Même si votre contrôleur API utilise une seule opération (disons DB fetch), vous devriez utiliser Async. La raison en est que votre serveur a un nombre limité de threads pour traiter les demandes des clients. Supposons que votre application puisse gérer 20 requêtes et que si vous n'utilisez pas Async, vous bloquez le thread du gestionnaire pour effectuer l'opération (opération DB) qui pourrait être effectuée par un autre thread (Async). À son tour, votre file d'attente de demandes augmente parce que votre thread principal est occupé à traiter d'autres choses et ne peut pas s'occuper de nouvelles demandes, à un moment donné, votre application cessera de répondre. Si vous utilisez Async, le thread principal est libre de gérer plus de requêtes client tandis que les autres opérations s'exécutent en arrière-plan.
Plus de ressources
Je recommanderais certainement de regarder la vidéo officielle très informative de Microsoft sur les problèmes de performances. https://www.youtube.com/watch?v=_5T4sZHbfoQ