Ajustando o Contêiner EJB

Se você usar aplicativos que afetem o tamanho do cache do contêiner Enterprise JavaBeans (EJB), é possível que o desempenho dos seus aplicativos possa ser afetado por uma configuração de tamanho incorreto. A Container Managed Persistence (CMP) é discutida nesse tópico, embora seja importante saber que os beans de entidade não são suportados em um módulo EJB 3.x.

Tamanho do Cache EJB

Monitore o Tivoli Performance Viewer para diagnosticar se a configuração do tamanho do cache do contêiner EJB está ajustada corretamente para seu aplicativo.

Se o aplicativo preencheu o cache fazendo com que ocorram despejos, o Tivoli Performance Viewer mostrará uma alta taxa de chamada do método ejbStores e, provavelmente, uma utilização de processador abaixo do esperado na máquina da estação de trabalho.

Todos os aplicativos que usam os enterprise beans devem ter essa configuração ajustada a partir do valor padrão, se o resultado da seguinte fórmula for igual ou maior que 2000:
EJB_Cache_Size = (Maior número dos beans de entidade da Opção B ou C listados em uma 
transação * número máximo de transações simultâneas) + 
(Maior número dos beans de entidade da Opção A exclusiva esperado para serem acessados durante 
uma carga de trabalho típica do aplicativo) + 
(Número de beans de sessão stateful ativos durante carga de trabalho típica) + 
(Número de tipos de bean de sessão stateless usados durante carga de trabalho típica)

Em que:
Os beans de entidade da Opção B e C são mantidos no cache EJB apenas durante o tempo de vida 
da transação na qual estão envolvidos. Portanto, o primeiro termo na fórmula 
computa os requisitos médios do cache EJB para estes tipos de beans.

Os beans de entidade da Opção A são mantidos no cache EJB indefinidamente e só serão removidos
 do cache se começar a haver mais beans no cache do que o tamanho 
do cache tiver sido definido para comportar. Se seu aplicativo usar Beans Somente Leitura, considere-os como sendo
beans da Opção A para este cálculo de ajuste. 

Os beans de sessão stateful são mantidos no cache EJB até que eles sejam removidos pelo 
aplicativo ou até que o valor do tempo limite da sessão seja atingido.

Apenas uma instância do bean de sessão stateless única para cada tipo EJB é mantido no 
cache durante o tempo em que quaisquer métodos estiverem em execução nesse
bean de sessão stateless. Se dois ou mais métodos estiverem sendo implementados simultaneamente no mesmo 
tipo de bean de sessão stateless, cada método será executado na própria instância do bean, mas 
apenas um local de cache será utilizado para todas estas instâncias. 

Esta fórmula calcula o limite superior e o número máximo de enterprise beans ativos em um tempo dentro do servidor de aplicativos. Como o cache do contêiner EJB é construído para conter todos estes beans para otimizações de desempenho, um melhor desempenho deve ser obtido ao configurar este tamanho do cache para maior que o número resultante da fórmula anterior.

É possível configurar o tamanho do cache EJB no console administrativo em Servidores > Tipos de Servidor > Servidores de aplicativos WebSphere > server_name > Configurações do Contêiner do EJB > Configurações do cache do EJB.

Além disso, ao ajustar o tamanho do cache EJB, é possível ajustar o parâmetro de encadeamento do gerenciamento de contêiner EJB para atender às necessidades do aplicativo. O encadeamento de gerenciamento é controlado por meio da configuração Intervalo de limpeza. Essa configuração controla com que freqüência um encadeamento de daemon no produto tenta remover instâncias de bean do cache que não foram utilizadas recentemente, tentando manter o número de instâncias de bean no tamanho do cache ou abaixo dele. Este comportamento assegura que o contêiner EJB coloque e consulte itens no cache rapidamente. Deixe este intervalo configurado como o padrão, entretanto, em alguns casos, pode ser mais válido verificar se reduzir este intervalo pode ser benéfico.

Para obter informações sobre o ajuste do cache EJB usando o serviço de rastreio de cache EJB, consulte o ajuste do cache EJB e o uso do serviço de rastreio.

