Introdução
Teste Carga Concentrador
Passo a passo
Com o objetivo de responder algumas questões sobre o desempenho do Concentrador que surgiram com o tempo, foram realizados alguns testes de carga no Concentrador. As questões mais frequentes são:
1 - Quantos Agentes processando notas o Concentrador suporta antes dos agentes entrarem em contingência?
2 - Quanto de memória e CPU o Concentrador consome com o máximo de Agentes?
3 - O quão lento ficam os processos do concentrador (processamento de notas e integração) com o banco MySQL cheio?
Segue o ambiente do Concentrador:
Processador: Intel® Core™ i3 CPU 540 @3.07GHz (4 CPUs), ~3.1GHz;
Memória: 8GB RAM;
Sistema Operacional: Windows 10 Enterprise 64bits (Build 10240);
Versão MySQL: Community 5.7.16.0;
Versão do Java: JRE 1.7.0_60 x64;
Versão do Concentrador: 4.8.5.0;
Tipo de Contingência Normal, Automatizar.
Segue os resultados:
1 - Quantos Agentes processando notas o Concentrador suporta antes dos agentes entrarem em contingência?
Não podemos afirmar com 100% de certeza a quantidade exata de agentes pois é muito relativo, pois existem vários fatorem que podem interferir no resultado final, sendo o modelo do processador, recursos compartilhados da máquina ou a quantidade de agentes processando notas ao mesmo tempo, por tanto, o resultado abaixo é de um cenário específico e deve-se ter cautela ao repassar essa informação à clientes e parceiros.
Para esse teste foram instalados 50 agentes, apontados para o Concentrador e foi sendo programado em cada agente para enviar uma nota com 50 itens a cada 15 segundos. A partir do 25º Agente, algumas notas começaram a ser processadas em contingência por falha de comunicação com o Concentrador. Isso ocorreu pois o uso do CPU da máquina do Concentrador chegava a 100% de uso:
Com esse resultado, deixamos 30 agentes processando notas a cada 15 segundos (cada um), durante duas horas. Foram processadas 16.456 documentos, sendo 11.268 autorizadas Normal, 200 falhas de comunicação com o Concentrador e 4.988 autorizadas em Contingência. Não tivemos falha de comunicação com a Sefaz.
Com isso, concluímos que nesse cenário de stress, e com esse modelo de processador o seguro seria deixar apenas 25 Agentes ativos, para evitar falhas de comunicação com o Concentrador. Para manter os 50 Agentes processando, tivemos que deixar um intervalo de 5 minutos de envio de notas em cada Agente, com isso, após 2 horas, não tivemos falhas de comunicação com o Concentrador.
2 - Quanto de memória e CPU o Concentrador consome com o máximo de Agentes?
A versão 4.8.5.0 do Concentrador se mostrou bem otimizada em relação ao consumo de memória RAM. Mesmo após 12 horas de stress com os 50 agentes processando notas a cada 5 minutos (cada um), o Concentrador não chegou a consumir 1gb de memória conforme mostra a imagem acima. O maior consumo ficou por parte da CPU, onde nosso i3 de 1ª Geração se tornou um gargalo ficando na maior parte do tempo acima dos 80% de uso. Mesmo com os 50 agentes ociosos a CPU ficou sempre acima dos 50%.
3 - O quão lento ficam os processos do concentrador (processamento de notas e integração) com o banco MySQL cheio?
Nesse testes, foi medido o tempo total no processamento de 50 notas com 50 itens cada com o Banco MySQL com as tabelas de entrada, saída e integração vazias, com 50 mil registros, com 500 mil registros, com 1 milhão de registros e com 2 milhões de registros, configurando o “Intervalo entre execuções (Recepção)” em 5 segundos. Com 50 mil registros o Concentrador já apresentou timeout na leitura da tabela de entrada, com isso, o desenvolvimento criou um índice para o campo “status” dessa tabela, o que resolveu o problema. Segue o link do nosso manual com o script de criação da tabela de entrada já com a criação do índice:
http://manuais.nddigital.com.br/e-Forms_NFCe/4.8.9.0/index.html?entrada_via_banco.htm
Segue o resultado da medição:
Com esse resultado podemos concluir que indiferentemente da quantidade de registros nas tabelas, não vamos ter problemas de performance. O único problema que teremos é se não for criado o índice na tabela de entrada para resolver o possível timeout na leitura da tabela de entrada. Como a integração é apenas insert no banco, também não tivemos problemas de performance.
Outras informações
Fonte: Rainmakers Team