Integrações entre Sistemas – Parte 9 – Estatísticas

Objetivo

Após algum tempo criando estes exercícios de diferentes métodos de integração, resolvi executar uma bateria de testes em todos eles para tentar chegar num comparativo de tempos e prós e contras de cada um deles.

Foram alguns dias, de máquinas superaquecendo e desligando, ajustes nos códigos criados para conseguir chegar nestes resultados. Espero que gostem.

O Método

Para chegar nestes resultados, executei os exemplos criados nas partes 1 a 8 com diferentes quantidades de dados: 20.000, 50.000, 500.000 e 1 milhão de registros. Para eliminar o problema de cache de bancos de dados e outras pequenas variações que podem acontecer nesse tipo de teste, executei cada um deles 10 vezes e tirei uma média dos tempos.

Em todos os métodos sempre foi utilizada a mesma massa de dados e as mesmas máquinas, somente para tentarmos observar a diferença de tempos de cada um dos métodos.

Demorou algo em torno de 4 dias pra conseguir rodar tudo, mas valeu a pena.

Tempos de execução

Separei os resultados em 2 gráficos para simplificar a visualização e comparação dos resultados:

O método File Transfer (extração simples) está no gráfico somente para referência. Ele não possui a abordagem request/response necessária para o cenário que estamos exercitando. Somente coloquei ele nos testes para termos uma base da diferença de uma extração simples para um request/response. Percebemos que a diferença dá em torno de 35%.

Outra comparação interessante está no método de Tcp Client. A abordagem single thread é de 55 a 80% mais lenta que a abordagem multi thread.

Mais um número assustador é a comparação Websphere MQ x MSMQ. Usei filas transacionais no MSMQ e filas persistentes no Websphere MQ. O MSMQ ficou de 85 a 100% mais lento que o Websphere MQ. Neste caso, prefiro acreditar que minha implementação está ruim. Pretendo investigar mais. Outra coisa que pode ter dado diferença neste caso é que o Websphere MQ utiliza-se de uma segunda thread para processar.

Outra comparação clássica é net.tcp x SOAP. No cenário de requests pequenos (sem trabalhar com pequenos lotes), a diferença é gigante. No caso da separação por pequenos lotes de 1000, o SOAP mostrou-se de 26 a 34% mais lento.

Para compararmos os métodos mais rápidos, vou separar a comparação por volumes, começando por 20.000 registros:

Método Tempo em segundos (20K registros) % Diferença absoluta
Websphere MQ 8,92
Http Request 9,93 11,39 1,02
Tcp Client (multi thread) 10,68 19,80 1,77
File Transfer (extração simples) 14,72 65,06 5,80
MSMQ 15,94 78,80 7,03
Net TCP (lotes) 17,95 101,29 9,03
File Transfer (request/response) 19,26 115,98 10,34
SOAP (lotes) 22,40 151,26 13,49
TCP Client (single thread) 27,80 211,83 18,89

O percentual representa o quanto o método em questão é mais lento em relação ao mais rápido, por exemplo, o cenário de File Transfer (request/response) se mostrou 115% mais lento que o cenário usando Websphere MQ (mais que o dobro do tempo).

Agora os resultados para 50.000 registros:

Método Tempo em segundos (50K registros) % Diferença absoluta
Http Request 22,02
File Transfer (extração simples) 23,35 6,04 1,33
Websphere MQ 24,61 11,76 2,59
Tcp Client (multi thread) 28,05 27,36 6,03
File Transfer (request/response) 32,63 48,18 10,61
Net TCP (lotes) 41,73 89,49 19,71
MSMQ 45,59 107,02 23,57
TCP Client (single thread) 52,32 137,60 30,30
SOAP (lotes) 52,79 139,71 30,77

Novamente vemos que conforme o volume aumenta, alguns métodos melhoram de desempenho e outros pioram. O aumento dos registros também faz com que a diferença percentual entre os métodos fique menos significativa, mas a diferença absoluta de alguma forma significativa. Por exemplo, a diferença em segundos de file transfer para http é de 10s para 50.000 registros.

Resultados para 500.000 registros:

