Notre produit est développé sur la plate-forme .Net Core 2.2 à l'aide de WCF 4.5 pour interagir avec le service client SOAP. Pendant le service, les développeurs de bus de données ont remarqué une charge élevée sur le serveur. De plus, des problèmes d'accès au service ont commencé à apparaître. En conséquence, il a été constaté que la raison réside dans le nombre de composés actifs.
Il y a un problème tel que l'épuisement de la connexion. Cela peut survenir en raison du manque de ports disponibles lors de l'établissement d'une connexion ou de la limitation du nombre de connexions à des services externes ou internes. Il existe deux solutions:
• Augmenter les ressources disponibles,
• Réduction du nombre de connexions.
La première option n'est pas à notre disposition, car une augmentation des ressources ne peut se faire que du côté du prestataire de services. Par conséquent, nous avons décidé de rechercher des options pour optimiser le nombre de composés. Dans cet article, nous parlerons de la solution trouvée.
Idée
Il s'est avéré que le problème était que pour chaque demande, nous avons créé une nouvelle instance du client WCF. Cela a rendu impossible l'utilisation du pool de connexions déjà implémenté dans WCF, car le pool est créé pour chaque canal, et nous créons un nouveau canal pour chaque demande. Bien sûr, vous pouvez réécrire le service chargé d'interagir avec WCF à l'aide d'un client WCF statique. Mais dans ce cas, le pool serait également statique, ce qui pourrait provoquer le problème de modification DNS
abordé dans cet article . Il a également parlé de la solution -
HttpClientFactory . L'essence de la solution est que l'usine peut fonctionner avec son propre pool, dans lequel les connexions sont périodiquement mises à jour. La période de mise à jour par défaut est de deux minutes, mais peut être modifiée.
Dans notre produit, nous avons déjà utilisé HttpClientFactory pour interagir avec d'autres services, et l'utilisation de l'usine dans WCF ressemblait à une bonne alternative à un client WCF statique. Dans ce cas, nous n'aurions pas à modifier l'implémentation du service WCF. Mais ils pourraient utiliser la piscine avec laquelle l'usine peut travailler. De plus, cela nous a permis de résoudre le problème d'authentification NTLM sous Linux,
décrit dans cet article , car lors de la configuration du client http, vous pouvez définir le schéma d'authentification pour le gestionnaire de messages.
Implémentation
Pour travailler avec HttpClientFactory, ajoutez simplement la description de la configuration client à ConfigureServices. Là , vous pouvez ajouter plusieurs clients nommés ou tapés avec votre propre configuration. Dans ce cas, chaque client utilisera son propre pool de connexions. Dans l'exemple, nous utilisons un client nommé.
services.AddHttpClient("ClientName");
Dans WCF, vous pouvez ajouter vos propres gestionnaires de messages pour le client http. Pour ce faire, ajoutez un délégué initialisé par la méthode aux paramètres de liaison. Là , en tant que paramètre d'entrée, nous obtenons un gestionnaire créé du côté WCF et retournons notre propre gestionnaire. Par conséquent, le gestionnaire obtenu à partir de la méthode déléguée sera transmis au concepteur http client côté WCF.
Ainsi, en retournant le gestionnaire du pool d'usine, nous remplacerons le gestionnaire entrant par lui. Pour obtenir le gestionnaire à partir du pool d'usine, nous utilisons HttpMessageHandlerFactory. Et pour accéder aux paramètres de liaison, il sera nécessaire d'implémenter une classe héritée d'IEndpointBehavior. Et puis ajoutez-le à notre client WCF.
Schématiquement, l'algorithme de création d'un nouveau client côté WCF ressemble à ceci.
Nous implémentons CustomEndpointBehaviour.
public class CustomEndpointBehavior : IEndpointBehavior { private readonly Func<HttpMessageHandler> _httpHandler; public CustomEndpointBehavior(IHttpMessageHandlerFactory factory) {
Ensuite, ajoutez notre EndpointBehavior au client WCF.
var httpMessageHandler = serviceProvider.GetRequiredService<IHttpMessageHandlerFactory>(); var client = new WcfClient(); client.Endpoint.EndpointBehaviors.Add(new CustomEndpointBehavior(httpMessageHandler));
Désormais, lors de la création de connexions via WCF, dans la mesure du possible, les instances de gestionnaire du pool seront utilisées. Cela réduira le nombre de composés actifs.
Test
Pour vérification, nous avons envoyé 100 demandes identiques. En conséquence, sans pool, le pic de composés a atteint 53, et avec un pool il n'a pas dépassé 7.
Surveillance des connexions sans pool:
Surveillance des connexions de pool:
Conclusion
Chez True Engineering, nous avons implémenté un pool de connexions dans WCF, qui ne dépend pas de l'implémentation du travail avec le client WCF. Il permet également d'économiser efficacement les ressources tant du côté serveur où l'application s'exécute que du côté du fournisseur de services.
Nous avons passé beaucoup de temps à rechercher des options d'optimisation, mais la solution elle-même s'est avérée concise et simple. Prenez-le pendant qu'il fait chaud)