Projeto MTE (Middleware Technology Evaluation)

O CSIRO apresentou um relatório [Tran et al. 2001] avaliando três dos principais competidores no mercado de plataformas de MOM: Microsoft Message Queue v2.0, IBM MQSeries v5.2 e TIBCO Rendezvous v6.6. Esse relatório realiza medições dos sistemas submetendo-os a vários cenários. O objetivo principal é identificar os pontos fortes e fracos de cada plataforma fazendo com que a escolha do sistema mais adequado dependa da determinação de quais desses pontos são mais relevantes em cada situação específica. Os resultados da avaliação do produto da IBM são também apresentados de forma detalhada no artigo [Tran et al. 2002].

Esse projeto realiza a avaliação dos produtos através de medições em um ambiente de teste controlado. Além disso, eles definem uma métrica para a avaliação dos produtos e analisam o impacto no desempenho de alguns fatores, como o tamanho de buffers e o mecanismo de persistência.

Segundo o CSIRO um aspecto chave da medição de desempenho de um sistema de MOM é o estabelecimento de um cenário que melhor reflita o “mundo real” das aplicações baseadas em MOM. Baseado nesses cenários é necessário definir uma métrica para que a comparação de desempenho possa ser estabelecida. Ainda segundo os pesquisadores, existe um número grande de fatores que podem influenciar o desempenho de um sistema de entrega de mensagens, entre eles: a qualidade do serviço de entrega determinada pelo nível de confiabilidade do canal de comunicação; os parâmetros de configuração do sistema; o tamanho das mensagens; e o número de threads utilizado pelos consumidores.

Os testes são realizados através de uma aplicação multi-threaded representando vários produtores enviando mensagens sobre uma rede comutada para uma aplicação também multi-threaded simulando vários consumidores. Os produtos MQSeries e MSMQ são testados com uma única fila e um único gerente de fila

126 Medição

em cada um dos lados (produtor e consumidor). Ou seja, não existe nesses cenários o papel do JMS Provider centralizado.

A aplicação que simula os produtores permite que seja configurada uma taxa de envio desejada variando para isso o número de threads destinado a realizar o envio de mensagens e o atraso (tempo de espera) entre um envio e outro. O número de threads na aplicação consumidora também permite variação, o que facilita a investigação do impacto desse aspecto na vazão total do sistema. Em geral, os pesquisadores configuraram as plataformas de MOM de acordo com as recomendações fornecidas pelos fabricantes dos produtos. A exceção foi quanto à recomendação da Microsoft de configurar o MSMQ sobre um sistema de múltiplos discos para acelerar o tratamento de mensagens em cenários transacionais e com persistência.

O experimento de medição foi conduzido de forma que os consumidores são iniciados antes dos produtores, para evitar que mensagens sejam acumuladas na fila. Cada thread da aplicação produtora fica em loop enviando mensagens para os consumidores e esperando um pequeno intervalo de tempo antes de enviar outra mensagem. Já as threads consumidoras estão em loop contínuo buscando mensagens na fila. Os experimentos utilizam apenas mensagens dos produtores para os consumidores, sem exigir resposta, e somente ponto-a-ponto (PTP). Os atributos básicos que foram variados durante o teste são: taxa de envio de mensagens, formada pelo número de threads de produção e pelo intervalo entre mensagens (10 threads no cenário com persistência e 50 threads para os demais cenários); número de threads de consumo (1, 5, 15, 20, 30 threads); e tamanho da mensagem (64, 1024, 4096 bytes).

Os resultados obtidos pelo projeto determinam que o sistema possa estar operando em dois possíveis estados: sustentável ou insustentável. O que determina em qual estado o sistema se encontra é a relação entre a taxa de envio e a taxa de recepção de mensagens. Se a relação entre essas taxas faz com que o tamanho da fila permaneça estável, é dito que o sistema está num estado sustentável. Caso contrário, o sistema tende a preencher a fila com mensagens, até que os recursos computacionais que suportam a implementação do mecanismo de armazenamento esteja completamente saturado. Nesse cenário, é dito que o sistema encontra-se em um estado insustentável.

A partir dessa observação, o projeto definiu a métrica da Vazão Máxima Sustentável (Maximum Sustainable Throughput, MST) como a principal medida de comparação e avaliação de plataformas de MOM. Ela representa a vazão do sistema no seu ponto de saturação. Esse nível de vazão não causa um incremento significativo da fila, permitindo que o sistema consiga mantê-lo sem exaurir os recursos computacionais. A medição dessa métrica deve ser conduzida com a fila inicialmente vazia, e com ambos os produtores e consumidores em execução.

