async Task<HttpResponseMessage> Get VS HttpResponseMessage Obtenir

J'aurais besoin de votre aide pour la suite. Pendant près d'un mois, j'ai lu au sujet des Tâches et asynchrone .

Je voulais essayer de mettre en œuvre mes nouveaux acquis knowledege, dans un simple wep projet d'api. J'ai l'une des méthodes suivantes et deux d'entre eux fonctionne comme prévu:

 public HttpResponseMessage Get()
 {
        var data = _userServices.GetUsers();
        return Request.CreateResponse(HttpStatusCode.OK, data);
 }

public async Task<HttpResponseMessage> Get()
{
        var data = _userServices.GetUsers();


        return await Task<HttpResponseMessage>.Factory.StartNew(() =>
        {
           return Request.CreateResponse(HttpStatusCode.OK, data);
        });
 }

Donc la question. J'ai essayé d'utiliser le violoneux, et de voir quelle est la différence entre ces deux. L'asynchrone est un peu plus rapide, mais à part ça, quel est le réel avantage dans la mise en œuvre de quelque chose comme ça dans une api web?

Eh bien, tout d'abord, merci à vous tous pour avoir répondu à l'arrière. Vous m'avez donné quelques "travail à domicile" à faire.Je comprends que l'Usine.StartNew est terrible car il démarre un nouveau thread à chaque demande! Je comprends aussi que le "fonctionnement asynchrone" doit être transmis jusqu'au dépôt, les sens tout le chemin jusqu'à GetUsers (Service) --> GetUsersAsync (Référentiel). Donc, nous aurons une chaîne de méthodes asynchrones , tout le chemin jusqu'à référentiel. Le respository pour la mise en œuvre d'un modèle qui prend en charge les opérations asynchrones ie Asynchrone Ado.Net ou EntityFramework.
Si j'étais à construire cette Api Web, je voudrais commencer avec 3 couches 1) Présentation 2) et 3) du Référentiel. Le référentiel permettrait de mettre en œuvre Async Ado.Net ou Entityframework . En outre, tout cela va se passer sur le thread principal, mais avec des opérations ASYNCHRONES. J'ai essayé de le "dévorer" la théorie dans le livre suivant Multithreading En C# 5.0 livre de cuisine.Il semble que toute cette connaissance est foiré dans ma tête,alors, toutes mes excuses,si vous me trouvez répéter les choses. Je vais poster le code qui explique ce que "je pense", je comprends. Je vous serais reconnaissant si vous pouvez tous contribuer ainsi activement à nouveau !!

OriginalL'auteur Veronica_Zotali | 2014-09-18

22

