O tamanho do seu cache do Enterprise JavaBeans (EJB) pode afetar o desempenho do servidor de aplicativos. Uma das etapas no ajuste de seu contêiner EJB
para níveis de desempenho ideais é fazer o ajuste fino do cache EJB.
Antes de Iniciar
Nota: Esse tópico faz referência a um ou mais arquivos de log do servidor de aplicativos. Como uma recomendação alternativa, é possível configurar o servidor para usar a infraestrutura de log e rastreio do High Performance Extensible Logging (HPEL)
em vez de usar os arquivos SystemOut.log , SystemErr.log, trace.log e activity.log em sistemas distribuídos e IBM® i. Também é possível usar HPEL em conjunção com os recursos de criação de log z/OS nativos. Se você estiver usando HPEL, será possível acessar todas as informações de log e rastreio usando a ferramenta de linha de comandos LogViewer a partir do diretório bin do perfil do servidor. Consulte as informações sobre a utilização do HPEL para resolução de problemas dos aplicativos
para obter mais informações sobre o uso do HPEL.
Sobre Esta Tarefa
O procedimento a seguir descreve como usar o serviço de rastreio de diagnóstico para ajudá-lo a determinar o melhor tamanho do cache.
Procedimento
- Ative o rastreio do cache de EJB. Para aprender a trabalhar com o serviço de rastreio, consulte o tópico Trabalhando com Rastreio.
![[IBM i]](../images/iseries.gif)
Para obter informações
sobre as configurações de serviço de rastreio, consulte o tópico Configurações de Serviço de Rastreio de
Diagnóstico.
Configure o rastreio
para usar esta cadeia de rastreio:
com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy=all=enabled:com.ibm.ejs.util.cache.CacheElementEnumerator=
all=enabled
![[IBM i]](../images/iseries.gif)
Configure Tamanho Máximo de Arquivo como 200MB ou
mais. Se deixar esse valor-padrão de 20 MB, o
único log de rastreio de 20 MB poderá ser preenchido e alguns dados poderão ser perdidos devido ao agrupamento de rastreio.
![[IBM i]](../images/iseries.gif)
Configure o Número
Máximo de Arquivos de Histórico como 5. Cinco arquivos devem ser suficientes,
mas se você vir que todos os cinco arquivos estão cheios e que ocorre agrupamento do rastreio, aumente
esse valor.
![[IBM i]](../images/iseries.gif)
Pare o servidor, exclua os logs existentes e, em seguida,
inicie o servidor.
Pare e reinicie o servidor.
- Execute cenários típicos para capturar dados de rastreio do cache. Ao executar um cenário típico com o rastreio ativado, os dados de rastreio de
cache EJB serão recebidos para serem analisados nas seguintes etapas.
- Visualize e analise a saída de rastreio.
- Abra o log de rastreio. Procure por uma ou pelas duas seguintes sequências de rastreio a
serem exibidas:
![[IBM i]](../images/iseries.gif)
Cache de EJB BackgroundLru 3: Tempo de acesso (1,40) - Limite de cache não atingido : 489/2053
BackgroundLru > EJB Cache: Sweep (16,40) - Cache limit exceeded : 3997/2053 Entry
Trace: 2007/03/22 11:47:07.048 01 t=7A9690 c=UNK key=P8 (13007002)
ThreadId: 0000006a
FunctionName: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
SourceId: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
Categoria: FINEST
ExtendedMessage: Cache de EJB: Tempo de acesso (23,40) - Limite de cache não atingido : 0/2053
Rastreio: 2007/03/22 11:54:16.755 01 t=7BD3B0 c=UNK key=P8 (13007002)
ThreadId: 0000006d
FunctionName: EJB Cache: Tempo de acesso (75,37) - Limite de cache excedido : 3801/2053
SourceId: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
Categoria: FINER
ExtendedMessage: Entrada
Nas cadeias de rastreio que incluem as
palavras Limite de cache, você encontrará uma proporção. Por exemplo, 3997/2053.
O primeiro
número é o número de enterprise beans atualmente no cache de EJB (chamado
de capacidade). O segundo número é a configuração do cache de EJB (mais detalhes
sobre isto em etapas posteriores). Use essa proporção, especialmente a capacidade, na
sua análise.
Também procure pelas frases
Limite de cache não atingido e
Limite de
cache excedido.
- Limite de cache não atingido
- Seu cache é igual a ou maior que o apropriado. Se for maior,
estará perdendo memória e deverá reduzir o tamanho do cache para um
valor mais apropriado.
- Limite de cache excedido
- O número de beans que estão sendo utilizados atualmente é maior que a capacidade
especificada, indicando que seu cache não está ajustado corretamente.
A capacidade
pode exceder a configuração do Cache de EJB porque a configuração não é um limite
rígido. O Contêiner EJB não para de incluir beans no cache quando o limite é
atingido. Se isso fosse feito, quando o cache estivesse cheio um pedido de um
bean não seria atendido, ou pelo menos seria retardado até que o cache caísse
abaixo do limite. Em vez disso, o limite do cache pode ser excedido, mas
o Contêiner EJB tenta limpar o cache e mantê-lo abaixo do tamanho do Cache
de EJB.
Caso o limite do cache seja excedido, você poderá ver
um ponto de rastreio semelhante a este:
![[IBM i]](../images/iseries.gif)
BackgroundLru < Cache de EJB: Tempo de acesso (64,38) - Despejado = 50 : 3589/2053 Saída
Cache EJB: Sweep (64,38) - Despejado = 50 : 3589/2053
Observe
a cadeia
Despejado =. Se você vir essa cadeia, estará utilizando Beans de Sessão com Preservação de Estado ou Beans de Entidade configurados para o armazenamento de cache Opção A ou B. Objetos despejados significam que você não está aproveitando totalmente a opção de armazenamento em cache que escolheu. O primeiro passo é tentar aumentar o tamanho do Cache de EJB. Se a continuação de execução do seu aplicativo resultar em mais despejos, isso significa que o
aplicativo está acessando ou criando mais novos beans entre as trocas de
Cache EJB do que o cache pode suportar e
NÃO está reutilizando os
beans existentes.
Você pode querer considerar o uso do armazenamento em cache
da Opção C para seus beans de entidade ou verificar seu aplicativo para ver se ele não está
removendo Beans de Sessão Stateful depois que eles não forem mais necessários.
Nota: Os Beans de Entidade configurados com a Opção C
de armazenamento em cache estão no cache apenas enquanto estiverem em uma transação, e precisam
ser mantidos no cache por toda a transação.
Portanto, eles nunca
são despejados durante um tempo de acesso do cache, mas são removidos do cache quando
a transação é concluída. Além disso, se você estiver utilizando apenas Beans de Sessão sem Estado
ou Beans de Entidade com a Opção C de armazenamento em cache (ou ambos), poderá aumentar
o intervalo de limpeza do Cache de EJB para um número maior. O intervalo de limpeza pode ser configurado conforme descrito
nas configurações do cache EJB. Os Beans de Sessão Stateless NÃO estão no
Cache EJB e, como os Beans de Entidade que usam o armazenamento em cache da Opção C nunca são despejados pela
estratégia de armazenamento em cache (LRU), não há nenhuma necessidade real de tempo de acesso com frequência. Ao usar apenas Beans de Sessão Stateless ou o armazenamento em cache da Opção C, você deverá ver apenas "Evicted = 0" no exemplo de rastreio mostrado.
- Analise o log de rastreio. Procure a cadeia de rastreio Limite de
cache excedido.
- É possível encontrar mais de uma instância dessa cadeia. Examine todas elas
para localizar o valor da maior capacidade de beans no Cache de EJB.
Reconfigure seu tamanho
de Cache EJB para cerca de 110% desse número. A configuração do tamanho do Cache de EJB
é explicada em uma etapa posterior.
- É possível não encontrar nenhuma instância dessa cadeia. Isso significa que você não
excedeu a capacidade do Cache de EJB (o que é sua meta final), mas não vê-la durante
a análise inicial também poderia significar que seu cache é grande demais e está
utilizando memória desnecessária. Neste
caso, você ainda deverá sintonizar seu cache reduzindo o tamanho do cache até
seu limite de cache não ser excedido, em seguida, aumentando-o para o valor
ideal. A configuração do tamanho do Cache de EJB
é explicada em uma etapa posterior.
Sua meta final é configurar o limite do cache como um valor que não
desperdice recursos mas também não seja excedido. Uma boa configuração fornece
um rastreio com apenas a mensagem
Limite de cache não atingido,
e uma proporção em que o número da capacidade possa chegar próximo, mas abaixo de 100%
da configuração de Cache EJB.
Nota: É recomendado não configurar seu tamanho de cache
para algo menor que o padrão de 2053.
- Modifique as configurações de cache com base na análise. Consulte as configurações de cache EJB para obter informações sobre como fazer isso.
![[IBM i]](../images/iseries.gif)
Para o servidor, exclua todos os logs e
reinicie o servidor.
Pare e reinicie o servidor.
- Repita as etapas anteriores até que esteja satisfeito com suas configurações.
- Desative o rastreio do Cache de EJB. Com o cache ajustado corretamente,
é possível remover o rastreio, remover os logs antigos e reiniciar o servidor.
O que Fazer Depois
A partir de sua análise, é possível configurar o cache EJB
de forma ideal, de uma perspectiva de Contêiner EJB, mas talvez não de forma ideal
de uma perspectiva do WebSphere Application
Server. Um tamanho de cache maior resulta em mais acertos e
melhor desempenho do cache, mas utiliza mais memória. A memória utilizada pelo cache
não está disponível para outras áreas do produto, possivelmente causando impacto
sobre o desempenho geral. Em um sistema com memória ampla, isso pode não ser um problema
e um ajuste correto do cache de EJB pode melhorar o desempenho geral. No entanto, você deve levar em conta essa questão de desempenho do sistema versus desempenho do
cache de EJB ao configurar o cache.