Estudo de caso: Ajustando o WebSphere Application Server V7 para desempenho

O IBM® WebSphere® Application Server suporta uma gama sempre crescente de aplicativos, cada um com seu próprio conjunto exclusivo de recursos, requisitos e serviços. Simplesmente como dois aplicativos não utilizarão um servidor de aplicativo no mesmo lugar exatamente, nenhum conjunto de parâmetros de ajuste provavelmente fornecerá melhor desempenho para qualquer um dos dois aplicativos diferentes. A maioria dos aplicativos geralmente terá alguma melhora de desempenho com o ajuste em três áreas principais: JVM, conjuntos de encadeamentos e conjuntos de conexões. Este artigo utiliza o aplicativo Apache DayTrader Performance Benchmark Sample para demonstrar o que é possível ajustar e como realizar seu ajuste, dependendo dos principais componentes e recursos do servidor que seu aplicativo utiliza. Este conteúdo é parte do IBM WebSphere Developer Technical Journal.

Christopher Blythe, Advisory Software Engineer, IBM

Photo of Christopher BlytheChristopher Blythe é Engenheiro Consultivo de Software e líder da equipe técnica da organização de Desempenho e Comparação do WebSphere Application Server no Research Triangle Park, Carolina do Norte. Suas áreas de interesse atualmente incluem aspectos de desempenho associados com tecnologias de núcleo Java EE e outras tecnologias emergentes, como WebSphere CloudBurst Appliance e WebSphere sMash. Como membro há 8 anos da organização WebSphere, ele é um dos colaboradores originais do IBM Trade Benchmark Sample para o WebSphere Application Server e continua a contribuir com o projeto Apache DayTrader Benchmark como controlador Apache Geronimo.



David Hare, Staff Software Engineer, IBM  

Author photoDavid Hare é Engenheiro da Equipe de Software na organização de Desempenho e Comparação do WebSphere Application Server no Research Triangle Park, Carolina do Norte. David tem 5 anos de experiência em ajudar os clientes a resolverem problemas de configuração, segurança/SSL e desempenho com o WebSphere Application Server. Seu foco principal tem sido a avaliação de desempenho do DayTrader, juntamente com tarefas de configuração como a implementação de aplicativos.



09/Nov/2009

Introdução

O IBM WebSphere Application Server é um aplicativo de servidor robusto, de nível corporativo que oferece um conjunto de componentes, recursos e serviços principais que os desenvolvedores podem utilizar em seus aplicativos. Cada aplicativo tem um conjunto exclusivo de requisitos e frequentemente utiliza os recursos de um servidor de aplicativo de formas muito diferentes. Para oferecer um alto grau de flexibilidade e suporte para essa ampla variedade de aplicativos, o WebSphere Application Server oferece uma lista abrangente de "botões" de ajuste e parâmetros que você pode usar para aprimoramento e desempenho do aplicativo.

Os valores-padrão para a maioria dos parâmetros de ajuste comumente utilizados no servidor de aplicativos são definidos para assegurar desempenho adequado sem necessidade de configurações ou ajustes adicionais para a maior gama de aplicativos. Entretanto, como dois aplicativos provavelmente não utilizam o servidor de aplicativos exatamente da mesma forma, não há garantias de que um único conjunto de parâmetros de ajuste seja perfeitamente adequado para todos os aplicativos. Esta realidade chama a atenção para a importância de realizar testes específicos de desempenho e ajuste em seus aplicativos.

Este artigo discute diversos dos parâmetros mais utilizados no WebSphere Application Server V7.0 (e versões anteriores) e as metodologias utilizadas para ajustá-los. Diferente de muitas recomendações de ajuste documentadas, este artigo utiliza o aplicativo Apache DayTrader Performance Benchmark Sample como estudo de caso para contextualizar a discussão. Com o aplicativo DayTrader, é possível identificar claramente os componentes principais do servidor em uso, realizar ajuste focado nessas áreas e comprovar o benefício associado com cada mudança de ajuste.

Antes de proceder, aqui estão alguns tópicos adicionais para lembrar ao ajustar o servido de aplicativos para desempenho:

  • O aumento de desempenho frequentemente pode comprometer certo nível de recurso ou função no aplicativo ou servidor de aplicativos. As vantagens e desvantagens entre desempenho e recurso devem ser pesadas cuidadosamente ao avaliar as mudanças de ajuste de desempenho.
  • Diversos fatores além do servidor de aplicativos podem causar impacto no desempenho, inclusive configuração de hardware e do SO, outro processos em execução no sistema, desempenho de recursos do banco de dados de backend, latência da rede, e assim por diante. É necessário incluir esses itens ao realizar as avaliações de desempenho.
  • As melhoras de desempenho detalhadas aqui são específicas para o aplicativo DayTrader, combinação de carga de trabalho e hardware e pilha de software de suporte aqui descritos. Quaisquer ganhos de desempenho para o aplicativo que resultem das mudanças de ajuste detalhadas neste artigo certamente devem variar e devem ser avaliadas com testes próprios de desempenho.

O aplicativo DayTrader

O aplicativo Apache DayTrader Performance Benchmark Sample simula um aplicativo simples de comércio de ações que permite que os usuários façam login/logout, visualizem seu portfólio, pesquisem valor de ações, comprem em vendam lotes de ações e gerenciem informações sobre a conta. O DayTrader não apenas atua como excelente aplicativo para teste funcional, como também oferece um conjunto padrão de cargas de trabalho para caracterizar e mensurar o desempenho do servidor de aplicativos e nível de componente. O DayTrader (e o aplicativo Trade Performance Benchmark Sample da IBM no qual o DayTrader foi originalmente baseado) não foi escrito para fornecer ótimo desempenho. Pelo contrário, os aplicativos são destinados a realizarem comparações relativas de desempenho entre as versões de servidor de aplicativos e estilos e padrões alternativos de implementação.

O DayTrader é construído em um conjunto principal de tecnologias Java™ Enterprise Edition (Java EE) que inclui servlets Java e JavaServer™ Pages (JSPs) para a camada de apresentação, além de Java database connectivity (JDBC), Java Message Service (JMS), Enterprise JavaBeans™ (EJBs) e beans acionados por mensagens (MDBs) para a lógica de negócios de backend e camada de persistência. A Figura 1 mostra uma visão geral resumida da arquitetura do aplicativo.

Figura 1. Visão geral do aplicativo DayTrader
Figure 1. DayTrader application overview

Para a avaliação de alguns padrões de gerenciamento comuns de persistência e transação Java EE, o DayTrader oferece três implementações diferentes dos serviços de negócios. Essas implementações (ou modos de tempo de execução) são mostradas na Tabela 1.

