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.