Ajuste de Beans de Sessão EJB com Preservação de Estado

O tempo limite do bean de sessão stateful é configurado de maneiras diferentes, com escopos diferentes, dependendo da versão do WebSphere Application Server.

O WebSphere Application Server Versão 6.1 e anterior suporta a configuração de tempo limite de bean de sessão stateful, por bean, usando o arquivo ibm-ejb-jar-ext.xmi.

O WebSphere Application Server Versão 7.0 suporta a configuração de tempo limite do bean de sessão stateful, por bean, usando o arquivo ibm-ejb-jar-ext.xmi (para módulos EJB 2.x), e o arquivo ibm-ejb-jar-ext.xml (para módulos EJB 3.x).

O WebSphere Application Server Versão 8.x suporta a configuração de tempo limite de bean de sessão stateful, por bean, usando os arquivos ibm-ejb-jar-ext.xmi (para módulos EJB 2.x) e ibm-ejb-jar-ext.xml (para módulos EJB 3.x), e o elemento XML de tempo limite de stateful e a anotação @StatefulTimeout. Alem disso, é possível configurar um valor de tempo limite de sessão stateful (global) de todo o servidor usando a propriedade do sistema com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout.

Configurações suportadas Configurações suportadas: Para arquivos de extensão e de ligação IBM®, a extensão do nome do arquivo .xmi ou .xml é diferente dependendo de você estar utilizando um aplicativo pré-Java EE 5 ou um módulo ou um aplicativo ou módulo Java™ EE 5 ou posterior. Um arquivo de extensão ou de ligação IBM é denominado ibm-*-ext.xmi ou ibm-*-bnd.xmi em que * é o tipo de arquivo de extensão ou de ligação como app, aplicativo, ejb-jar ou web. As seguintes condições se aplicam:
  • Para um aplicativo ou módulo que usa um Java EE versão anterior à versão 5, a extensão do arquivo deverá ser .xmi.
  • Para um aplicativo ou módulo que usa Java EE 5 ou posterior, a extensão do arquivo deve ser .xml. Se os arquivos .xmi forem incluídos no aplicativo ou módulo, o produto ignorará os arquivos .xmi.

No entanto, um módulo Java EE 5 ou posterior pode existir dentro de um aplicativo que inclui arquivos pré-Java EE 5 e usa a extensão do nome do arquivo .xmi.

Os arquivos ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi, e ibm-portlet-ext.xmi continuam a usar as extensões de arquivo .xmi.

sptcfg

Beans de sessão sem estado não têm um valor de tempo limite porque não têm estado de conversação e não são dedicados a nenhum cliente específico.

É possível usar o Rational Application Developer para atualizar o arquivo ibm-ejb-jar-ext.xmi, que é usado para configurar o valor do tempo limite da sessão stateful para beans em um módulo EJB 2.x. Para obter informações adicionais, leia sobre a definição das configurações do tempo limite de sessão para um bean no Centro de Informações do Rational Application Developer.

Por exemplo, o código XMI gerado é configurado para um valor de tempo limite de sessão stateful de 15 minutos é:
<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension_1"
  timeout="15">

É possível modificar o arquivo ibm-ejb-jar-ext.xml para configurar o tempo limite da sessão stateful para beans em um módulo EJB 3.x. Por exemplo, o código para configurar um valor de tempo limite da sessão stateful de 15 minutos para o bean myBean é:

<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension"
  timeout="15">
    <enterpriseBean xmi:type="ejb:Session" href="META-INF/ejb-jar.xml#MyBean"/>
 </ejbExtensions>

É possível configurar o tempo limite do bean de sessão stateful usando a anotação @StatefulTimeout. A anotação @StatefulTimeout usa um parâmetro de valor necessário que representa a duração do tempo limite e um parâmetro de unidade opcional. Se o parâmetro de unidade opcional não for especificado, a unidade padrão será minutos. A anotação @StatefulTimeout é introduzida como parte do EJB 3.1.

Por exemplo, use a anotação @StatefulTimeout para declarar um valor de tempo limite de 100 segundos:

@StatefulTimeout(value=100 unit=java.util.concurrent.TimeUnit.SECONDS)