Tabela 1. Implementações do DayTrader
Modo de tempo de execuçãoPadrãoDescrição
DiretoServlet para JDBCAs operações de criação, leitura, atualização e exclusão (CRUD) são realizadas diretamente no banco de dados utilizando o código JDBC customizado. As conexões com o banco de dados, envios e retrocessos são gerenciados manualmente no código.
Sessão DiretaServlet para Bean de Sessão Stateless para JDBCAs operações CRUD são realizadas diretamente no banco de dados utilizando código JDBC customizado. As conexões com o banco de dados são gerenciadas manualmente no código. Os envios e retrocessos do banco de dados são gerenciados automaticamente pelo bean de sessão stateless.
EJBServlet para Bean de Sessão Stateless para Bean de EntidadeO contêiner EJB assume a responsabilidade por todas as consultas, transações e conexões com o banco de dados.

Esses modos de tempo de execução estão incluídos no escopo deste artigo para demonstrar o impacto de cada mudança de ajuste sobre esses três estilos de implementação de persistência e transação Java EE.


Navegando os itens ajustáveis do WebSphere Application Server

Como anteriormente mencionado, a importância de entender a arquitetura do aplicativo, os componentes do servidor e os recursos utilizados pelo aplicativo não pode ser enfatizada o suficiente quando se realiza um ajuste de desempenho. Com isso em mente, é possível filtrar rapidamente a lista de parâmetros ajustáveis e focar em um conjunto principal de itens ajustáveis que causem impacto direto no seu aplicativo.

O ajuste de desempenho geralmente começa com o Java Virtual Machine (JVM), que atual como base para o servidor de aplicativos. Desse ponto em diante, o ajuste é primariamente conduzido pelos componentes do servidor de aplicativo utilizados pelo aplicativo. Por exemplo, é possível identificar alguns dos principais componentes do servidor ajustáveis do aplicativo DayTrader utilizando o diagrama de arquitetura (Figura 1):

  • Contêineres de Web e de EJB
  • Conjuntos de encadeamentos associados
  • Conjuntos de conexão com o banco de dados
  • Provedor de sistemas de mensagens padrão.

O restante deste artigo discute os detalhes das diversas opções de ajuste que causam impacto no desempenho do DayTrader com base nos componentes listados acima. Essas opções foram divididas nas seguintes seções:

  • Ajuste básico: Esse grupo de parâmetros de ajuste cobre alguns dos componentes de servidor de aplicativos mais comumente ajustados e mais utilizados, a começar pelo JVM. Essas configurações tradicionalmente oferecem a melhor eficiência.
  • Ajuste avançado: Esse grupo secundário de parâmetros avançados de ajuste é geralmente específico a um determinado cenário e normalmente é utilizado para conseguir o máximo de desempenho de um sistema.
  • Ajuste de sistema de mensagens assíncrono: As opções discutidas aqui são específicas para aplicativos que utilizam os componentes do sistema de mensagens do WebSphere Application Server para sistema de mensagens assíncrono.

Os parâmetros de ajuste agrupados nessas seções são apresentados com uma discussão detalhada da aplicabilidade e informações relacionadas às trocas funcionais e seu impacto final sobre o desempenho (para cada um dos padrões de gerenciamento de transação e persistência, se aplicável). As ferramentas que podem auxiliar no processo de ajuste para determinado parâmetro também são apresentadas. São fornecidos links para documentação associada ao WebSphere Application Server Information Center ou outros recursos em cada seção, além de um resumo deles na seção Resources.


Ajuste básico

Discutido nesta seção:

  1. Tamanho de heap JVM
  2. Tamanho do conjunto de encadeamentos
  3. Tamanho do conjunto de conexões
  4. Tamanho do cache de instrução de origem de dados
  5. Passagem por referência do ORB

a. Tamanho de heap JVM

Os parâmetros de tamanho de heap JVM influenciam diretamente o comportamento da coleta de lixo. Aumentar o tamanho de heap JVM permite que mais objetos sejam criados antes que ocorra uma falha de alocação e o acionamento da coleta de lixo. Isso permite que o aplicativo seja naturalmente executado por um maior período de tempo entre os ciclos de coleta de lixo (GC). Infelizmente, um aspecto negativo associado ao tamanho de heap aumentado é um aumento correspondente no tempo necessário para encontrar e processar objetos que devem ser coletados como lixo. Consequentemente, o ajuste de tamanho de heap JVM normalmente envolve um equilíbrio entre o intervalo entre as coletas de lixo e o tempo de pausa necessário para realizar a coleta de lixo.

Para ajustar o tamanho de heap JVM, é necessário ativar a GC detalhada. Isso pode ser feito no console administrativo do WebSphere Application Server navegando para Servers => Application servers => server_name => Process definition => Java Virtual Machine. Ativando a GC detalhada, o JVM imprime informações úteis a cada coleta de lixo, como a quantidade de bytes livres e utilizados no heap, o intervalo entre as coletas de lixo e o tempo de pausa. Essas informações são registradas no arquivo native_stderr.log, que pode então ser utilizado por várias ferramentas para visualizar o uso do heap.

As configurações padrão do heap do WebSphere Application Server são 50 MB para o tamanho de heap inicial e 256 MB para o tamanho máximo de heap. Geralmente é ideal configurar os tamanhos mínimo e máximo de heap para o mesmo valor para evitar que o JVM redimensione dinamicamente o heap. Isso não apenas torna a análise da GC mais fácil ao fixar um parâmetro em um valor constante, mas também evita o gasto adicional associado com a alocação e desalocação de mais memória. A desvantagem de configurar tamanhos mínimo e máximo de heap para o mesmo valor é que a primeira inicialização do JVM será mais lenta porque o JVM precisa alocar o heap maior.

Há cenários em que a configuração de valores mínimo e máximo diferentes de heap é vantajosa. Um deles é quando várias instâncias do servidor de aplicativos executando diferentes cargas de trabalho são hospedadas no mesmo servidor. Nesse cenário, o JVM pode responder dinamicamente aos requisitos mutáveis de carga de trabalho e utilizar a memória do sistema com mais eficiência.

Teste

Quatro testes de laboratório foram realizados com a GC detalhada ativada, com tamanhos iniciais e máximos de heap configurados em 256 MB, 512 MB, 1024 MB e 2048 MB, respectivamente. É possível analisar a GC detalhada manualmente, mas as ferramentas gráficas como a ferramenta IBM Monitoring and Diagnostic Tools para Java - Garbage Collection and Memory Visualizer (oferecida juntamente com o IBM Support Assistant, gratuito para download) podem tornar o processo consideravelmente mais fácil. Essa ferramenta foi utilizada nos testes de laboratório para visualizar os dados da GC detalhada para que os ajustes pudessem ser feitos ao encontrar o tamanho apropriado de heap para o aplicativo DayTrader.