O artigo [Tran et al. 2003] demonstra a importância da métrica MST para a avaliação de sistemas de MOM, testando três competidores voltados para integração de sistemas (Message Brokers): IBM Websphere MQ/MQIntegrator, TIBCO Rendesvous/MessageBroker v4.0 e Mercator Integration Manager v6.0.

Quanto à qualidade do serviço de entrega, as plataformas de MOM normalmente oferecem três níveis de serviço: melhor esforço, persistente e transacional. A partir da combinação desses níveis de serviço o projeto MTE definiu três alternativas para realizar as medições: NPNT (sem persistência e não transacional), PNT (persistente e não transacional) e PT (persistente e transacional). A partir de então, essa nomenclatura passou a ser largamente adotada nos processos de avaliação de sistema de entrega de mensagens.

Quantos aos demais fatores o projeto também inferiu através dos resultados obtidos que eles afetam de forma significativa o desempenho do MOM. O MST decrementa quase linearmente com o incremento do tamanho da mensagem para cenários NPNT. A persistência (PNT) faz com que o MST reduza de patamares próximos a 3.000 mps (mensagens por segundo) para cerca de 130 mps. Enquanto a escalabilidade para o modelo PNT é fraca, para os modelos transacionais eles determinaram que ela pode chegar a seis vezes com o acréscimo de threads de consumo.

As principais limitações desse estudo são:

Os resultados de desempenho são específicos para os casos de teste desenvolvidos no projeto. Outras aplicações podem ter comportamento diferente, pois podem fazer uso de características das plataformas de MOM diferentes das avaliadas nesse estudo. Porém, o estudo afirma que o teste de comunicações PTP é predominante nas aplicações que fazem uso de sistemas de MOM e que espera que os resultados sejam relevantes em muitos cenários de aplicações corporativas;

Os resultados de desempenho são específicos para a plataforma de hardware e rede utilizada. Ambientes diferentes (servidores, rede, sistemas operacionais) podem produzir resultados diferentes. Segundo eles, infelizmente não existe forma absolutamente correta de saber o desempenho em uma plataforma tecnológica diferente sem fazer as medições;

Os casos de teste (cenários de avaliação) não utilizam o estilo de comunicação publish/subscribe (Pub/Sub), não sendo possível avaliar essa característica dos sistemas de MOM testados. Eles afirmam que esperam resultados bem diferentes para cenários Pub/Sub devido a grande diferença de comportamento dos sistemas de MOM nesse modelo de comunicação.

6.1.3 Sonic MQ

O relatório técnico [Jahming 2001] apresenta os resultados obtidos no estudo que apresenta o desempenho de produtos em conformidade com a especificação JMS. Os JMS Providers avaliados são o SonicMQ v4.0 e o IBM MQSeries v5.2. Nenhum procedimento de tuning é realizado nos produtos avaliados, isso significa que os resultados obtidos podem ser maiores se tais procedimentos fossem adotados. Segundo os autores, o propósito deste estudo é testar e ilustrar as características de desempenho desses JMS Providers. Eles admitem que os resultados não devem ser projetados para outras situações e que eles

128 Medição

demonstram apenas o desempenho dos produtos nesses cenários, e na plataforma escolhida.

Para realizar os testes a Sonic Software desenvolveu um JMS Client chamado

MsgRunner que permite uma grande variedade de configurações de cenários de

teste. Esse cliente implementa a interface JMS fazendo com que o mesmo cliente possa ser utilizado para avaliar qualquer JMS Provider sem nenhuma alteração. Esse aspecto torna a avaliação um pouco mais isenta que outras iniciativas que utilizam clientes específicos para cada produto a ser avaliado. Todos os experimentos são conduzidos sob as seguintes condições:

Todas as conexões dos clientes são estabelecidas antes do período de

ramp-up iniciar, não estando incluídas na janela de medição;

Cada experimento inclui dois minutos para o período de ramp-up e dois minutos para ramp-down;

Cada janela de medição tem quinze minutos de duração;
Cada cliente roda apenas uma conexão JMS;

Todos os testes são executados múltiplas vezes, garantindo a propriedade de repetição, e a obtenção de dados estatisticamente válidos;

As mensagens são recebidas pelos consumidores de forma assíncrona, e utilizando o método de reconhecimento AUTO_ACKNOWLEDGE.
Exceto durante os testes do cenário Pub/Sub com mensagens

NonDurable com configuração de um produtor para muitos consumidores, nenhuma máquina cliente excede 50% da utilização de CPU, garantindo que nenhum gargalo é inserido por estes equipamentos;

O banco de dados (storage) utilizado para persistir as mensagens é inicializado antes de cada experimento, garantindo que nenhum