É possível configurar o tempo limite do bean de sessão stateful usando o elemento XML de tempo limite stateful no descritor de implementação ejb-jar.xml. O elemento stateful-timeout é introduzido como parte do EJB 3.1.

Por exemplo, para configurar um valor de tempo limite de 100 segundos:

<stateful-timeout>
     <timeout>100</timeout>
     <unit>Seconds</unit>
</stateful-timeout>

A anotação @StatefulTimeout e o elemento XML stateful-timeout são os mecanismos definidos pela especificação para declarar valores de tempo limite por bean, iniciando com o EJB 3.1. Antes do EJB 3.1, não há meio definido por especificação para declarar tempo limite da sessão statful por bean. Quando usar o elemento XML de tempo limite stateful ou a anotação @StatefulTimeout, um valor -1 significa que o bean nunca atinge o tempo limite e um valor 0 significa que o bean é imediatamente elegível para remoção.

É possível configurar o tempo limite do bean de sessão stateful basicamente de modo global (de todo o servidor) usando a propriedade do sistema com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout. A unidade de tempo para a propriedade do sistema com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout é em minutos. O valor especificado deve ser 0 ou maior e, se um valor inválido for especificado, o valor padrão de 10 minutos será usado no lugar. O valor do tempo limite global não pode ser configurado usando o XML ou as anotações. O valor do tempo limite global aplica-se a todos os beans de sessão stateful em execução no servidor, incluindo os beans de sessão stateful nos módulos EJB 2.x ou EJB 3.x.

Em WebSphere Application Server Versão 8.x, as configurações de tempo limite de stateful têm precedência sobre a configuração de tempo limite de todo o servidor. A configuração do tempo limite de todo o servidor tem prioridade sobre o tempo limite padrão (não especificado). O pedido de precedência a seguir é usado para determinar o valor de tempo limite da sessão de stateful para um bean em execução em WebSphere Application Server Versão 8.x:
  1. Elemento XML stateful-timeout
  2. Anotação @StatefulTimeout
  3. ibm-ejb-jar-ext.xml ou ibm-ejb-jar-ext.xmi
  4. Propriedade do sistema com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout
  5. Se nenhum valor de tempo limite no nível do bean ou de todo o servidor for especificado explicitamente, o valor de tempo limite padrão de 10 minutos será aplicado.

Dcom.ibm.websphere.ejbcontainer.poolSize

O Tivoli Performance Viewer indicará se o aplicativo está usando a maioria das instâncias de bean no conjunto. Quando a maioria das instâncias de bean for usada, aumente o tamanho dos conjuntos de bean que estiverem se esgotando ao incluir este parâmetro na tag de propriedades customizadas da JVM, por exemplo:

-Dcom.ibm.websphere.ejbcontainer.poolSize=<application_name>#<module_name>#
<enterprisebean_name>=<minSize>,<maxSize>

Em que:

O elemento <application_name> é o nome do aplicativo Java EE, conforme definido no descritor de implementação do arquivo archive corporativo (EAR), para o bean cujo tamanho do conjunto está sendo configurado.

O elemento <module_name> é o nome do arquivo Java archive (JAR) do módulo EJB, para o bean cujo tamanho do conjunto está sendo configurado.

O elemento <bean_name> é o nome do enterprise bean Java EE, conforme definido no descritor de implementação do módulo EJB, para o bean cujo tamanho do conjunto está sendo configurado.

O elemento <minSize> é o número de instâncias de bean que o contêiner mantém no conjunto, independente de quanto tempo os beans estiveram no conjunto (beans maiores que esse número são descartados do conjunto ao longo do tempo para otimizar o uso de memória).

O elemento <maxSize> é o número de instâncias de bean no conjunto em que nenhuma outra instância de bean é posicionada no conjunto uma vez que ela for usada (isto é, quando o conjunto estiver neste tamanho, qualquer bean adicional é descartado ao invés de incluído no conjunto, o que garante que o número de beans no conjunto possua um limite de forma que o uso de memória não cresça de uma forma ilimitada).