Um dos primeiros itens a monitorar no resultado da coleta de lixo detalhada é o heap livre após a coleta. Essa métrica é comumente utilizada para determinar se há fugas de memória Java no aplicativo. Se essa métrica não alcançar um valor de estado estável e continuar a diminuir ao longo do tempo, é necessário ter um indicativo claro de que há uma fuga de memória no aplicativo. A métrica de heap livre depois da coleta também pode ser utilizada em conjunto com o tamanho de heap para calcular o conjunto de trabalhos da memória (ou "área de cobertura") utilizado pelo servidor e pelo aplicativo. Simplesmente subtraia o valor de heap livre do tamanho total de heap para obter esse valor.

Figura 2. Resumo de heap livre depois da coleta
Figure 2. Free heap after collection summary

Fique ciente de que embora os dados da GC detalhada no gráfico da Figura 2 possam ajudar a detectar fugas de memória no heap Java, eles não podem detectar fuga de memória nativa. Fugas de memória nativa ocorrem quando componentes nativos (como bibliotecas nativas de fornecedor escritas em C/C++ e chamadas via APIs de Java Native Interface (JNI)) fogem da memória nativa para fora do heap Java. Nessas situações, é necessário utilizar ferramentas específicas à plataforma (como comandos ps e top em plataformas Linux®, Perfmon em plataformas Windows®, e assim por diante) para monitorar o uso de memória nativa para os processos Java. A Página WebSphere Application Server Support tem documentação detalhada sobre o diagnóstico de fugas de memória.

Duas métricas adicionais são os intervalos de coleta de dados e os tempos médios de pausa para cada coleta. O intervalo da GC é a quantidade de tempo entre os ciclos de coleta de dados. O tempo de pausa é a quantidade de tempo que um ciclo de coleta de dados leva para ser concluído. A Figura 3 apresenta os intervalos de coleta de lixo para cada um dos quatro tamanhos de heap. A média deles foi 0,6 segundos (256 MB), 1,5 segundos (512 MB), 3,2 segundos (1024 MB) e 6,7 segundos (2048 MB).

Figura 3. Intervalos de coleta de dados
Figure 3. Garbage collection intervals

A Figura 4 apresenta os tempos médios de pausa para cada um dos quatro tamanhos de heap. No teste de laboratório, a média deles foi 62 ms (256 MB), 69 ms (512 MB), 83 ms (1024 MB) e 117 ms (2048 MB). Isso demonstra claramente a desvantagem padrão associada com o aumento do tamanho de heap Java. Conforme o tamanho de heap aumenta, o intervalo entre as GCs aumenta, permitindo que mais trabalho seja realizado antes que o JVM pause para executar suas rotinas de coleta de lixo. Entretanto, aumentar o heap também significa que o coletor de lixo deve processar mais objetos e, por sua vez, leva a maiores tempos de pausa de GC.

Figura 4. Tempos médios de pausa
Figure 4. Average pause times

Os tempos de intervalo de GC e de pausa juntos compõem a quantidade de tempo gasta na coleta de lixo. O percentual de tempo gasto na coleta de lixo é demonstrado na ferramenta IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer e pode ser calculado utilizando a seguinte fórmula:

Percentage of time spent in garbage collection

A quantidade de tempo gasto na coleta de lixo e o rendimento resultante (solicitações por segundo) para cada uma dessas execuções são demonstrados na Figura 5.

Figura 5. Tempo gasto na coleta de lixo e rendimento
Figure 5. Time spent in garbage collection and throughput

Uma configuração recomendada para tamanho inicial e máximo de heap para o aplicativo DayTrader seria 1024 MB. Assim, atinge-se um pico de diminuição das devoluções marginais onde o aumento do tamanho de heap não rende benefício de desempenho proporcional. Isso oferece um bom equilíbrio entre os maiores intervalos de coleta de lixo e menores tempos de pausa, o que resulta em menos tempo gasto na coleta de lixo.

Outro aspecto importante do ajuste JVM é a política de coleta de lixo. As três principais políticas de GC são:

  • optthruput: (padrão) Realiza operações de marcação e varredura durante a coleta de lixo quando o aplicativo é pausado para maximizar o rendimento do aplicativo.
  • optavgpause: Realiza as operações de marcação e varredura simultaneamente enquanto o aplicativo está sendo executado para minimizar os tempos de pausa. Isso oferece os melhores tempos de resposta do aplicativo.
  • gencon: Trata objetos com ciclo de vida curto e longo de forma diferente para oferecer uma combinação de tempos de pausa menores e alto rendimento do aplicativo.

O aplicativo DayTrader não utiliza muitos objetos com ciclos de vida longos e normalmente é melhor executado com a política padrão de GC optthruput. Entretanto, cada aplicativo é diferente e portanto é necessário avaliar cada política de GC para descobrir a que melhor se adapta ao seu aplicativo. O artigo Garbage collection policies do developerWorks é um ótimo recurso para saber mais sobre as políticas de GC.

A Figura 6 apresenta o ganho de desempenho alcançado (determinado com base no rendimento do aplicativo) ao ajustar o tamanho de heap JVM para cada um dos diferentes modos de tempo de execução do DayTrader. No gráfico, as barras azuis sempre representam os valores básicos de rendimento e as barras vermelhas representam os valores de rendimento depois do ajuste do parâmetro discutido. Para apresentar as diferenças relativas de rendimento entre os vários modos de tempo de execução, todas as medições são comparadas com o modo EJB básico.

Por exemplo, antes do ajuste, o modo Sessão Direta e o modo Direto são 23% e 86% mais rápidos que o modo EJB básico, respectivamente. A linha sobre o eixo secundário representa a melhora de desempenho geral para cada um dos modos de tempo de execução. Nesse caso, o ajuste do JVM resultou em melhoras variadas para os três modos de tempo de execução devido a padrões exclusivos de alocação de objetos associados a cada modo. Essas melhorias atingiram de 3% (para o modo JDBC) a 9% (para o modo EJB).

Essas informações serão demonstradas no final de cada parâmetro de ajuste, onde aplicável. A melhora de desempenho após a aplicação de cada parâmetro de ajuste é cumulativa, construída sobre parâmetros das seções anteriores. Um gráfico ao final desse artigo (Figura 22) exibe a melhora geral de desempenho conseguida com todas as mudanças de ajustes aplicadas.

Figura 6. Benefício de desempenho de tamanho de heap ajustado JVM
Figure 6. Performance benefit of tuned JVM heap size

Para obter mais informações, consulte:

b. Tamanho do conjunto de encadeamentos

Cada tarefa realizada pelo servidor é executada em um encadeamento obtido a partir de um dos vários conjuntos de encadeamentos do WebSphere Application Server. Um conjunto de encadeamentos permite que os componentes do servidor reutilizem os encadeamentos, eliminando a necessidade de criar novos encadeamentos no tempo de execução para servir cada nova solicitação. Três dos conjuntos de encadeamentos mais comumente utilizados (e ajustados) no servidor de aplicativos são:

  • Contêiner da Web: Utilizado quando as solicitações chegam por HTTP. No diagrama da arquitetura DayTrader (Figura 1), é possível ver que a maior parte do tráfego vem para o DayTrader através do conjunto de encadeamentos do contêiner da Web.
  • Padrão: Usado quando as solicitações vêm para um bean acionado por mensagens ou se uma cadeia de transporte particular não tiver sido definida para um conjunto específico de encadeamentos.
  • ORB: Usado quando as solicitações remotas vêm através de RMI/IIOP um bean corporativo de um aplicativo cliente EJB, interface remota EJB ou outro servidor de aplicativos.

