Dois-je utiliser le traitement asynchrone?

J'ai un service Windows qui surveille une table (avec une minuterie) pour les lignes, attrape les lignes une à la fois lorsqu'elles apparaissent, soumet l'information à un service Web RESTful, analyse la réponse et écrit quelques détails sur le réponse à une table. Est-ce que je gagnerais n'importe quoi en rendant cet asynchrone? Mon actuelle (dépouillée) Code de soumission de service Web est la suivante:Dois-je utiliser le traitement asynchrone?

HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create(new Uri(url)); 
HttpWebResponse resp; 
try 
{ 
     resp = (HttpWebResponse)req.GetResponse(); 
} 
catch (WebException we) 
{ 
     resp = (HttpWebResponse)we.Response; 
} 

if (resp != null) 
{ 
     Stream respStream = resp.GetResponseStream(); 
     if (respStream != null) 
     { 
      responseBody = new StreamReader(respStream).ReadToEnd(); 
     } 

     resp.Close(); 
     respStream.Close(); 
} 

return responseBody;

Source

2012-12-10 DerPflug

Si vous n'avez pas à faire quelque chose en même temps et que l'utilisateur n'est pas impliqué, certainement pas. Comme c'est un service, un autre thread peut accomplir n'importe quelle autre activité requise. – kenny

Il peut être utile d'obtenir une réponse plus détaillée si vous pouvez détailler quelques détails: quelle est la quantité typique d'enregistrements que vous devrez traiter dans un laps de temps x? Quel est le flux de votre programme? (Signification, tirez-vous un enregistrement, déclenchez la requête, attendez la réponse, mettez à jour la BD, obtenez l'enregistrement suivant, répétez, ou avez-vous un autre flux?) –

Sauf si votre service Windows est vraiment occupé à faire autre chose et vous ne voulez pas qu'il attende une réponse, je ne vois vraiment pas l'intérêt de faire cette async. Par contre, je dois préciser que WebResponse (et donc HttpWebResponse), Stream et StreamReader implémentent tous IDisposable et doivent être éliminés. – Pete

Si vous ne vous souciez pas du temps nécessaire pour obtenir une réponse à une demande individuelle, non, il n'y a pas de raison particulière de la rendre asynchrone. Par contre, si vous attendez qu'une requête soit complètement terminée avant de lancer votre prochaine demande, vous pourriez avoir des problèmes à gérer un gros volume. Dans ce scénario, vous pouvez envisager de paralléliser votre code. Mais cela ne vaut la peine d'être discuté que si vous obtenez un grand nombre d'éléments entrés dans la base de données pour traitement.

Source

2012-12-10 22:12:37

Comment ça? S'il a un client qui se connecte à DB, obtient une nouvelle ligne et déclenche une demande au service distant, attend la réponse et l'enregistre dans la base de données, puis obtient la ligne suivante - ce n'est pas un processus parallèle. Il pourrait être utile d'avoir le déroulement du programme détaillé pour nous. EDIT - Je jure qu'il y avait un commentaire auquel je répondais - maintenant je ressemble à un cinglé! –

Merci à tous pour votre contribution. C'est le genre d'information que je cherchais. – DerPflug

En utilisant des méthodes asynchrones vous évitez la nécessité d'avoir un fil dédié de blocage sur les résultats de l'opération async. Vous pouvez libérer ce thread pour travailler sur d'autres tâches plus productives jusqu'à ce que la tâche asynchrone soit terminée et qu'il soit de nouveau productif.

Si votre service n'est pas très sollicité et qu'il n'est pas fréquemment dans une position où vous avez besoin de plus de travail que de threads pour le faire, vous n'avez pas besoin de vous inquiéter. Pour de nombreuses applications professionnelles, ils ont simplement des taux d'utilisation si faibles que cela n'est pas nécessaire.

Si vous avez une application à grande échelle desservant suffisamment d'utilisateurs pour lesquels vous avez un très grand nombre de requêtes simultanées (même si ce n'est que pendant les heures de pointe), il peut être nécessaire de passer à des homologues asynchrones.

Source

2012-12-10 22:11:56 Servy

J'ai compris qu'il ne s'agissait pas du code de service dont il parle mais de son code client qui soumet des données au service et attend une réponse. Le commentaire sur l'utilisation d'async pour libérer le thread jusqu'à ce qu'une réponse arrive est toujours valide - juste généralement moins important du côté du client que du serveur. Si c'était le serveur, je ferais probablement l'effort. –

Dois-je utiliser le traitement asynchrone?

Répondre

Questions connexes