Para manter o número de instâncias no conjunto em um tamanho fixo, os elementos minSize e maxSize podem ser configurados para o mesmo número. Um conjunto de instâncias separado para cada tipo de EJB em execução no servidor de aplicativos existe e cada conjunto inicia sem nenhuma instância; o número de instâncias cresce conforme os beans são usados e, em seguida, colocados no conjunto.

Quando uma instância de bean é necessária pelo contêiner e nenhum bean estiver disponível no conjunto, o contêiner cria e usa uma instância de bean e, em seguida, coloca esta instância no conjunto, a menos que já haja o maxSize de instâncias no conjunto. Por exemplo, a instrução
Dcom.ibm.websphere.ejbcontainer.poolSize=ivtApp#ivtEJB.jar#ivtEJBObject=125,1327  
configura minSize de 125 e um maxSize de 1327 no bean denominado ivtEJBObject no arquivo ivtEJB.jar, no aplicativo ivtApp.

O aplicativo, ivtApp, é substituído pelo nome do aplicativo real, o arquivo ivtEJB.jar é substituído pelo arquivo JAR que contém o bean que deve ter seu tamanho de conjunto aumentado e ivtEJBObject é o nome do bean do enterprise bean cujo tamanho do conjunto deve ser aumentado. O número mínimo de beans que são mantidos no conjunto é 125. O número máximo de beans que são mantidos no conjunto é 1327. Configure isso para que não ocorra mais nenhum despejo do conjunto. Na maioria dos casos, esses devem ser configurados de modo igual se houver muita memória porque não ocorre nenhum aumento ou diminuição do conjunto.

Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation

Você deve entender como seu aplicativo manipula a criação dos objetos de chave primária para uso pelos beans CMP e pelos beans de persistência gerenciada por bean (BMP) dentro do produto.

O contêiner EJB usa a chave primária de um bean de entidade como um identificador dentro das estruturas de dados internas para otimizar o desempenho. Entretanto, o contêiner EJB deve copiar estes objetos de chave primária no primeiro acesso ao bean para assegurar que os objetos armazenados nos caches internos sejam separados dos objetos usados em um aplicativo. Este processo ocorre para manter as estruturas internas consistentes, caso o aplicativo faça alguma mudança na chave primária. Se o aplicativo não mudar nenhuma das chaves primárias usadas para criar e acessar beans de entidade uma vez que forem criadas, um sinalizador especial pode ser usado para garantir que o contêiner EJB ignore a cópia do objeto de chave primária, salvando os ciclos do processo e aumentando o desempenho. Esse mecanismo pode ser ativado por sua conta e risco, incluindo a propriedade –D no campo de propriedade customizada da JVM.
-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true
Configurações suportadas Configurações suportadas: Os beans de entidade não são suportados em EJB 3.x e em módulos mais recentes.sptcfg

O benefício em desempenho dessa otimização depende do aplicativo. Se o aplicativo usar tipos primitivos para as chaves primárias de enterprise beans, não haverá nenhum ganho porque estes objetos já estão imutáveis e o mecanismo de cópia levará isso em consideração. Entretanto, se o aplicativo usar muitas chaves primárias complexas, ou seja, um objeto para uma chave primária ou vários campos, este parâmetro poderá gerar aprimoramentos significativos.

Dcom.ibm.ws.pm.deferredcreate

O gerenciador de persistência é utilizado pelo contêiner EJB para persistir dados no banco de dados dos beans de entidade CMP.

Ao criar beans de entidade chamando o método ejbCreate, por padrão, o gerenciador de persistência insere imediatamente a linha vazia com apenas a chave primária no banco de dados. Na maioria dos casos, uma vez criado o bean você deve modificar os campos no bean criado ou nos outros beans dentro da mesma transação. Caso deseje adiar a inserção no banco de dados até o fim da transação para eliminar uma ida ao banco de dados, configure o sinalizador –D dentro do campo de propriedades customizadas da JVM. Os dados são inseridos no banco de dados e a consistência é mantida.
Configurações suportadas Configurações suportadas: Os beans de entidade não são suportados em EJB 3.x e em módulos mais recentes.sptcfg
-Dcom.ibm.ws.pm.deferredcreate=true