As opções ajustáveis importantes associadas com conjuntos de encadeamentos são demonstradas na Tabela 2.

Tabela 2. Opções ajustáveis de conjunto de caracteres
ConfiguraçãoDescrição
Tamanho mínimoO número mínimo de encadeamentos permitidos no conjunto. Quando um servidor de aplicativos é iniciado, nenhum encadeamento é inicialmente atribuído ao conjunto de encadeamentos. Os encadeamentos são adicionados ao conjunto de encadeamentos conforme a carga de trabalho atribuída ao servidor de aplicativos os solicita, até o número de encadeamentos no conjunto igualar o número especificado no campo tamanho mínimo. Depois desse ponto, outros encadeamentos são adicionados e removidos conforme a carga de trabalho muda. Entretanto, o número de encadeamentos no conjunto nunca cai abaixo do número especificado no campo tamanho mínimo, mesmo se alguns encadeamentos estiverem inativos.
Tamanho máximoEspecifica o número máximo de encadeamentos para manter o conjunto padrão de encadeamentos.
Tempo limite de inatividade encadeamentoEspecifica a quantidade de inatividade (em milissegundos) que deve decorrer antes que um encadeamento seja recuperado. Um valor de 0 indica não esperar e um valor negativo (menos de 0) significa esperar para sempre.

Supondo que a máquina contenha uma única instância do servidor de aplicativos, uma boa prática é usar 5 encadeamentos por núcleo de CPU de servidor para o conjunto de encadeamento padrão, e 10 encadeamentos por CPU de servidor para os conjuntos de encadeamento ORB e contêiner de Web. Para uma máquina com até 4 CPUs, as configurações padrão são normalmente um bom começo para a maioria dos aplicativos. Se uma máquina tem várias instâncias de servidor de aplicativos, então esses tamanhos devem ser reduzidos com base nisso. Por outro lado, pode haver situações em que o tamanho do conjunto de encadeamentos possa precisar ser aumentado para responsabilizar-se por conexões de E/S ou de longa execução em backend. A Tabela 3 mostra os tamanhos padrão de conjuntos de encadeamentos e tempos limite de inatividade para os conjuntos de encadeamento mais comumente ajustados.

Tabela 3. Tamanhos padrão de conjuntos de encadeamento e tempos limite de inatividade
Conjunto de encadeamentoTamanho mínimoTamanho máximoTempo limite de inatividade
Padrão20205000 ms
ORB10503500 ms
Contêiner de Web505060000 ms

As configurações de conjunto de encadeamentos no console administrativo podem ser mudadas navegando para Servers => Application Servers => server_name => Thread Pool. Também é possível utilizar os Orientadores de Desempenho para obter recomendações sobre tamanhos de conjunto de encadeamentos e outras configurações.

O IBM Tivoli® Performance Viewer é uma ferramenta integrada no console administrativo que permite a visualização dos dados da PMI (Performance Monitoring Infrastructure) associados com praticamente qualquer componente do servidor. O visualizador oferece orientação para ajudar a ajustar os sistemas para ótimo desempenho e recomenda alternativas para configurações ineficientes. Consulte o Centro de Informações do WebSphere Application Server para obter instruções sobre como ativar e visualizar dados PMI com o Tivoli Performance Viewer.

A Figura 7 mostra os dados PMI para o conjunto de encadeamentos do contêiner de Web enquanto o aplicativo teve sua utilização acelerada e foi executado sob uma carga constante de pico. O tamanho do conjunto (laranja) é o número médio de encadeamentos no conjunto, e a contagem ativa (vermelho) é o número de encadeamentos simultâneos ativos. Este gráfico mostra que a configuração padrão de 50 encadeamentos máximos para o contêiner de Web funciona bem neste caso, pois todos os 50 encadeamentos não foram alocados e a carga de trabalho média simultânea está utilizando cerca de 18 encaminhamentos. Como o tamanho padrão do conjunto de encadeamentos foi suficiente, nenhuma modificação foi realizada.

Figura 7. Dados PMI para conjunto de encadeamentos para contêiner de Web
Figure 7. PMI data for Web container thread pool

Antes do WebSphere Application Server V6.x, havia um mapeamento um-para-um entre o número de conexões simultâneas do cliente e os encadeamentos no conjunto de encadeamentos do contêiner de Web. Em outras palavras, se 40 clientes estavam acessando um aplicativo, 40 encadeamentos eram necessários para atender as solicitações. No WebSphere Application Server V6.0 e 6.1, Native IO (NIO) e Asynchronous IO (AIO) foram introduzidos, oferecendo a capacidade de escalar para milhares de conexões de cliente utilizando um número relativamente pequeno de encadeamentos. Isso explica porque, na Figura 7, uma média de 18 encadeamentos foi utilizada para servir 50 conexões simultâneas de cliente a partir do driver de carga de HTTP. Com base nessas informações, o tamanho de conjunto de encadeamentos pode ser baixado para reduzir o custo adicional envolvido no gerenciamento de um conjunto de encadeamentos maior que o necessário. Entretanto, isso diminuiria a capacidade do servidor responder a picos de carga nos quais um grande número de encadeamentos eram realmente necessários. Deve-se considerar cuidadosamente a determinação dos tamanhos de conjunto de encadeamento, inclusive o que a carga de trabalho média e de pico poderiam ser.

c. Tamanho do conjunto de conexões

Cada vez que um aplicativo tenta acessar um armazém backend (como um banco de dados), ele precisa de recursos para criar, manter e liberar uma conexão para aquele armazém de dados. Para reduzir o esforço que esse processo pode causar nos recursos do aplicativo em geral, o servidor de aplicativos permite estabelecer um conjunto de conexões de backend que os aplicativos podem compartilhar em um servidor de aplicativo. O agrupamento de conexões difunde o gasto adicional de conexão através de diversas solicitações de usuário, conservando assim os recursos do aplicativo para futuras solicitações. As opções ajustáveis importantes associadas com conjuntos de conexões são demonstradas na Tabela 4.

