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.
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
.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.

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.
sptcfgBeans 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.
<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.
- Elemento XML stateful-timeout
- Anotação @StatefulTimeout
- ibm-ejb-jar-ext.xml ou ibm-ejb-jar-ext.xmi
- Propriedade do sistema com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout
- 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.
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.
-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true

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.

-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.

-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.
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 |

com.ibm.ws.pm.useLegacyCache
Especifica o nome da classe Java que o produto utiliza para implementar a interface javax.rmi.CORBA.UtilDelegate.

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.

'com.ibm.ws.pm.grouppartialupdate=true' and 'com.ibm.ws.pm.batch=true'