Nosso produto foi desenvolvido na plataforma .Net Core 2.2 usando o WCF 4.5 para interagir com o serviço de cliente SOAP. Durante o serviço, os desenvolvedores do barramento de dados notaram uma alta carga no servidor. Além disso, começaram a aparecer problemas com o acesso ao serviço. Como resultado, verificou-se que o motivo está no número de compostos ativos.
Existe um problema como esgotamento da conexão. Pode surgir devido à falta de portas disponíveis ao estabelecer uma conexão ou limitar o número de conexões a serviços externos ou internos. Existem duas soluções:
• Aumentar os recursos disponíveis,
• Reduzindo o número de conexões.
A primeira opção não está disponível para nós, uma vez que um aumento de recursos pode ser feito apenas no lado do provedor de serviços. Portanto, decidimos procurar opções para otimizar o número de compostos. Neste artigo, falaremos sobre a solução encontrada.
Idéia
Como se viu, o problema era que, para cada solicitação, criamos uma nova instância do cliente WCF. Isso impossibilitou o uso do pool de conexões já implementado no WCF, porque o pool foi criado para cada canal e criamos um novo canal para cada solicitação. Obviamente, você pode reescrever o serviço responsável por interagir com o WCF usando um cliente estático do WCF. Mas, nesse caso, o pool também seria estático, o que poderia causar o problema de alteração de DNS
discutido neste artigo . Ele também falou sobre a solução -
HttpClientFactory . A essência da solução é que a fábrica pode trabalhar com seu próprio pool, no qual as conexões são atualizadas periodicamente. O período de atualização padrão é de dois minutos, mas pode ser alterado.
Em nosso produto, já usamos o HttpClientFactory para interagir com outros serviços, e o uso da fábrica no WCF parecia uma boa alternativa a um cliente estático do WCF. Nesse caso, não precisaríamos fazer alterações na implementação do serviço WCF. Mas eles poderiam usar a piscina com a qual a fábrica pode trabalhar. Além disso, isso nos permitiu resolver o problema com a autenticação NTLM no Linux,
descrito neste artigo , pois ao configurar o cliente http, você pode definir o esquema de autenticação para o manipulador de mensagens.
Implementação
Para trabalhar com HttpClientFactory, basta adicionar a descrição da configuração do cliente ao ConfigureServices. Lá você pode adicionar vários clientes nomeados ou digitados com sua própria configuração. Nesse caso, cada cliente usará seu próprio pool de conexões. No exemplo, usamos um cliente nomeado.
services.AddHttpClient("ClientName");
No WCF, você pode adicionar seus próprios manipuladores de mensagens para o cliente http. Para fazer isso, adicione um delegado inicializado pelo método aos parâmetros de ligação. Lá, como parâmetro de entrada, obtemos um manipulador criado no lado do WCF e retornamos nosso próprio manipulador. Como resultado, o manipulador obtido do método delegate será passado para o designer http do cliente no lado do WCF.
Assim, retornando o manipulador do pool de fábrica, substituiremos o manipulador de entrada por ele. Para obter o manipulador do pool de fábrica, usamos o HttpMessageHandlerFactory. E para obter acesso aos parâmetros de ligação, será necessário implementar uma classe herdada de IEndpointBehavior. E depois adicione-o ao nosso cliente WCF.
Esquematicamente, o algoritmo para criar um novo cliente no lado do WCF se parece com isso.
Implementamos CustomEndpointBehaviour.
public class CustomEndpointBehavior : IEndpointBehavior { private readonly Func<HttpMessageHandler> _httpHandler; public CustomEndpointBehavior(IHttpMessageHandlerFactory factory) {
Em seguida, adicione nosso EndpointBehavior ao cliente WCF.
var httpMessageHandler = serviceProvider.GetRequiredService<IHttpMessageHandlerFactory>(); var client = new WcfClient(); client.Endpoint.EndpointBehaviors.Add(new CustomEndpointBehavior(httpMessageHandler));
Agora, ao criar conexões por meio do WCF, sempre que possível, serão usadas instâncias de manipulador do pool. Isso reduzirá o número de compostos ativos.
Teste
Para verificação, enviamos 100 pedidos idênticos. Como resultado, sem piscina, o pico de compostos atingiu 53 e, com uma piscina, não excedeu 7.
Monitorando conexões sem um pool:
Monitorando conexões de pool:
Conclusão
Na True Engineering, implementamos um conjunto de conexões no WCF, que não depende da implementação do trabalho com o cliente WCF. Ele também economiza efetivamente recursos no lado do servidor em que o aplicativo está sendo executado e no lado do provedor de serviços.
Passamos muito tempo pesquisando opções de otimização, mas a solução em si acabou sendo concisa e simples. Pegue enquanto está quente)