Tabela 4. Opções de ajuste do conjunto de conexões
ConfiguraçãoDescrição
Conexões mínimasNúmero mínimo de conexões físicas a manter. Se o tamanho do conjunto de conexões estiver no seu tamanho ou abaixo do tamanho mínimo, uma linha de tempo limite não utilizada não descartará as conexões físicas. Entretanto, o conjunto não cria as conexões somente para assegurar que o tamanho mínimo do conjunto de conexões seja mantido.
Conexões máximasNúmero máximo de conexões físicas que podem ser criadas nesse conjunto. Essas são conexões físicas com o armazém de dados de backend. Quando esse número é atingido, nenhuma nova conexão física é criada. Os solicitantes devem esperar até que uma conexão física atualmente em uso seja retornada ao conjunto ou até que uma ConnectionWaitTimeoutException seja lançada, com base na configuração de tempo limite da conexão. Configurar um valor alto máximo de conexões pode resultar em carga de pedidos de conexão que exceda o recurso de backend.
Tempo limite de inatividade encadeamentoEspecifica a quantidade de inatividade (em milissegundos) que deve decorrer antes que um encadeamento seja recuperado. Um valor de 0 indica não esperar e um valor negativo (menos de 0) significa esperar para sempre.

O objetivo de ajustar o conjunto de conexão é assegurar que cada encadeamento que precisa de uma conexão com o banco de dados tenha uma, e que as solicitações não sejam enfileiradas esperando para acessar o banco de dados. Para o aplicativo DayTrader, cada tarefa realiza uma consulta no banco de dados. Como cada encadeamento realiza uma tarefa, cada encadeamento simultâneo precisa de uma conexão com o banco de dados. Normalmente, todas as solicitações vêm por HTTP e são executadas em um encadeamento de contêiner de Web. Portanto, o tamanho máximo do conjunto deve ser pelo menos do tamanho máximo do conjunto de encadeamentos do contêiner de Web. Entretanto, há alguns casos em que as solicitações chegam no conjunto de encadeamentos padrão, como no modo assíncrono via bean acionado por mensagens.

No todo, a boa prática geral é determinar quais conjuntos de encadeamentos servem às tarefas que precisam de conexão com a origem de dados e dimensionar adequadamente os conjuntos. Nesse caso, o tamanho máximo do conjunto de conexão foi definido para a soma do tamanho máximo dos conjuntos de encadeamentos padrão e do contêiner da Web (70). As configurações do conjunto de conexões podem ser alteradas no console administrativo navegando para Resources => JDBC => Data Sources => data_source => Connection pool properties. Lembre-se de que nem todos os aplicativos podem se comportar tão bem quanto o DayTrader a partir do ponto de vista de gerenciamento de conexões, portanto podem usar mais de uma conexão por encadeamento.

A Figura 8 mostra os dados PMI para o conjunto de conexões enquanto o aplicativo DayTrader estava sendo executado em carga constante de pico com tamanhos de conjunto de conexões padrão de 1 no mínimo / 10 no máximo. FreePoolSize (laranja) é o número de conexões livres no conjunto e UseTime (verde) é o tempo médio (em ms) que uma conexão é utilizada. Este gráfico mostra que todas as 10 conexões estavam sempre em uso. Além da métrica exibida, a tabela também mostra outras métricas importantes: WaitingThreadCount mostra 33 encadeamentos esperando uma conexão com o banco de dados com um WaitTime médio de 8,25 ms e o conjunto é geralmente 100% ocupado, como demonstrado pela métrica PercentUsed.

Figura 8. Métrica PMI antes de ajustar o conjunto de conexões
Figure 8. PMI metrics before tuning the connection pool

A Figura 9 mostra o mesmo gráfico após o ajuste do conjunto de conexões de 10 mínimo/70 máximo. Ele mostra que houve muitas conexões livres disponíveis e nenhum encadeamento ficou esperando uma conexão, o que produz tempos de resposta muito mais rápidos.

Figura 9. Métrica PMI depois de ajustar o conjunto de conexões
Figure 9. PMI metrics after tuning the connection pool
Figura 10. Benefício de desempenho de tamanhos de conjunto de conexões ajustados
Figure 10. Performance benefit of tuned connection pool sizes

Para obter mais informações, consulte:

d. Tamanho de cache de instrução de origem de dados

O tamanho de cache de instrução de origem de dados especifica o número de instruções JDBC preparadas que pode ser armazenado em cache por conexão. A origem de dados do WebSphere Application Server otimiza o processamento de instruções preparadas e instruções que podem ser chamadas armazenando em cache as instruções que não estão sendo utilizadas em uma conexão ativa. Se o seu aplicativo utiliza muitas instruções como o DayTrader, aumentar esse parâmetro pode melhorar o desempenho do aplicativo. O tamanho do cache de instrução pode ser configurado navegando para Resources => JDBC => Data sources => data_source => WebSphere Application Server data source properties.

O tamanho do cache de instrução de origem de dados pode ser ajustado por meio de alguns métodos diferentes. Uma técnica é rever o código do aplicativo (ou um traço SQL coletado de um banco de dados ou driver de banco de dados) para todas as instruções exclusivas preparadas e assegurar que o tamanho do cache seja maior que esse valor. A outra opção é aumentar de forma iterativa o tamanho do cache e executar o aplicativo sob carga constante de pico até que a métrica PMI não relate mais descartes de cache. A Figura 11 mostra o mesmo gráfico PMI do conjunto de conexões, desta vez com o tamanho de cache de instrução de origem de dados aumentado para 60 com relação ao tamanho padrão (que é 10). A métrica PrepStmtCacheDiscardCount (vermelho) é o número de instruções descartadas porque o cache está cheio. Olhando de volta no quadro na Figura 9, antes de ajustar o tamanho do cache de instrução de origem de dados, o número de instruções descartadas era mais de 1,7 milhões. O gráfico na Figura 11 mostra que não houve descarte de instrução depois de ajustar o tamanho do cache.

Figura 11. Métrica PMI depois de ajustar o tamanho do cache de instrução de origem de dados
Figure 11. PMI metrics after tuning the data source statement cache size
Figura 12. Benefício de desempenho com tamanho de cache de instrução de dados aumentado
Figure 12. Performance benefit of increased data source statement cache size

Para obter mais informações, consulte:

e. Passagem por referência do ORB

A opção de passagem por referência do Object Request Broker (ORB) determina se a semântica passagem por referência ou passagem por valor deve ser usada ao tratar objetos de parâmetro envolvidos em uma solicitação EJB. Esta opção pode ser encontrada no console administrativo navegando para Servers => Application Servers => server_name => Object Request Broker (ORB). Por padrão, esta opção é desabilitada e uma cópia de cada objeto de parâmetro é feita e passada ao método EJB invocado. Isso é consideravelmente mais caro do que passar uma simples referência ao objeto de parâmetro existente.

Para resumir, a opção de passagem por referência do ORB basicamente trata o método EJB invocado como uma chamada local (mesmo para EJBs com interfaces remotas) e evita a cópia do objeto necessário. Se interfaces remotas não forem absolutamente necessárias, uma alternativa um pouco mais simples que não requer ajuste é utilizar EJBs com interfaces locais. Entretanto, ao utilizar interfaces locais e não remotas, são perdidos os benefícios comumente associados com interfaces remotas, transparência local em ambientes distribuídos e recursos de gerenciamento de carga de trabalho.