overhead é inserido no experimento para realizar tal limpeza;

De forma equivalente, todas as filas ou tópicos são esvaziados, deletados e recriados antes de cada experimento;

Durante os experimentos nenhuma outra aplicação está rodando e/ou consumindo recursos do SUT;

Produtores são configurados para gerar mensagens tão rápido quanto possível, isto é, sem nenhuma inserção de think time entre as mensagens;

Não é testado nenhum cenário com utilização de comunicação transacional.

A configuração dos clientes é realizada de forma que cada produtor e consumidor estejam em conexões separadas. Quando produtores e consumidores compartilham a mesma máquina, elas estão sobre a mesma JVM, porém em threads distintas. São utilizadas cerca de 10 máquinas clientes para gerar a carga de trabalho para o servidor.

Ambos os estilos de comunicação (PTP e Pub/Sub) são avaliados neste estudo. Quarenta cenários distintos são avaliados para cada um dos JMS Providers, que

executaram com suas configurações padrões, ou com pequenas modificações para permitir a avaliação dos cenários.

Desses cenários, quatorze utilizam o estilo PTP (todos utilizam mensagens com persistência), sendo os oito primeiros utilizando uma comunicação um para um, outros quatro simulando comunicação de poucos para muitos, enquanto que os últimos dois avaliam cenários de muitos para poucos. No primeiro grupo de cenários o objetivo é testar a capacidade do MOM em manipular um número crescente de conexões simultâneas. No segundo, o objetivo é avaliar a capacidade de encaminhamento de mensagens sem enfileiramento. Já no último grupo o intuito é testar os mecanismos de fluxo de mensagens com a presença de enfileiramento.

Os cenários Pub/Sub são elaborados a partir da variação do número de produtores, de consumidores e de tópicos, além do tamanho da mensagem e do modelo de assinatura (Durable ou NonDurable). Todos os cenários com assinaturas Durable adotam mensagens persistentes, enquanto que no caso de NonDurable as mensagens são não persistentes.

Os primeiros dezesseis cenários Pub/Sub simulam uma comunicação um para um, com o incremento do número de conexões e tópicos. Nesses experimentos, um produtor está produzindo mensagens para um único Destination, que por sua vez é assinado por um único consumidor. Os próximos oito cenários adotam uma comunicação de poucos para muitos. Nesses casos, existem múltiplos consumidores como assinantes de um tópico, fazendo com que cada mensagem enviada para o tópico seja encaminhada para cada assinante. Os últimos dois cenários Pub/Sub simulam uma situação de muitos para poucos, ou seja, os avaliadores pretendem avaliar o comportamento do controle de fluxo (controle de admissão).

Todos esses experimentos avaliam o desempenho do MOM através do acompanhamento de duas métricas: Taxa de Entrega de Mensagens e Latência. A taxa de entrega de mensagens representa a razão entre a quantidade de mensagens recebidas pelos consumidores dentro da janela de medição e o tempo de duração da janela. Essa taxa pode se diferenciar da taxa de envio de mensagens, que não é objeto de medição do estudo.

A latência representa a quantidade média de tempo entre o momento que o produtor está pronto para enviar uma mensagem até o momento que o consumidor a recebe. Segundo os pesquisadores, nem todas as mensagens são incluídas nessa monitoração, pois o objetivo dessa métrica é ilustrar o efeito do MOM no encaminhamento de mensagens.

Uma conclusão importante deste estudo [Jahming 2001] é que a avaliação somente foi possível porque os JMS Providers implementam uma interface padrão (API JMS). Apesar disso, os resultados possuem bastante interferência por causa de fatores externos a configuração dos cenários, como: configuração do JMS Provider; plataforma operacional do servidor (sistema operacional, JVM, sistema de disco, quantidade de memória); configuração da plataforma operacional dos clientes; configuração da rede.

Em outro trabalho [Sonic 2003], é apresentada uma comparação do SonicMQ v5.0.2 com o TIBCO Enterprise for JMS v3.1. Nesse estudo, os autores

130 Medição

realizam medições em ambiente de teste, para cenários Pub/Sub, variando o nível de confiabilidade do serviço de entrega de mensagens (modo de entrega e integridade transacional).

Segundo os autores os cenários representam situações de estresse para aplicações do mundo real, como: aplicações para o sistema financeiro, comunicação de atualização de preço em empresas de varejo, distribuição de preços para portais B2B, aplicações de monitoramento na área de Telecom. Os cenários para os experimentos definem sempre um número igual de produtores e consumidores (publishers e subscribers). Os testes examinam o desempenho do MOM suportando muitos clientes simultaneamente.

