.NET WebService IPC - Devrait-il être fait pour minimiser certaines opérations coûteuses?

Question

Je suis à la recherche de différentes approches à un problème: le client demande un travail, certaines choses sont faites et un résultat (ok/error) est renvoyé. Un service web .NET semble définitivement être la solution, mon seul problème est que le "truc" consistera à créer et à démanteler une session pour chaque requête. Est-ce que l'abstraction de la «substance» dans une application (qui garderait une seule session active, et traiterait la demande du service Web) semble être la bonne façon de procéder? (et si oui, quelle méthode de communication)

Le temps de travail est négligeable, mon souci est le martelage que les serveurs de transaction en question obtiendront probablement si je crée/abandonne une session pour chaque travail.

Une forme de communication IPC ou socket est-elle une solution réalisable ici?

Réflexions/commentaires/expériences très appréciés.

Edit: Après un peu plus de recherche, il semble que l'hébergement d'un service WCF dans un service Windows est probablement une meilleure façon d'aller ...

Answer 1

bien, on y va:

• Ne configurez pas un nouveau canal de communication pour chaque requête. Côté client/côté serveur, utilisez les implémentations WCF et assurez-vous que le client ne reçoit pas un nouveau procxy pour chaque appel;) Surtout avec la configuration de canal HTTPS qui coûte cher. N'appelez pas le service;) SImple que cela - faites aussi peu d'appels que POSSIBLES. Avoir une interface grossière optimisée pour ne pas faire beaucoup d'appels. Autoriser le traitement par lots des résultats Par exemple "GetInvoice" pourrait être "GetDocuments" - renvoyer non seulement une facture, et en prenant plusieurs ID, renvoyant plusieurs documents. Une liste de 30 factures passe de 30 appels à 1. Sinon, une approche par bus de messagerie peut fonctionner - j'en utilise une comme celle-ci et transporte jusqu'à 1024 messages par appel. Essayez de ne pas utiliser un service Web si vous avez une tonne de charge. Utilisez la liaison WCF et NetTcp (qui est binaire et n'utilise pas HTTP, ce n'est donc pas un service Web). Les frais généraux HTTP sont énormes - regardez google, quelqu'un a fait un test et nous parlons net tcp étant parfois environ 900 fois plus rapide. Surtout si vous faites peu de travail et avez perdu des utilisateurs cela peut augmenter l'évolutivité. Négatif - vous n'êtes plus que WCF du côté client, plus de "Web Service".

C'est à peu près tout ce que vous pouvez faire. Avec des pertes différentes, mais voici comment améliorer les performances;) Si vous parlez d'IPC uniquement en utilisant des tubes nommés, même les tubes nommés net.tcp sont très efficaces (en utilisant la mémoire partagée entre les processus), mais limités à la même machine dans l'implémentation .NET.