A opção de passagem por referência do ORB fornecerá apenas um benefício quando o cliente EJB (ou seja, servlet) e o módulo EJB invocado estiverem localizados no mesmo carregador de classe. Essa necessidade significa que tanto o cliente EJB quanto o módulo EJB devem ser implementados no mesmo arquivo EAR e executados na mesma instância de servidor de aplicativos. Se o cliente EJB e os módulos EJB forem mapeados para diferentes instâncias de servidor de aplicativos (frequentemente referidos como camada dividida), os módulos EJB devem ser invocados remotamente utilizando a semântica de passagem por valor.

Como o aplicativo DayTrader contém módulos WEB e EJB no mesmo EAR, e ambos são implementados à mesma instância do servidor de aplicativos, a opção de passagem por referência do ORB pode ser utilizada para realizar um ganho de desempenho. Como indicado pelas mensurações demonstradas na Figura 13, esta opção é extremamente benéfica para o DayTrader, onde todas as solicitações dos servlets são passadas aos beans de sessão stateless por uma interface remota, exceto no modo direto, onde o contêiner EJB é ignorado em função do JDBC direto e transações manuais.

Figura 13. Benefício de desempenho da passagem por referência do ORB
Figure 13. Performance benefit of ORB pass by reference

Para obter mais informações, consulte:


Ajuste avançado

Discutido nesta seção:

  1. Armazenamento de servlet em cache
  2. Conexões persistentes de transporte HTTP
  3. Suporte a páginas grandes
  4. Desativando serviços não utilizados
  5. Localização de servidor da Web

a. Armazenamento de servlet em cache

O DynaCache do WebSphere Application Server oferece um serviço de armazenamento geral em cache na memória para objetos e fragmentos de páginas gerados pelo servidor. As interfaces DistributedMap e DistributedObjectCache podem ser utilizadas em um aplicativo para armazenar em cache e compartilhar objetos Java armazenando referências a esses objetos no cache para uso posterior. O armazenamento de servlet em cache, por outro lado, permite que fragmentos de resposta JSP e servlets sejam armazenados e gerenciados por um conjunto customizável de regras de armazenamento em cache.

No aplicativo DayTrader, um Resumo de Mercado é exibido em cada acesso a uma página inicial de usuário. Esse resumo contém uma lista das principais cinco ações em alta e em queda, bem como o índice da bolsa atual e volume de comercialização. Essa atividade requer a execução de várias consultas ao banco de dados e, portanto, atrasa muito o carregamento da página inicial do usuário. Com o armazenamento de servlet em cache, o marketSummary.jsp pode ser armazenado em cache, praticamente eliminando essas dispendiosas consultas ao banco de dados para melhorar o tempo de resposta para a página inicial do usuário. O intervalo de atualização para o objeto armazenado em cache pode ser configurado e é ajustado para 60 segundos no exemplo mostrado na Listagem 1. O Dynacache pode também ser utilizado para armazenar outro servlet/fragmentos JSP em cache e dados no DayTrader. Esse exemplo demonstra a melhora possível com o armazenamento em cache para evitar operações complexas do servidor.

O armazenamento de servlet em cache pode ser ativado no console administrativo navegando para Servers => Application servers => server_name => Web container settings => Web container. O caminho URI para o servlet ou JSP a ser armazenado em cache deve ser definido em um arquivo cachespec.xml, que é localizado dentro do diretório WEB-INF do módulo da Web. Para o marketSummary.jsp no DayTrader, o cachespec.xml é parecido com a Listagem 1.

Listagem 1. cachespec.xml
Listing 1. cachespec.xml
Figura 14. Benefício de desempenho do armazenamento de servlet em cache
Figure 14. Performance benefit of servlet caching

Para obter mais informações, consulte:

b. Conexões persistentes de transporte HTTP

Conexões persistentes especificam que uma respostas HTTP de saída deve utilizar uma conexão persistente (keep-alive) ao invés de uma conexão que fecha depois da mudança de uma solicitação ou de resposta. Em muitos casos, pode-se conseguir uma melhora do desempenho aumentando o número máximo de solicitações persistentes permitidas em uma única conexão HTTP. As conexões SSL podem ver um ganho significativo de desempenho ativando solicitações persistentes ilimitadas por conexão, pois as conexões SSL enfrentam o gasto adicional de trocar chaves e negociar protocolos para terminar o processo de handshake SSL. Maximizar o número de solicitações que podem ser tratadas por conexão diminui o impacto desse gasto adicional. Também, aplicativos de alto rendimento com tempos de resposta rápidos podem realizar um ganho de desempenho mantendo as conexões abertas, ao invés de construir e fechar uma conexão a cada solicitação. Quando essa propriedade é definida para 0 (zero) a conexão permanece aberta enquanto o servidor de aplicativos estiver em execução. Entretanto, se a segurança for uma preocupação, então, deve-se considerar cuidadosamente essa configuração, pois esse parâmetro pode evitar negação de ataques de serviço quando um cliente tenta manter uma conexão keep-alive.

As configurações de conexões persistentes de transporte HTTP podem ser definidas no console administrativo navegando para Servers => Application servers => server_name => Ports. Lá, clique em View associated transports para a porta associada com as configurações do canal de transporte HTTP que você deseja alterar.

Durante o teste do DayTrader, o valor Máximo de solicitações persistentes por conexão foi alterado de 100 (padrão) para ilimitado. Os gráficos na Figura 15 mostram os resultados de rendimento de acesso de um simples servlet "Hello World" por HTTP padrão (não SSL) e HTTPS (SSL), antes e depois de ativar solicitações persistentes ilimitadas por conexão.

Figura 15. Benefício de desempenho de solicitações persistentes ilimitadas por conexão
Figure 15. Performance benefit of unlimited persistent requests per connection

Para obter mais informações, consulte:

c. Suporte a páginas grandes

Diversas plataformas oferecem a capacidade de estabelecer uma grande seção contínua de memória utilizando páginas de memória maiores que o tamanho padrão de página de memória. Dependendo da plataforma, tamanhos de páginas de memória grandes podem alcançar de 4 MB (Windows) a 16 MB (AIX), contra tamanhos padrão de página de 4 KB. Muitos aplicativos (inclusive aplicativos baseados em Java) frequentemente se beneficiam de páginas grandes devido a uma redução no custo adicional de CPU associado ao gerenciamento de números menores de páginas grandes.

Para usar páginas grandes de memória, é necessário primeiro defini-las e ativá-las no sistema operacional. Cada plataforma tem requisitos diferentes de sistema que devem ser configurados antes que o suporte a páginas grandes seja ativado. O Centro de Informações do WebSphere Application Server documenta cada uma dessas etapas por plataforma:

Uma vez configurado no sistema operacional, o suporte a páginas grandes no JVM pode ser ativado especificando -Xlp nas configurações de Generic JVM Arguments no console administrativo em Servers => Application servers => server_name => Process definition => Java Virtual Machine. Esteja ciente de que se grandes páginas forem ativadas, o sistema operacional separará uma grande porção de memória contínua para uso pelo JVM. Se a quantidade de memória restante não for suficiente para lidar com outros aplicativos em execução, pode ocorrer paginação (troca das páginas na memória pelas páginas no disco rígido), o que reduziria significativamente o desempenho do sistema.

Figura 16. Benefício de desempenho de páginas grandes
Figure 16. Performance benefit of large pages

Para obter mais informações, consulte:

d. Desativando serviços não utilizados

Desativar serviços não utilizados que um aplicativo não precisa mais pode aumentar o desempenho. Um exemplo é PMI. É importante observar que PMI deve ser ativada para visualizar as métricas documentadas anteriormente neste artigo e para receber orientação dos orientadores de desempenho. Embora desativar a PMI remova a capacidade de visualizar essas informações, também oferece um pequeno ganho de desempenho. A PMI pode ser desativada em servidor de aplicativos individual no console administrativo navegando para Monitoring and Tuning => Performance Monitoring Infrastructure (PMI).

Figura 17. Benefício de desempenho ao desativar a PMI
Figure 17. Performance benefit of disabling PMI

Para obter mais informações, consulte:

e. Localização do servidor da Web

Servidores da Web como o IBM HTTP Server frequentemente são usados frente a implementações do WebSphere Application Server para lidar com conteúdo estático ou para oferecer recursos de workload management (WLM). Em versões do WebSphere Application Server anteriores à V6, os servidores de Web também eram necessários para lidar eficientemente com milhares de conexões recebidas de clientes, devido ao mapeamento de um-para-um entre conexões do cliente e encadeamentos de contêiner da Web (discutido anteriormente). No WebSphere Application Server V6 e posteriores, isso não é mais necessário com a introdução de NIO e AIO. Para ambientes utilizando servidores de Web, as instâncias do servidor de Web devem ser colocadas em sistemas dedicados separados das instâncias do WebSphere Application Server. Se um servidor de Web é colocado em um sistema com uma instância do WebSphere Application Server, compartilharão eficientemente recursos valiosos de processador, reduzindo o rendimento geral para a configuração.

Um teste no DayTrader foi realizado com o IBM HTTP Server colocado localmente na mesma máquina que o WebSphere Application Server, e um segundo teste foi realizado com o servidor de Web localizado remotamente em uma máquina separada dedicada. A Tabela 5 mostra o percentual de ciclos de CPU consumidos por cada processo quando o servidor de Web e o servidor de aplicativos foram colocados no mesmo sistema. Como se pode ver nos resultados, aproximadamente 25% da CPU foi consumida pelo processo do Servidor HTTP que corresponde a uma única CPU no sistema de quatro CPUs usado no teste.

Tabela 5. Utilização de CPU com Servidor HTTP
Processo% da CPU
WebSphere Application Server66,3
IBM HTTP Server26,2

A Figura 18 mostra a comparação entre o rendimento e o tempo de resposta desses dois cenários, bem como o caso em que não havia servidor de Web.

Figura 18. Rendimento com e sem servidor da Web
Figure 18. Throughput with and without a Web server

Ajuste de sistema de mensagens assíncrono

A maior parte deste artigo esteve voltada até agora aos principais aspectos de serviço de Web e persistência do aplicativo DayTrader e WebSphere Application Server. Agora mudaremos o foco para como o DayTrader utiliza componentes JMS para realizar processamento assíncrono de pedidos de compra/venda e para monitorar mudanças de preços de ações. O aplicativo de referência do DayTrader contém dois recursos de sistema de mensagens que podem ser ativados ou desativados independentemente:

  • Processamento assíncrono de pedidos: O processamento assíncrono compra e venda é realizado por uma fila JMS e um MDB.
  • Monitoramento da consistência do preço das ações: Um tópico JMS e um MDB são utilizados para monitorar mudanças no preço das ações associadas com pedidos de compra e venda de ações.

Há duas opções de ajuste primárias associadas com a configuração do sistema de mensagens que terão um impacto significativo no desempenho: o tipo de armazenamento de mensagens e a confiabilidade da mensagem. Com essas, uma técnica mais avançada de ajuste que renderá ganhos adicionais de desempenho é colocar logs de transações e armazenamento de arquivo (se aplicável) em um disco rápido. Cada um desses tópicos e seus ganhos de desempenho correspondentes são discutidos em detalhe abaixo.

Discutido nesta seção:

  1. Tipo de armazenamento de mensagem
  2. Níveis de confiabilidade da mensagem
  3. Movendo o log de transações e armazenamento de arquivo para um disco rápido

a. Tipo de armazenamento de mensagem

O provedor interno do sistema de mensagens do WebSphere Application Server mantém o conceito de "armazenamento de dados" do mecanismo do sistema de mensagens. O armazém de dados serve como repositório persistente para mensagens tratadas pelo mecanismo. Quando um mecanismo de sistema de mensagens é criado em um ambiente de servidor único, um armazenamento baseado em arquivo é criado para uso como armazém de dados padrão. No WebSphere Application Server V6.0.x, o armazém padrão de dados foi fornecido por um banco de dados Derby local em processo. O arquivo e os armazéns de dados baseados em Derby são convenientes para cenários de servidor único, mas não fornecem o mais alto nível de desempenho, escalabilidade, gerenciamento ou alta disponibilidade. Para atender esses requisitos, é possível utilizar um armazém de dados em banco de dados remoto:

  • Armazém de dados de banco de dados local Derby: Com esta opção, um banco de dados local Derby em processo é utilizado para armazenar as informações e mensagens operacionais associadas com o mecanismo de sistema de mensagens. Embora conveniente para fins de desenvolvimento, esta configuração utiliza ciclos e memória valiosos no servidor de aplicativos para gerenciar as mensagens armazenadas.
  • Armazém de dados baseado em arquivo: (padrão) Se o mecanismo de sistema de mensagem for configurado para utilizar um armazém de dados baseado em arquivo, as informações operacionais e mensagens são mantidas no sistema de arquivo ao invés de no banco de dados. Isso permite desempenho mais rápido do que com o banco de dados Derby, quando um disco rápido como um redundant array of independent disks (RAID) é utilizado, pode ter desempenho tão rápido quanto um banco de dados remoto. Os resultados do teste mostrados abaixo não utilizam dispositivo RAID para o armazém de dados baseado em arquivo e não refletem essa melhora adicional.
  • Armazém de dados em banco de dados remoto: Nesta configuração, um banco de dados em um sistema remoto é configurado para atuar como armazém de dados do mecanismo do sistema de mensagens. Isso libera ciclos para o processo JVM do servidor de aplicativos usado anteriormente para gerenciar o banco de dados Derby ou armazéns baseados em arquivo, permitindo que servidor de banco de dados com nível de produção de melhor desempenho (como o IBM DB2® Enterprise Server) seja usado. Uma vantagem técnica de usar um banco de dados para o armazenamento de dados é que alguns aplicativos J2EE™ podem compartilhar conexões JDBC para beneficiarem-se da otimização one-phase. Para obter mais informações, veja as informações sobre compartilhamento de conexões para beneficiar-se da otimização one-phase commit. O armazém de arquivos não suporta essa otimização.