O benefício em desempenho dessa otimização depende do aplicativo. Se as transações de aplicativos EJB forem inseridas de maneira intensiva, o aplicativo poderá se beneficiar dessa otimização. Se o aplicativo executar poucas inserções, o benefício dessa otimização será menor.

Dcom.ibm.ws.pm.batch

Quando um aplicativo EJB acessa vários beans CMP dentro de uma transação única, dependendo das operações executadas nos beans, como atualizações, inserções e leituras, o número de operações emitidas para o banco de dados corresponde às operações executadas nos beans do CMP. Se o sistema de banco de dados que você estiver utilizando suportar lotes de instruções de atualização, será possível ativar este sinalizador e aumentar o desempenho em todas as interações com o banco de dados que envolver mais de duas atualizações em uma única transação.

Configurações suportadas Configurações suportadas: Os beans de entidade não são suportados em EJB 3.x e em módulos mais recentes.sptcfg
Use este sinalizador, que suporta o gerenciador de persistência que inclui todas as instruções de atualização em uma instrução em lote única que é emitida para o banco de dados. Este processo economiza roundtrips para o banco de dados, o que aumenta o desempenho. Se você souber que o aplicativo exibe o comportamento de atualizar vários beans CMP em uma única transação, e se o banco de dados suportar atualizações em lote, é possível configurar o sinalizador –D dentro do campo de propriedades customizadas da JVM, por exemplo:
-Dcom.ibm.ws.pm.batch=true

O benefício em desempenho dessa otimização depende do aplicativo. Se o aplicativo nunca, ou raramente, atualizar os beans CMP ou atualizar apenas um bean único por transação, não haverá nenhum ganho de desempenho. Se o aplicativo atualizar vários beans por transação, este parâmetro beneficiará o desempenho de aplicativos.

A tabela a seguir lista os bancos de dados backend que suportam atualização em lotes.
Tabela 1. Bancos de dados backend que suportam atualização de lote.. A tabela a seguir lista os bancos de dados backend que suportam atualização em lotes.
Banco de Dados Suporta atualização em lotes Suporta atualização em lotes com Controle de Simultaneidade Otimista
DB2 yes no
Oracle yes no
Driver DB2 Universal yes yes
Informix sim yes
SQLServer sim yes
Apache Derby sim yes
Configurações suportadas Configurações suportadas: Atualização em lote com OCC não pode ser executado para bancos de dados que não o suportam, mesmo se especificados pela intenção de acesso.sptcfg

com.ibm.ws.pm.useLegacyCache

Especifica o nome da classe Java que o produto utiliza para implementar a interface javax.rmi.CORBA.UtilDelegate.

Configurações suportadas Configurações suportadas: Os beans de entidade não são suportados em EJB 3.x e em módulos mais recentes.sptcfg
O gerenciador de persistência tem dois tipos de mecanismos de armazenamento em cache, cache legado e cache de dois níveis. Normalmente, o cache de dois níveis é mais eficiente que o cache legado por causa das otimizações nesse modo. O padrão é o cache de legado, embora o cache em dois níveis seja recomendado. Defina esta configuração por meio da propriedade do sistema da seguinte forma:
com.ibm.ws.pm.useLegacyCache=false

com.ibm.ws.pm.grouppartialupdate e com.ibm.ws.pm.batch

O recurso de atualizações parciais melhora o desempenho dos aplicativos com enterprise beans em determinados cenários. O gerenciador de persistência possui dois mecanismos de armazenamento em cache disponíveis, cache legado e cache de dois níveis. Normalmente, o cache de dois níveis tem desempenho melhor que o legado, por causa das otimizações nesse modo.

Configurações suportadas Configurações suportadas: Os beans de entidade não são suportados em EJB 3.x e em módulos mais recentes.sptcfg
Em determinados aplicativos onde você deve executar atualizações em lote e atualizações parciais, você deve configurar as seguintes propriedades do sistema para obter benefícios de ambos:
'com.ibm.ws.pm.grouppartialupdate=true' and 'com.ibm.ws.pm.batch=true'

Ícone que indica o tipo de tópico Tópico de Referência



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rprf_ejbcontainer
Nome do arquivo: rprf_ejbcontainer.html