Otimizando Tempos de Resposta do Fluxo de Mensagens

Antes de começar:

Leia o tópico de conceitos sobre os nós do fluxo de mensagens.

Ao projetar um fluxo de mensagens, a flexibilidade e importância dos nós internos indicam que há várias maneiras de alcançar o processamento e, portanto, os resultados finais requeridos. No entanto, você também pode perceber que essas diferentes soluções geram desempenho diferente e, se esta for uma consideração importante, será necessário projetar o desempenho e também o funcionamento.

Existem duas formas nas quais seus aplicativos podem perceber o desempenho:

  1. Tempo de resposta. Indica a rapidez com que cada mensagem é processada pelo fluxo de mensagens. Isso tem uma grande influência na forma pela qual você projeta seus fluxos de mensagens. Isso é discutido com detalhes adicionais neste tópico.
  2. Rendimento do Processamento. Indica quantas mensagens de tamanhos específicos podem ser processadas por um fluxo de mensagens em determinado tempo. Isso é afetado principalmente por fatores de configuração e de recursos do sistema e, portanto, é discutido em Otimizando o Rendimento do Processamento do Fluxo de Mensagens com outras informações de configuração de domínio.

Existem vários aspectos que influenciam os tempos de resposta do fluxo de mensagens. No entanto, conforme você cria e modifica o design de seu fluxo de mensagens para alcançar os melhores resultados que atendam aos seus requisitos de negócios específicos, também deve considerar a eventual complexidade do fluxo de mensagens. Os fluxos de mensagens mais eficientes não são necessariamente os mais fáceis de entender e manter; tente as soluções disponíveis para alcançar o melhor equilíbrio para suas necessidades.

Vários fatores influenciam os tempos de resposta de fluxos de mensagens:

O Número de Nós Incluídos no Fluxo de Mensagens
Cada nó provoca alguma sobrecarga de processamento, portanto considere o conteúdo do fluxo de mensagens com atenção, incluindo a utilização de subfluxos.

Utilize o menor número de nós possível em um fluxo de mensagens; cada nó incluído no fluxo de mensagens aumenta a sobrecarga no intermediário. Existe um limite superior para o número de nós em um único fluxo. Este limite é regido pelos recursos do sistema, principalmente o tamanho da pilha.

Para obter informações adicionais sobre tamanhos de pilhas, consulte Considerações do Sistema para o Desenvolvimento do Fluxo de Mensagens.

Como o Fluxo de Mensagens Roteia e Processa as Mensagens
Em algumas situações, você pode perceber que os nós internos e, talvez, outros nós que estão disponíveis em seu sistema, oferecem mais de uma forma de fornecer a mesma função. Tente escolher a configuração mais simples. Por exemplo, se desejar definir algum processamento específico com base no valor de um campo em cada mensagem, poderá projetar um fluxo de mensagens que tenha uma seqüência de nós Filter para tratar cada caso. Se apropriado, você pode agrupar mensagens através do nó Filter para reduzir o número pelo qual cada tipo de mensagem tem que passar antes de ser processada.

Por exemplo, você pode ter um fluxo de mensagens que trata oito mensagens diferentes (Invoice, Despatch Note e outras). Você pode incluir um nó Filter para identificar cada tipo de mensagem e roteá-la de acordo com seu tipo. Você pode otimizar o desempenho desta técnica testando os tipos de mensagens mais freqüentes nos nós Filter mais antigos. No entanto, o oitavo tipo de mensagem sempre deve passar por oito nós Filter.

Se você puder agrupar os tipos de mensagens (por exemplo, se o tipo de mensagem for numérico e você puder testar para todos os tipos de mensagens maiores que quatro e menores que quatro), poderá reduzir o número de nós Filter requeridos. O primeiro nó Filter testa para menos de quatro e transmite a mensagem para dois nós Filter adicionais (conectados aos terminais true e false) que testam para menos de dois e menos de seis, respectivamente. Os quatro nós Filter adicionais podem então ser testados para um, dois, três ou quatro e assim por diante. Embora o número real de nós Filter requerido seja o mesmo, o número de nós pelos quais cada mensagem passa é reduzido.