O DayTrader foi executado em modo EJB assíncrono com esses três tipos diferentes de armazenamento de mensagem. Durante essas execuções, a especificação de rastreio org.apache.geronimo.samples.daytrader.util.Log=all foi ativada para capturar o tempo para receber mensagens para o TradeBrokerMDB. Ao medir o desempenho do sistema de mensagens assíncrono, é sempre importante basear as medidas nos tempos de resposta MDB que são assíncronos, e não nos tempos de resposta de página real, que são síncronos. Os resultados na Figura 19 mostram que um armazém de dados em banco de dados remoto rende o melhor desempenho, pois oferece o tempo de resposta mais rápido MDB e o rendimento mais elevado.

Figura 19. Comparação do desempenho de tipos de armazenamento de mensagem
Figure 19. Performance comparison of message store types

Para obter mais informações, consulte:

b. Níveis de confiabilidade da mensagem

A confiabilidade da mensagem é um componente importante para qualquer sistema de mensagens e o provedor de mensagens do WebSphere Application Server oferece cinco níveis diferentes de confiabilidade:

  • Melhor esforço não persistente
  • Expresso não persistente
  • Confiável não persistente
  • Confiável persistente
  • Assegurado persistente.

Mensagens persistentes são sempre armazenadas em alguma forma de armazém de dados persistente, enquanto mensagens não persistentes são geralmente armazenadas em memória volátil. Há uma desvantagem entre a confiabilidade da entrega da mensagem e a velocidade com que as mensagens são entregues. A Figura 20 mostra os resultados para dois testes utilizando um armazém de arquivo com diferentes níveis de confiabilidade: assegurado persistente e expresso não persistente. Os resultados ilustram claramente que conforme o nível de confiabilidade diminui, as mensagens podem ser processadas mais rapidamente.

Figura 20. Comparação do desempenho de níveis de confiabilidade de mensagem
Figure 20. Performance comparison of message reliability levels

Para obter mais informações, consulte:

c. Movendo o log de transações e armazenamento de arquivos para um disco rápido

Como as operações de E/S de disco são dispendiosas, armazenar arquivos de log em discos rápidos como um RAID pode aumentar muito o desempenho. Na maioria das configurações RAID, a tarefa de escrever dados para a mídia física é compartilhada através das várias unidades. Esta técnica rende mais acesso simultâneo para armazenamento para informações de transações persistentes e acesso mais rápido aos dados dos logs.

O diretório de log de transações pode ser configurado no console administrativo navegando para Servers => Application Servers => server_name => Container Services => Transaction Service.

O diretório de log de armazém de arquivo pode ser especificado durante a criação de um membro SIBus utilizando a opção -logDirectory no comando AdminTask addSIBusMember ou através dos painéis de criação do SIBus Member no console de administração.

A Figura 21 mostra os resultados para os dois testes: um com os logs de transação e armazenamento de arquivos armazenados localmente no disco rígido e outro com eles armazenados em um RAMDisk (que trata essencialmente uma seção de memória como um disco rígido para leituras e gravações mais rápidas). Para esses testes, foi utilizado um nível de confiabilidade expresso não persistente. Os resultados mostram que os tempos de resposta e rendimento são levemente mais rápidos quando os logs são armazenados em um disco rápido.

Figura 21. Benefício de desempenho usando um disco rápido
Figure 21. Performance benefit of using a fast disk

Para obter mais informações, consulte:


Resumo

O IBM WebSphere Application Server foi projetado para hospedar uma gama sempre crescente de aplicativos, cada um com seu próprio conjunto exclusivo de recursos, requisitos e serviços. Essa flexibilidade afirma a realidade de que dois aplicativos não utilizarão um servidor de aplicativo no mesmo lugar exatamente, e que nenhum conjunto de parâmetros de ajuste provavelmente fornecerá melhor desempenho para qualquer um dos dois aplicativos diferentes.

Embora o DayTrader possa não parecer com seu aplicativo, a metodologia para descobrir o que ajustar e como realizar o ajuste é a mesma. A chave é identificar e focar nos principais componentes e recursos do servidor utilizados pelo seu aplicativo, com base na arquitetura do aplicativo. Em geral, um grande número de aplicativos terá alguma melhora com o ajuste nas três áreas principais: JVM, conjuntos de encadeamentos e conjuntos de conexões. Outros elementos ajustáveis podem render a mesma eficiência; entretanto, normalmente estarão ligados a um recurso específico do WebSphere Application Server usado pelo aplicativo.

Este artigo discutiu esse conjunto principal de itens ajustáveis, mais outras opções que beneficiam o aplicativo DayTrader. Para cada uma das opções, foram oferecidas informações sobre onde encontrar o item ajustável, recomendações gerais ou precauções sobre quaisquer desvantagens e indicadores para ferramentas relacionadas, se aplicável. A Figura 22 mostra a melhora geral de desempenho para cada modo de tempo de execução do DayTrader depois da aplicação das seguintes opções de ajuste:

  • tamanho de heap JVM
  • Tamanho de conjunto de encadeamentos
  • Tamanho de conjunto de conexões
  • Tamanho de cache de instrução de origem de dados
  • Passagem por referência do ORB
  • Armazenamento de servlet em cache
  • Conexões persistentes HTTP ilimitadas
  • Suporte a páginas grandes
  • Desativação de PMI.
Figura 22. Melhoras gerais de desempenho depois do ajuste das opções aplicadas
Figure 22. Overall performance improvements after tuning options applied

Como é possível ver claramente na figura, o ajuste descrito rendeu 169% de melhoria para o modo EJB, 207% para o modo Sessão Direta, e 171% para o modo Direto. Essas são melhorias realmente consideráveis e melhorias semelhantes podem ser realizadas em outros aplicativos; entretanto, é necessário lembrar que os resultados variam com base nos fatores discutidos anteriormente e em outros fatores que estão além do escopo deste artigo.

Esperamos que as informações e ferramentas discutidas aqui tenham fornecido alguns importantes insights para ajudar a tornar a tarefa de ajustar seu servidor de aplicativos para seus aplicativos específicos menos hercúlea e até menos assustadora.

Recursos

Aprender

Obter produtos e tecnologias

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=WebSphere
ArticleID=445668
ArticleTitle=Estudo de caso: Ajustando o WebSphere Application Server V7 para desempenho
publish-date=11092009