Método Tempo em segundos (500K registros) % Diferença absoluta
Http Request 230,19
Websphere MQ 233,63 1,50 3,44
File Transfer (extração simples) 250,76 8,94 20,57
File Transfer (request/response) 347,30 50,88 117,12
Tcp Client (multi thread) 351,39 52,65 121,20
Net TCP (lotes) 404,00 75,51 173,82
MSMQ 443,33 92,60 213,15
SOAP (lotes) 533,62 131,82 303,43
TCP Client (single thread) 545,48 136,97 315,29

Agora percebemos que a medida que o volume aumenta o Websphere MQ começa a ter um desempenho melhor, mas surpreendentemente apesar do consumo absurdo de memória e gerando muita paginação no sistema operacional, o método Http Request ainda funciona muito bem. Acredito que com muita concorrência ele não desempenhará tão bem assim devido ao alto consumo de memória.

Por último, os resultados para 1 milhão de registros:

Método Tempo em segundos (1 milhão de registros) % Diferença absoluta
Websphere MQ 417,36
Http Request 428,95 2,78 11,59
File Transfer (extração simples) 495,27 18,67 77,91
File Transfer (request/response) 657,09 57,44 239,73
Tcp Client (multi thread) 671,37 60,86 254,01
Net TCP (lotes) 788,20 88,85 370,84
MSMQ 836,12 100,34 418,76
SOAP (lotes) 1059,69 153,90 642,33
TCP Client (single thread) 1079,72 158,70 662,36

Agora, com alto volume, percebemos que o Websphere MQ atinge o topo novamente, ficando novamente em 2º lugar o Http Request e o método até então “preferido” pela maioria, File Transfer fica em 3º lugar. Eu já suspeitava disso, mas ele ficou em 3º.

File Transfer

Acredito que file transfer ainda seja o método mais utilizado para transferência de grandes massas de informação entre 2 sistemas. Para muitos, ainda é o método mais rápido. Com os resultados obtidos através destes testes (usando 1 milhão de registros como base de comparação) e mantendo somente os métodos mais populares, chegamos nas seguintes diferenças:

Método Tempo em segundos (1 milhão registros) % Diferença absoluta (s) Diferança absoluta (min)
File Transfer (request/response) 657,09
Websphere MQ 417,36 -36,48 -239,73 -4,00
Net TCP (lotes) 788,20 19,95 131,11 2,19
SOAP (lotes) 1059,69 61,27 402,61 6,71

Essa tabela compara os métodos sempre em relação a file transfer. Websphere MQ é 36% mais rápido enquanto o SOAP é 61% mais lento que file transfer, mas se compararmos em tempos absolutos, temos uma variação de 6,71 minutos do SOAP para file transfer em 1 milhão de registros!

Será que a diferença de tempo vale todo o trabalho adicionado pelo método de file transfer, desde a sincronização dos arquivos, até a necessidade de customizar a entrega da informação para cada sistema diferente que solicite o arquivo? Na minha opinião não. Se a questão é desempenho, partir para mensageria é uma idéia melhor. Se a questão é velocidade de desenvolvimento, ficaria com net.tcp ou SOAP.

Prós e contras

Esse tipo de comparativo é muito ruim e subjetivo, mas resolvi montar alguns critérios, para analisarmos cada um dos métodos sob diferentes perspectivas:

Critério Websphere MQ Http Request File Transfer Tcp Client Net TCP SOAP MSMQ
Desempenho Bom Bom Regular Regular Regular Ruim Ruim
Facilidade de implementação Regular Regular Ruim Ruim Bom Bom Regular
Aderência a SOA Bom Ruim Ruim Ruim Ruim Bom Bom
Necessidade de parse de conteúdo Ruim Ruim Ruim Ruim Bom Bom Ruim
Abrangência de plataformas (baixa plataforma) Bom Bom Bom Bom Ruim Bom Ruim
Abrangência de plataformas (considerando alta plataforma) Bom Ruim Regular Regular Ruim Ruim Ruim
Acoplamento entre origem e destino Regular Ruim Ruim Ruim Bom Bom Regular
Custo com licenças de uso Ruim Bom Bom Bom Bom Bom Bom
Aderência a padrões de mercado (conteúdo da mensagem) Ruim Ruim Ruim Ruim Ruim Bom Ruim
Dependência de disponibilidade do sistema destino Bom Ruim Bom Ruim Ruim Ruim Bom
  • Desempenho: Este critério é baseado nos tempos aqui discutidos
  • Facilidade de implementação: Neste critério, estou considerando complexidades mais da mecânica de transferência do que de formato de arquivos. No Websphere MQ por exemplo, é necessário tratar a comunicação de forma assícrona, que adiciona alguma complexidade. No caso de File Transfer é necessário criar uma mecânica de sinalização para não pergar o arquivo em escrita e em leitura e ainda no caso de TCP, criar todo um protocolo para se estabelecer como as informações serão transferidas, problemas que em SOAP, por exemplo não existem.
  • Aderência a SOA: Todos os métodos aqui tratam comunicação ponto a ponto. Em arquiteturas mais desenvolvidas e numa malha grande de sistemas, sabemos que comunicação ponto a ponto torna o ambiente quase impossível de se gerenciar. No caso de MQ, SOAP é fácil implementar uma ESB na comunicação sem ter que mexer praticamente nada em provedor e consumidor de serviço.
  • Necessidade de parse de conteúdo: Sempre que falamos de parse de conteúdo manualmente, estamos sujeitos a erros. Hoje existem parsers de XML, schemas e diversas ferramentas para isso, mas é sempre uma fonte de erro. Quando falamos em alta plataforma, por exemplo, isso já pode não ser muito trivial. Alguns métodos como SOAP e Net.tcp removem essa complexidade.
  • Abrangência de plataformas (baixa plataforma): Esse critério trata-se da facilidade de utilizar esse método de integração em diferentes plataformas (Unix, Java, etc). Websphere MQ tem implementações para várias plataformas, o que já não é verdade para MSMQ (apenas Windows). File Transfer, HTTP e TCP são comuns em outras plataformas. Net.tcp que é proprietário da Microsoft também é um issue neste caso.
  • Abrangência de plataformas (considerando alta): Alta plataforma é algo extremamente fechado. Websphere MQ é uma excelente solução neste caso pois existe implementação para mainframe. É possível usar file transfer e TCP, mas a complexidade é bastante alta. Em ambos os casos, existe a preocupação na conversão ASCII/EBCDIC.
  • Acoplamento entre origem e destino: Falando de acoplamento, me refiro à necessidade de ambos os lados assumirem uma série de premissas em relação a formato, protocolo, conteúdo, etc. Os únicos métodos que abstraem isso melhor são SOAP e Net.tcp, devido à existencia de um WSDL que evita uma série de problemas em relação à premissas de como o conteúdo será formatado.
  • Custo com licenças de uso: Este critério pesa mais para o Websphere MQ que é um produto da IBM com custo de licenciamento.
  • Aderência a padrões de mercado: Neste critério está contemplada a facilidade de interoperabilidade com outras tecnologias. A única realmente padrão utilizada aqui é o SOAP
  • Dependência de disponibilidade do sistema destino: Este critério trata-se do quanto o sistema origem depende do sistema destino. Em métodos como SOAP, TCP, Http Request, a espera da resposta do sistema é imediata, devido à natureza síncrona da comunicação. Em caso de falha do sistema destino, o sistema origem falha também. Quando falamos de MQ, MSMQ ou File Transfer, uma vez que o arquivo ou mensagem esteja disponível para o sistema destino, o sistema origem não para no caso de falhas. Quando ocorre recuperação das falhas, as respostas são enviadas e o processamento segue, com menor necessidade de intervenção manual.

Código Fonte

O código fonte está disponível no git hub: https://github.com/ericlemes/IntegrationTests.

Conclusão

Como podemos observar, integração entre sistemas com alto volume é algo que deve ser pensado e planejado com calma. Em relação a todos os métodos apresentados, a grande supresa pra mim ficou no Websphere MQ. Não esperava que o desempenho fosse tão bom.

Me parece que para um cenário “enterprise”, com várias plataformas, sistemas, a associação do MQ como transporte com um middleware como barramento (ESB) é a solução para a grande maioria dos problemas de integração, com bom desempenho e baixo acoplamento.

Mesmo o padrão SOAP apresentando várias vantagens, o desempenho pode ser um ponto importante em muitos casos. No trade-off do desempenho do MQ contra a simplicidade de desenvolvimento do SOAP, a princípio fico com o desempenho do MQ na maioria dos casos.

About these ads

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 466 outros seguidores

%d blogueiros gostam disto: