Langage C#
  1. Langage C#
  3. PerSession vs PerCall
Intereting Posts
Comment puis-je arrêter l’inheritance web.config Renvoyer xml ou json de l’API web MVC en fonction de la demande Mise en page correcte de la structure à partir de la notice enregistrée Lecture de fichier MP3 en C # Comment fusionner (ou compresser) deux IEnumerables ensemble? Odeur de code logique de validation métier Mettre à jour uniquement certaines propriétés sur une entité EF qui ne sont pas définies sur null Zedgraph – comment personnaliser les tics X-Axis basés sur la date Problème d’interopérabilité C # et Excel, l’enregistrement du fichier Excel n’est pas fluide Un object Dapper DynamicParameters peut-il être énuméré comme un dictionnaire de parameters? Le pilote RabbitMQ C # cesse de recevoir des messages json.net ne sérialise pas les propriétés de la classe dérivée Comment et quand abandonner l’utilisation des tableaux en C #? Collection de dictionnaire nested dans .NET Génération de GS1 DataMasortingx avec ZXing.Net

PerSession vs PerCall

Quelle est la règle générale pour décider d’utiliser PerSession ou PerCall?

J’ai un service WCF un peu lourd (je pense ..), contenant des méthodes CRUD à environ 80 tables.

J’ai divisé le service WCF en 7 contrats au sein d’un service (c.-à-d. 7 points finaux au sein d’un service), de sorte que chaque contrat prenne en charge son propre domaine. Par exemple, j’ai un contrat de vente. Toutes les tables liées aux ventes et les opérations correspondantes se situent dans le “contexte délimité” des ventes

Donc, ma structure de service WCF ressemble à ceci: 

public partial class ABCService : ISalesService { //CRUD methods of all tables related to Sales } public partial class ABCService : IMarketingService { //CRUD methods of all tables related to Marketing } public partial class ABCService : ICustomerService { //CRUD methods of all tables related to Customer } public partial class ABCService : IProductService { //CRUD methods of all tables related to Products }

Mon problème avec PerCall est que, du fait que je dispose d’un service DB / WCF assez important, je crains que la quantité de ressources consommée par chaque appel, multipliée par le nombre d’utilisateurs et la vitesse à laquelle ils appellent le service, serait beaucoup trop grand.

Je ne connais pas les détails, mais j’ai lu que la création d’un proxy de canal est une opération coûteuse.

Oh, j’utilise des proxies codés manuellement au lieu de la référence de service Add de VS pour utiliser mon service WCF.

Donc, ma question est, que devrais-je utiliser? PerSession ou PerCall?

Mettre à jour:

  1. Je n’ai pas besoin de maintenir l’état entre les appels.
  2. J’utilise des liaisons NetTCP

A mon avis, pour prendre une décision, considérez ces deux points

  1. Pour utiliser InstanceContextMode.PerSession – Si vos utilisateurs ont des valeurs de session stockées sur le service WCF sur le serveur.
  2. Pour utiliser InstanceContextMode.PerCall – Si vos utilisateurs n’ont rien stocké en session sur le service WCF sur le serveur, c’est-à-dire que le service WCF nécessite Aucun paramètre par utilisateur requirejs pour le stockage en mémoire. Nécessite une évolutivité.

Quelques points concernant Quand et pourquoi?

InstanceContextMode.PerCall

  • Si votre service est sans état et évolutif, les avantages sont similaires à ceux de HTTP car ils sont également sans état.
  • Si le service a un code d’initialisation léger (ou aucun code).
  • Si votre service est à thread unique.
  • Exemple de scénario: Pour 1 000 demandes de clients dans une période donnée dans une situation PerCall , il n’y aura que 100 objects instanciés pour 100 appels actifs . Deuxièmement, si le serveur devait tomber en PerCall dans la situation PerCall , les seules erreurs qui se produiraient concerneraient les 100 demandes réelles en cours (en supposant un basculement rapide). Les 900 autres clients pourraient être routés vers un autre serveur lors de leur prochain appel.

InstanceContextMode.PerSession

  • Si votre service doit maintenir un certain état entre les appels du même client.
  • Si votre service a un code d’initialisation léger (ou aucun code). Même si vous n’obtenez qu’une nouvelle instance pour chaque proxy client, vous devez néanmoins faire attention à ne pas avoir un code d’initialisation coûteux dans un constructeur.
  • Exemple de scénario: Pour 1 000 demandes de client dans une période donnée dans une situation de PerSession , vous pouvez avoir 1 000 objects instanciés sur le serveur, mais seulement 100 sont réellement actifs en appel à tout moment. Ainsi, les objects PerSession instanciés peuvent constituer un gaspillage de ressources et avoir une incidence sur la capacité de répondre aux demandes sous charge. Deuxièmement, si le serveur devait tomber en panne, alors dans PerSession les 1 000 clients ayant une session sur ce serveur perdraient leur session et seraient incapables de terminer leur travail.

Liens de référence:

  1. MSDN – Instanciation, simultanéité et limitation WCF
  2. SO – Par appel ou par session
  3. MSDN – Utilisation de sessions dans un contexte WCF

La raison pour laquelle vous ne voyez pas beaucoup de réponses à ce type de question en ligne est que cela dépend. Ce que je voudrais faire est de l’essayer – puis ouvrez perfmon sur le serveur sur lequel vous hébergez le service et ajoutez les compteurs pour votre service. Si vous n’êtes pas familier, utilisez simplement Google wcf performance manager.

La bonne nouvelle est que WCF facilite les modifications de configuration.

Si vous êtes préoccupé par le coût de l’instanciation d’un proxy côté client, rappelez-vous que perCall est un comportement de service, pas un comportement de client. Même si vous définissez le contexte d’instance de service sur PerCall, vous pouvez toujours créer une instance de votre proxy et effectuer un ensemble d’appels de méthode à partir de ce proxy. Tout ce que perCall signifie, c’est que lorsque vous appelez, une instance du service est créée, votre méthode est appelée et l’instance du service est à nouveau détruite. Si vous n’avez pas d’initialisation coûteuse sur l’instance de service (c’est-à-dire s’il s’agit de méthodes essentiellement statiques), vous êtes probablement d’accord avec chaque appel.