Comme d'autres l'ont souligné, le point de async sur ASP.NET est ce que ça libère l'un des ASP.NET le pool de threads. Cela fonctionne très bien pour naturellement-les opérations asynchrones tels que les I/O-les opérations liées parce que c'est moins un thread sur le serveur (il n'y a pas de fil qui est "traitement" de l'opération asynchrone, comme je l'explique sur mon blog). Ainsi, le principal avantage de async sur le côté serveur est évolutivité.

Cependant, vous voulez éviter Task.Run (et, pire encore, Task.Factory.StartNew) sur ASP.NET. J'appelle ce "faux asynchronie", car ils font juste synchrone/blocage de travailler sur un thread du pool. Ils sont utiles dans les applications d'INTERFACE utilisateur où vous voulez aller travailler hors de la thread d'INTERFACE utilisateur pour que l'INTERFACE utilisateur reste sensible, mais ils doivent (presque) jamais être utilisé sur ASP.NET ou d'un autre serveur d'applications.

À l'aide de Task.Run ou Task.Factory.StartNew sur ASP.NET seront effectivement diminuer votre évolutivité. Ils seront la cause de certains thread inutile de commutateurs. Pour la durée des opérations, vous pourriez finir vers le haut de jeter hors de la ASP.NET pool de threads heuristiques, causant des threads supplémentaires à être créé puis détruit inutilement. J'explore ces problèmes de performances étape-par-étape dans un autre post de blog.

Donc, vous devez penser à ce que chaque action est en train de faire, et si tout cela devrait être asynchrone. Si elle devrait, alors que l'action doit être asynchrone. Dans votre cas:
```
public HttpResponseMessage Get()
{
  var data = _userServices.GetUsers();
  return Request.CreateResponse(HttpStatusCode.OK, data);
}
```
Qu'est-ce exactement Request.CreateResponse faire? C'est juste de la création de l'objet réponse. C'est - juste une fantaisie new. Il n'y a pas d'I/O qui s'y passent, et il n'est certainement pas quelque chose qui doit être poussé à un thread d'arrière-plan.

Cependant, GetUsers est beaucoup plus intéressant. Cela sonne plus comme une lecture de données, qui est I/O base. Si votre backend pouvez mettre à l'échelle (par exemple, SQL Azure, Tableaux, etc), alors vous devriez regarder à faire que async d'abord, et une fois que votre service est d'exposer un GetUsersAsync, cette action pourrait devenir async trop:
```
public async Task<HttpResponseMessage> Get()
{
  var data = await _userServices.GetUsersAsync();
  return Request.CreateResponse(HttpStatusCode.OK, data);
}
```
OriginalL'auteur Stephen Cleary
2

Il fait plus de sens lorsque l'appel se passe avec les grandes opérations d'e /s.
Oui, Async est plus rapide car elle permet de libérer le thread de demande pour le moment que les opérations sont réalisées. Ainsi, à partir de du serveur Web de point de vue, vous êtes de donner un fil de retour de la piscine qui peut être utilisé par le serveur pour les futurs appels à venir à travers.

Donc, pour par exemple, lorsque vous effectuez une opération de recherche dans SQL server, vous pouvez le faire async et de voir l'avantage de performance.

Il est bon pour l'évolutivité qui implique de multiples serveurs.

Donc, pour par exemple, lorsque le SearchRecordAsync envoie son SQL à la base de données, il renvoie une tâche incomplète, et si la demande frappe l'attendent, il renvoie la demande thread du pool de threads. Plus tard, lorsque la DB opération est terminée, un thread de demande est prise à partir du pool de threads utilisés pour poursuivre la demande.

Même si vous n'êtes pas à l'aide, les opérations SQL, disons que vous voulez envoyer un e-mail à 10 personnes. Dans ce cas également async a plus de sens.

Async est aussi très pratique pour montrer les progrès de l'événement. De sorte que l'utilisateur sera toujours obtenir les actifs de la GUI, et que la tâche est en cours d'exécution en arrière-plan.

À comprendre, jetez un oeil à cet exemple.

Ici, je suis en train de lancer la tâche envoyer de mail. En attendant j'souhaitez mettre à jour la base de données, alors que le fond est la réalisation d'envoyer mail tâche.

Une fois la base de données de mise à jour qui s'est passé, il est en attente pour l'envoi de courrier tâche à remplir. Cependant, avec cette approche, il est tout à fait clair que je peux exécuter la tâche à l'arrière-plan et de procéder à l'original (principale) de thread.
```
using System;
using System.Threading;
using System.Threading.Tasks;

public class Program
{
    public static void Main()
    {
        Console.WriteLine("Starting Send Mail Async Task");
        Task task = new Task(SendMessage);
        task.Start();
        Console.WriteLine("Update Database");
        UpdateDatabase();

        while (true)
        {
            //dummy wait for background send mail.
            if (task.Status == TaskStatus.RanToCompletion)
            {
                break;
            }
        }

    }

    public static async void SendMessage()
    {
        //Calls to TaskOfTResult_MethodAsync
        Task<bool> returnedTaskTResult = MailSenderAsync();
        bool result = await returnedTaskTResult;

        if (result)
        {
            UpdateDatabase();
        }

        Console.WriteLine("Mail Sent!");
    }

    private static void UpdateDatabase()
    {
        for (var i = 1; i < 1000; i++) ;
        Console.WriteLine("Database Updated!");
    }

    private static async Task<bool> MailSenderAsync()
    {
        Console.WriteLine("Send Mail Start.");
        for (var i = 1; i < 1000000000; i++) ;
        return true;
    }
}
```
Merci beaucoup pour la réponse. Disons que nous voulons construire une api web doit servir autant de demandes que possible par minute pour un volume élevé d'e-commerce. Nous n'avons pas opérations d'e / s mais supposons que nous avons peu coûteuse les opérations SQL. Si j'étais à décorer mes principaux points de terminaison asynchrones, serait-ce une bonne idée?
Hey mate, j'ai essayé avec le simple exemple de ce que je voulais dire avec async, c'est que comme le filetage, mais c'est moins casse-tête parce que le compilateur fait tout pour nous.

OriginalL'auteur codebased
1

À l'aide de async sur votre serveur peut considérablement améliorer l'évolutivité car il libère le fil de servir la demande pour gérer d'autres demandes tout le async opération est en cours. Par exemple, en mode synchrone IO operaton, le thread est suspendu et ne rien faire jusqu'à ce que l'opération est terminée et ne serait pas disponible pour servir une autre demande.

Cela étant dit, à l'aide de Task.Factory.StartNew commence un autre thread si vous n'obtenez pas l'évolutivité des avantages à tous. Votre fil d'origine peuvent être réutilisés, mais vous avez déchargé le travail à un autre thread, donc il n'y a pas d'avantage net à tous. il y a en effet un coût du passage à un autre thread, mais c'est minime.

Vraiment opérations asynchrones ne pas démarrer un thread et je veux le regarder pour voir si une telle opération existe, ou si l'on peut être écrit pour Request.CreateResponse. Ensuite, votre code sera beaucoup plus évolutif. Si non, vous êtes mieux de s'en tenir à l'approche synchrone.

OriginalL'auteur Ned Stoyanov

Vous devez vous connecter pour publier un commentaire.