Progress/Sonic Software

A Sonic propôs em [Sonic 2004] a definição de um processo sistemático e estruturado de benchmark para sistemas de MOM. Esse trabalho apresenta cenários típicos de utilização de um sistema de entrega de mensagens, além de uma abordagem objetiva e direta para condução do processo, descrevendo as principais métricas a serem analisadas, uma metodologia para medição, assim como os fatores que as afetam.

Inicialmente, o trabalho define as seguintes métricas para realizar a avaliação do sistema de MOM: Taxa de Entrega de Mensagens (mensagens por segundo, mps) e Vazão do Sistema (bytes por segundo, bps). Em seguida, os autores elencam algumas perguntas que precisam ser respondidas durante o planejamento do benchmark:

Como os resultados podem ser interpretados?

Qual a duração mínima necessária dos experimentos?

Com que freqüência as observações (medidas) devem ser coletadas?
Como pode ser construído um cenário realístico?

Quantos produtores e consumidores devem ser utilizados para que se obtenha um cenário realístico?

Para responder essas questões, o trabalho analisa um conjunto de características comuns em sistemas de entrega de mensagens (algumas específicas para os que adotam a especificação JMS), como: topologia de instalação, domínio de troca de mensagem, duração do benchmark, modos de entrega das mensagens, requisitos de escalabilidade, volume e tamanho das mensagens.

Quanto à topologia de instalação o trabalho destaca três opções: muitos produtores para poucos consumidores, poucos produtores para muitos consumidores e muitos produtores para muitos consumidores. Com certeza existem aplicações reais que utilizam cada um desses três modelos de topologia, sendo necessário, portanto que todos eles sejam utilizados para avaliar o MOM em um benchmark.

Quanto ao domínio do sistema de troca de mensagens, os autores destacam que tanto comunicações PTP quanto Pub/Sub são importantes para representar cenários reais. Quanto a desempenho, os dois domínios são bem diferentes, logo, um benchmark precisa avaliar ambos.

Quanto à duração do benchmark os autores afirmam que o ideal seria testa os

JMS Providers por meses, porém devido à inviabilidade desse procedimento,

eles defendem que no mínimo os experimentos devem durar 24 horas para sistemas críticos operando em um regime de 24x7. Ainda segundo eles, esse

134 Benchmarks

seria o tempo mínimo para avaliar possíveis congestionamentos de mensagens, crescimento do consumo de memória.

Quanto aos modos de entrega de mensagens, os autores destacam a necessidade de avaliar o sistema de persistência da solução. Em alguns casos, os JMS

Providers para acelerar esse mecanismo definem cache em memória,

diminuindo a confiabilidade da solução.

Quanto à escalabilidade, o trabalho ressalta que é importante avaliar tanto a capacidade do sistema em receber um número crescente de usuários conectados a um mesmo canal (destination), quanto avaliar a manipulação de um número crescente de canais.

Quanto ao volume e ao tamanho das mensagens, os autores ressaltam que esses dois parâmetros do componente básico da carga de trabalho impactam diretamente no desempenho, e por isso devem ser definidos cenários variando- os para avaliar o seu impacto.

Entre as conclusões do trabalho, uma das que se destaca é a necessidade de definição de cenários (incluindo a definição do ambiente) que reflitam situações realísticas e que exercitem o JMS Provider em todos os aspectos destacados. O trabalho finaliza concluindo que para tornar os resultados relevantes é necessário o atendimento a algumas condições: ambientes de teste similares aos de produção; experimentos de longa duração; cenários com múltiplos produtores e consumidores; garantia que todos os JMS Providers serão testados nas mesmas condições e com a mesma carga.

Em [Sonic2007], a Sonic Software ampliou o escopo das recomendações quanto à elaboração de benchmarks para avaliação de JMS Providers. Nesse novo estudo o contexto é o mesmo utilizado nesta dissertação: a utilização do MOM JMS como a base para o ESB em processos de integração e implantação de uma arquitetura orientada a serviços (SOA).

Os autores definem três passos para realizar um benchmarking entre plataformas de integração: planejar a necessidade futura de carga; comparar a eficiência dos vários modelos de integração; comparar o custo/benefício das soluções de entrega de mensagens. Isso mais uma vez ressalta o que este trabalho já vem afirmando que as plataformas de MOM são a chave para os modelos de integração atuais e futuros.

Outra contribuição importante que esse estudo traz é, segundo os autores, a constatação que nenhum processo substitui a experiência dos avaliadores. Ainda segundo eles, o ideal é o envolvimento de profissionais com experiência tanto em avaliação de desempenho quanto em MOM, para garantir que os resultados obtidos sejam relevantes.

Os avaliadores apresentam que para definir a carga de trabalho a ser submetida ao MOM durante os experimentos, dois parâmetros são fundamentais: taxa de produção de mensagens e o tamanho das mensagens. Para definir avaliar cenários realísticos de integração, os autores sugerem que os cenários possuam taxas de produção e tamanho das mensagens definidas através de matrizes, permitindo assim que em um mesmo cenário se possa ter um mix de mensagens diferentes, assim como produtores com comportamento de geração de carga distinto.

Uma inovação desse estudo [Sonic 2007] em relação à versão anterior [Sonic 2004] é a definição de novas métricas para avaliar os sistemas. O estudo anterior praticamente definia apenas a vazão como métrica de avaliação. Nesse novo estudo, além da vazão é definida a Latência e o número de Exceções. A Latência mede o atraso médio inserido no processo de entrega de mensagens. O número de exceções determina a quantidade de falhas, mensagens rejeitadas ou transações abortadas.

Além dessas métricas, o trabalho define a importância de se monitorar o consumo de recursos importantes para o funcionamento do sistema, e que sejam finitos. Para tanto eles definem outras métricas para serem acompanhadas: utilização de CPU, utilização de memória, threads contidas, utilização da rede, taxa de E/S.

6.2.2 SPEC

A SPEC juntamente com a participação de centros de pesquisas acadêmicos e da indústria (ex. TU-Darmstadt, IBM, Sun, BEA, Sybase, Apache, Oracle, JBoss) desenvolveu um benchmark para avaliação de JMS Providers denominado SPECjms2007 [SPEC 2007].

As publicações [Sachs et al. 2007a] e [Sachs et al. 2007b] apresentam esse

benchmark descrevendo principalmente a sua caracterização de carga, enquanto

que em [Kounev e Sachs 2008] os autores descrevem suas características funcionais e algumas peculiaridades importantes para esta dissertação, como um

framework para avaliação de desempenho de MOM.

Esse framework compõe um importante diferencial do SPECjms2007. Ele permite que os avaliadores customizem a carga de trabalho para suas necessidades, configurando o nível de estresse desejado para a infra-estrutura de MOM, sendo capaz de com isso representar cenários específicos de carga. Entretanto, os autores ressaltam que para a utilização dessas facilidades é necessário o entendimento da forma com que a carga de trabalho é decomposta em componentes básicos, e como cada um desses componentes básicos influencia no desempenho do MOM.

O objetivo do SPECjms2007 é prover uma carga de trabalho padrão e métricas para medir e avaliar o desempenho e a escalabilidade de uma plataforma de MOM baseada na especificação JMS. Para conseguir atingir esse objetivo a carga de trabalho do SPECjms2007 precisa preencher alguns requisitos importantes.

Primeiramente, ele deve ser baseado em um cenário de carga de trabalho que seja representativo em relação à utilização no mundo real desse tipo de plataforma. Com isso os usuários, ao analisar os resultados do benchmark, podem observar comportamentos similares aos seus ambientes reais.

O segundo requisito é quanto à capacidade da carga de trabalho explorar todas as funcionalidades normalmente utilizadas nas plataformas de MOM, incluindo ambos os estilos de comunicação PTP e Pub/Sub. As funcionalidades e serviços são estressados pelo benchmark de acordo com o peso que eles são utilizados em cenários reais.

136 Benchmarks

O próximo requisito é que a carga deve realizar a medição do desempenho e da escalabilidade, tanto da plataforma de MOM quanto da plataforma de hardware que suporta o sistema de entrega de mensagens. Ou seja, o resultado do

benchmark determina o desempenho desse conjunto que não deve ser separado,

pois um influencia diretamente no outro. O importante desse requisito é que ele deixa de fora a avaliação de sistemas auxiliares como sistemas gerenciadores de banco de dados, que poderiam comprometer a comparação dos resultados.

Finalmente, a carga de trabalho do SPECjms2007 não deve ter qualquer limitação inerente ao benchmark, sendo necessário que ela possa ser escalada incrementando tanto o número de Destinations (filas e tópicos) assim como a quantidade de tráfego que passa por cada um deles.

O cenário escolhido para o SPECjms2007 modela um sistema de gerenciamento da cadeia de suprimentos (SCM) de um supermercado. Participam dessa cadeia as seguintes entidades: matriz (HQ), fornecedores (SP), centros de distribuição (DC) e lojas (SM).

A carga de trabalho gerada nesse cenário simula situações típicas de troca de mensagens para integração entre as aplicações dessas entidades. Para representar essas situações o benchmark define sete interações básicas envolvendo troca de mensagens:

Interação 1 – solicitação e atendimento de pedidos entre as lojas (SM) e os centros de distribuição (DC) via comunicação PTP;

Interação 2 – solicitação e atendimento de pedidos entre os centros de distribuição (DC) e os fornecedores (SP) via comunicação PTP;

Interação 3 – atualização de preços comandada pela matriz (SM) para as lojas (SM) via comunicação Pub/Sub;

Interação 4 – inventário das lojas (SM), permitindo que a matriz (HQ) seja informada das posições de estoque, via comunicação PTP;

Interação 5 – envio de estatística de vendas das lojas (SM) para a matriz (HQ) via comunicação PTP;

Interação 6 – anúncio de novos produtos por parte da matriz (HQ) para as lojas (SM) via comunicação Pub/Sub;

Interação 7 – envio de informações de crédito por parte da matriz (HQ) para as lojas (SM) via comunicação Pub/Sub.

Em cada uma das interações é produzido um conjunto de mensagens que varia em termos de formato, estilo de comunicação (PTP ou Pub/Sub), Destination, modelo de confiabilidade (persistência, integridade transacional), modelo de assinatura (Durable, NonDurable). A Tabela 6-1 apresenta a lista de todas as mensagens trocadas em cada interação.

Tabela 6-1. Tipos de mensagens utilizadas em cada interação do SPECjms2007.

Int. Mensagem Destination Formato Pers Trans Dur

1 order Queue (DC) ObjectMsg X X

1 orderConf Queue (SM) ObjectMsg X X

1 shipDep Queue (DC) TextMsg X X

Int. Mensagem Destination Formato Pers Trans Dur

1 shipInfo Queue (SM) TextMsg X X

1 shipConf Queue (DC) ObjectMsg X X

2 callForOffers Topic (HQ) TextMsg X X X

2 Offer Queue (DC) TextMsg X X

2 pOrder Queue (SP) TextMsg X X

2 pOrderConf Queue (DC) TextMsg X X

2 Invoice Queue (HQ) TextMsg X X

2 pShipInfo Queue (DC) TextMsg X X

2 pShipConf Queue (SP) TextMsg X X

2 statInfoShipDC Queue (HQ) StreamMsg

3 priceUpdate Topic (HQ) MapMsg X X X

4 inventoryInfo Queue (SM) TextMsg X X 5 statInfoSM Queue (HQ) ObjectMsg

6 productAnnouncement Topic (HQ) StreamMsg 7 creditCardHL Topic (HQ) StreamMsg

O SPECjms2007 oferece três topologias diferentes para estruturar a carga de trabalho: horizontal, vertical e livre. As duas primeiras topologias avaliam a escalabilidade de um MOM em dimensões distintas. Na primeira dimensão (topologia vertical), a avaliação se concentra na capacidade de um Destination encaminhar mensagens (escalabilidade do tópico). Essa avaliação é obtida aumentando-se a quantidade de tráfego gerado por localização (loja, centro de distribuição, etc.), simulando um aumento na quantidade de negociações envolvendo um número fixo de entidades (localizações).

Na segunda dimensão (topologia horizontal) a avaliação está focada na capacidade de entrega de mensagens do servidor como um todo (escalabilidade do JMS Provider), avaliando principalmente o gerenciamento de múltiplos

Destinations. Para conseguir isso se incrementa a quantidade de centros de

distribuição (DC), lojas (SM), fornecedores (SP), enquanto que o tráfego gerado por cada localização é mantido constante.

Já a topologia livre refere-se exatamente ao framework provido em conjunto com SPECjms2007, que permite a configuração da carga de trabalho, fazendo com que o avaliador possa configurar um mix entre as interações diferente do padrão estabelecido nas outras topologias. O framework permite a configuração personalizada dos seguintes parâmetros: quantidade de localizações, tráfego gerado por cada localização, tamanho das mensagens, modelo de confiabilidade. O usuário pode ainda escolher seletivamente as interações desejadas.

6.3

Modelagem

Os trabalhos de Menascé et al. [Menascé 2005] [Menascé et al. 1994] [Menascé et al. 1999] [Menascé et al. 2004] [Menascé e Almeida 1998] [Menascé e Almeida 2000] [Menascé e Almeida 2002] [Menascé e Gomma 2000] [Almeida

138 Modelagem

e Menascé 2002] utiliza a técnica de modelagem com o formalismo das redes de fila (Queueing Networks, QNs). As QNs são um formalismo gráfico que tanto podem ser utilizados para avaliação analítica quanto para simulação. Esses trabalhos apresentam também fundamentação da técnica de medição, quase sempre para validar e complementar a avaliação realizada pelos modelos.

Os trabalhos de Kounev et al. [Kounev 2005] [Kounev 2006] [Kounev e Buchmann 2002] [Kounev e Buchmann 2003a] [Kounev e Buchmann 2003b] [Kounev e Buchmann 2006] [Kounev e Buchmann 2007] [Kounev et al. 2008] também são na área de avaliação de desempenho de sistemas distribuídos utilizando a técnica de modelagem. O formalismo escolhido é baseado numa junção das GSPNs (utilizada nesta dissertação), com as redes de Petri coloridas e as redes de filas, e é denominado Queueing Petri Net (QPN). As QPNs têm como um dos pontos fortes o poder de representação elevado, com um aumento da abstração e com isso uma maior facilidade para modelar sistemas distribuídos.

As próximas subseções trazem uma coletânea de alguns desses trabalhos, além de outros trabalhos desenvolvidos utilizando modelos para avaliação de desempenho de sistemas distribuídos, e sempre que possível focando na modelagem de plataformas de MOM.