Você pode notar que, utilizar um nó RouteToLabel com um conjunto de nós Label fornece melhor alternativa para uma seqüência de nós Filter. Cada mensagem passa por um número menor de nó, melhorando o rendimento do processamento. No entanto, você também deve considerar que a utilização do nó RouteToLabel significa utilizar um nó Compute: a sobrecarga deste nó pode exceder as vantagens. Se você estiver lidando com um número limitado de tipos de mensagens, um pequeno número de nós Filter é mais eficiente.

O Amostra Airline Reservations demonstra como é possível utilizar os nós RouteToLabel e Label em vez de utilizar vários nós Filter no fluxo de mensagens XML_PassengerQuery. O Amostra Message Routing demonstra como é possível armazenar as informações de roteamento em uma tabela do banco de dados em um cache de memória no fluxo de mensagens.

Se Seu fluxo de mensagens Inclui Loops
Evite loops de nós de repetição; eles podem ser muito ineficientes e provocar problemas de desempenho e de pilha. Você pode observar que um nó Compute com várias instruções PROPAGATE evita a necessidade de fazer um ciclo em loop em uma série de nós.
A Eficiência do ESQL
Verifique todo o código ESQL criado para seus nós do fluxo de mensagens. À medida que desenvolve e testa um nó, você pode manter instruções que não sejam requeridas após a finalização do processamento de mensagens. Você também pode observar que alguma coisa que foi codificada como duas instruções pode ser codificada como uma. Reservar um tempo para rever e verificar seu código ESQL pode oferecer simplificação e aperfeiçoamentos de desempenho.

Se você tiver importado fluxos de mensagens de um release anterior, verifique as instruções ESQL na variável ESQL na Versão 5.0 para ver se é possível utilizar novas funções ou instruções para melhorar sua eficiência.

A Utilização de Mensagens Persistentes e Transacionais
As mensagens persistentes são salvas em disco durante o processamento do fluxo de mensagens. Isso será evitado se você puder especificar que as mensagens na entrada, na saída ou nas duas, não são persistentes. Se seu fluxo de mensagens estiver tratando apenas mensagens não-persistentes, verifique a configuração dos nós e o próprio fluxo de mensagens; se suas mensagens não forem persistentes, o suporte a transações pode ser desnecessário. A configuração padrão de alguns nós força a capacidade da transação; se você atualizar essas propriedades e reimplementar o fluxo de mensagens, os tempos de resposta podem ser aprimorados.
Tamanho da Mensagem
Uma mensagem maior leva mais tempo para ser processada. Se você puder dividir mensagens grandes em blocos de informações menores, isso poderá aprimorar a velocidade na qual elas são tratadas pelo fluxo de mensagens. O Amostra Large Messaging demonstra como minimizar os requisitos de memória virtual para o fluxo de mensagens para melhorar o desempenho de um fluxo de mensagens ao processar mensagens potencialmente grandes.
Formato de Mensagem
Embora o WebSphere Message Broker suporte vários formatos de mensagens e forneça recursos que podem ser utilizados para transformação de um formato para outro, isto não resulta em sobrecarga. Certifique-se de não executar conversões ou transformações desnecessárias.

É possível localizar informações adicionais sobre o aprimoramento do desempenho de um fluxo de mensagens em Artigo do developerWorks sobre o Desempenho do Fluxo de Mensagens.

Conceitos relacionados
Visão Geral de Fluxos de Mensagens
Visão Geral da Implementação
Considerações do Sistema para o Desenvolvimento do Fluxo de Mensagens
Tarefas relacionadas
Configurando o Domínio do Intermediário
Otimizando o Rendimento do Processamento do Fluxo de Mensagens
Projetando um Fluxo de Mensagens
Utilizando Mais de Um Nó Input
Criação de um Fluxo de Mensagens
Definindo o Conteúdo do Fluxo de Mensagens
Editando Propriedades Configuráveis
Referências relacionadas
Nós Internos
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback
Direitos Autorais IBM Corporation 1999, 2006 Última Atualização: 1 Sep 2006
ac00355_