Durante esse trabalho a Sonic Software criou um benchmark para avaliação de desempenho de JMS Providers, disponibilizando o pacote de ferramentas

TestHarness para download em seu site (http://www.sonicsoftware.com.br).

Os cenários são identificados pela relação entre Produtores, Tópicos e Consumidores como 10/10/10 (P/T/C), indicando que dez produtores se comunicam com dez consumidores, através de dez tópicos. O que determina o número máximo de clientes suportados no experimento é a garantia de que a plataforma cliente não estará saturada quanto a CPU ou memória.

A duração dos experimentos é de trinta e três minutos, sendo os dois primeiros considerados como ramp-up, e o último como ramp-down. Ou seja, a janela efetiva de medição é de trinta minutos. Os produtores e os consumidores executam em máquinas cliente diferentes, e se conectam com o servidor através de uma rede dedicada e controlada.

Os experimentos utilizam cinqüenta mensagens por transação entre o produtor e o JMS Provider. A sessão de entrega das mensagens (entre JMS Provider e o consumidor) não é transacional. O método de reconhecimento das mensagens é DUPS_OK_ACKNOWLEDGE para as sessões não transacionais.

O pacote de ferramentas possui algumas limitações, entre elas: uma única métrica avaliada (taxa de entrega de mensagens); geração de carga a partir de vários clientes (distribuída) é iniciada manualmente; não existe tratamento estatístico automatizado dos resultados.

6.1.4 FioranoMQ

A Krissoft Solutions realiza um estudo comparativo entre o FioranoMQ v7.5 e os principais JMS Providers de mercado: SonicMQ v6.0, Tibco EMS v4.0 e IBM WebSphereMQ v5.3. Os resultados desse estudo são apresentados no relatório técnico [Krissoft 2004].

O estudo avalia o desempenho dos JMS Providers utilizando o estilo de comunicação Pub/Sub. Segundo os autores, essa avaliação testa cenários de estresse com condições equivalentes a aplicações do mundo real. Em todos os cenários apenas um JMS Provider é responsável em encaminhar as mensagens de muitos produtores para muitos consumidores.

A metodologia utilizada para os testes são as mesmas desenvolvidas e publicadas pela Sonic Software [Sonic 2003] [Sonic 2004]. Todos os procedimentos já discutidos em [Sonic 2003] são rigorosamente seguidos,

inclusive o fato que todos os JMS Providers são configurados com opções padrão.

Todos os testes são conduzidos sobre as condições estabelecidas em [Jahming 2001] com exceção de:

O método de reconhecimento utilizado por todos os consumidores é DUPS_OK_ ACKNOWLEDGE;

Todas as configurações da JVM são exatamente as mesmas para todos os produtos, mesmo quando recomendado a utilização de algum parâmetro especial para melhorar o desempenho de algum dos produtos em particular.

Segundo os autores, os experimentos são realizados para os dois mais populares modelos de cenário Pub/Sub:

Produtores gerando mensagens Não Persistentes e consumidores com assinatura NonDurable. Esse modelo é tipicamente utilizado por aplicações que trocam grandes volumes de mensagens e tem um requisito de baixa latência;

Produtores gerando mensagens persistentes e consumidores com assinatura Durable. Esse modelo é normalmente empregado por aplicações que necessitam do máximo de confiabilidade no canal de comunicação, incluindo redundância, entrega única de cada mensagem independente de falhas.

Para cada modelo de cenário são definidos vários cenários com o intuito de avaliar a escalabilidade do JMS Provider em duas dimensões:

Testes de Escalabilidade do Servidor – observam as características de desempenho do JMS Provider variando o número de tópicos utilizados, mantendo para cada um deles um número fixo de clientes. Ou seja, os resultados avaliam a capacidade do MOM de manipular várias conexões simultâneas, atendendo assim a um número crescente de clientes.

Testes de Escalabilidade do Tópico – observam as características de desempenho do JMS Provider variando o número de clientes associados a um tópico, mantendo o número de tópicos fixo. Ou seja, os resultados avaliam a capacidade do MOM de manipular um número crescente de clientes associados a um mesmo tópico.

Um aspecto importante dos experimentos é que não foi adicionado nenhum tempo de processamento para os produtores ou consumidores, fazendo com que ambos produzam e consumam mensagens o mais rápido possível.

Os experimentos são conduzidos utilizando uma topologia formada por duas máquinas: uma para executar os clientes (tanto produtores quanto consumidores), e outra para executar o servidor (JMS Provider). Quanto à métrica utilizada para comparar os produtos, é avaliada a taxa de entrega de mensagens, conforme especificado nos trabalhos da Sonic Software.