IBM WebSphere Application Server, Advanced Edition
Guia de Ajustes
IBM WebSphere Application Server, Advanced EditionGuia de Ajustes |
|
Assistente do ajustador de desempenho
Armazenamento em cache de fragmento dinâmico
Para chamá-los a partir do console administrativo, selecione Console > Assistentes > Ajustador de Desempenho.
Consulte o artigo 6.6.21 do InfoCenter, para obter mais informações.
O armazenamento em cache de fragmento dinâmico é a capacidade de armazenar em cache a saída de servlets e arquivos JSP dinâmicos, uma tecnologia que melhora muito o desempenho do aplicativo. Essa cache, trabalhando na JVM de um servidor de aplicativos, intercepta chamadas para um método service() do servlet, verificando se ele pode atender essa chamada a partir da cache, em vez de executar o servlet novamente. Como os aplicativos J2EE possuem proporções altas de leitura-gravação e podem tolerar um grau pequeno de latência na atualização de seus dados, o armazenamento em cache do fragmento pode criar uma oportunidade para ganhos excelentes no tempo de resposta do servidor, rendimento e escalabilidade.
Depois que um servlet é executado (gerando a saída que será armazenada em cache), é gerada uma entrada de cache contendo essa saída. Também são gerados efeitos colaterais da execução (isto é, a chamada de outros servlets ou arquivos JSP), além de meta-dados sobre a entrada, incluindo informações de tempo limite e de prioridade de entrada. Entradas exclusivas são diferenciadas por uma cadeia de IDs gerados a partir do objeto HttpServletRequest para cada chamada do servlet. Isso resulta em um servlet sendo armazenado em cache dependendo dos parâmetros do pedido, da URI utilizada para chamar o servlet ou de informações da sessão. Como os arquivos JSP são compilados pelo WebSphere Application Server nos servlets, os JSPs e os servlets são utilizados de forma passível de alteração (exceto ao declarar elementos em um arquivo XML).
Para definir isso:
Consulte o artigo 4.5: Armazenamento em cache de fragmento dinâmico do InfoCenter, para obter mais informações.
| Sintoma | Informações adicionais |
| O rendimento e o tempo de resposta são indesejáveis. | Velocidade do processador |
|
AIX: Erro de alocação de memória Solaris: Arquivos abertos em excesso | Descritores de arquivos do AIX (ulimit) ou Descritores de arquivos do Solaris (ulimit) |
| Solaris: O servidor é bloqueado durante os períodos de pico, as respostas levam minutos, a utilização do processador permanece alta em toda a atividade nos processos do sistema e netstat mostra que vários soquetes estão abertos para a porta 80 no estado CLOSE_WAIT ou FIN_WAIT_2. | tcp_close_wait_interval/tcp_time_wait_interval do Solaris e tcp_fin_wait_2_flush_interval do Solaris |
| Windows NT/2000: O Netstat mostra que muitos soquetes estão em TIME_WAIT. | TcpTimedWaitDelay do Windows NT/2000 |
| HP-UX 11: O rendimento é indesejado e a prioridade do servidor de aplicativos não foi ajustada. | Ajustando a prioridade do sistema operacional do processo do WebSphere Application Server |
| Na carga, os pedidos do cliente não chegam no servidor Web porque eles excedem o tempo limite ou são rejeitados. |
Para HP-UX 11, consulte HP-UX 11 tcp_conn_request_max Para IIS Windows NT/2000, consulte o parâmetro ListenBackLog Para IBM HTTP Server no NT, consulte ListenBackLog |
| Windows NT/2000: O desempenho do WebSphere Application Server diminuiu depois que um servidor de aplicativos de outro fornecedor foi instalado. | Propriedades de Permissões do IIS |
| A métrica de porcentagem máxima do Analisador de Recursos indica que o conjunto de threads do contêiner da Web é muito pequeno. | Máximo de conexões ThreadsMax do contêiner da Web |
| O Netstat mostra muitos soquetes de estado TIME_WAIT para a porta 9080. | Máximo de transportes Keep-Alive do contêiner da Web |
| Muita entrada/saída de disco devido à paginação. | Definições de tamanho da pilha |
| O métrico de porcentagem utilizada do Analisador de Recursos para um conjunto de conexões de origem de dados indica o tamanho do conjunto como muito grande. | Tamanho do conjunto de conexões da origem de dados do WebSphere |
| A cache de instrução preparada do Analisador de Recursos descarta o métrico que indica que o tamanho da cache de instrução preparada da origem de dados é muito pequeno. | Tamanho da cache de instrução preparada |
| Muita entrada/saída ocorre devido aos registros do log de gravação do DB2. | DB2 MinCommit |
| A métrica de porcentagem máxima do Analisador de Recursos indica que o conjunto de threads do Object Request Broker é muito pequeno. | Enfileiramento e beans corporativos |
| A JVMPI (Java Virtual Machine Profiler Interface) do Analisador de Recursos indica utilização excessiva de objetos quando muito tempo está sendo gasto na coleta de lixo. | Detectando utilização excessiva de objetos |
| O métrico de memória utilizada do Analisador de Recursos mostra fugas de memória e o Java exibe uma exceção Sem Memória. | Detectando fugas de memória |
| O rendimento, o tempo de resposta e a escalabilidade são indesejáveis. | Se o aplicativo permitir, utilize o armazenamento em cache de fragmento dinâmico |
Uma ampla variedade de aperfeiçoamentos de desempenho pode ser feita no WebSphere Application Server
ao utilizar procedimentos disponíveis para ajuste. Esse guia de ajuste ensina como o ajuste
funciona, fornecendo recomendações gerais e uma descrição de metodologias específicas de ajuste. Encontram-se também disponíveis dicas e sugestões sobre os vários fatores e variáveis que podem melhorar o ajuste de desempenho.
Utilize o guia de ajustes junto com seus exemplos e recursos para expandir sua experiência
com o ajuste. O ajuste é um processo de
aprendizado contínuo. Os resultados podem variar daqueles apresentados neste guia.
Para sua comodidade, são descritos alguns procedimentos para a definição de parâmetros em outros produtos. Como esses produtos podem ser alterados, pense nesses procedimentos como sugestões.
Há dois tipos de ajuste: ajuste do aplicativo e ajuste do parâmetro.
Embora o ajuste do aplicativo ofereça, às vezes, os melhores aperfeiçoamentos de ajuste, este documento focaliza os parâmetros individuais de desempenho e a sinergia entre eles.
O documento técnico, WebSphere Application Server Development Best Practices for Performance and Scalability, trata do ajuste de aplicativo descrevendo as melhores práticas de desenvolvimento para os servlets de conteúdo de aplicativos da Web, arquivos JSP (Java Server Pages), JDBC (Java Database Connectivity) e aplicativos corporativos que contêm componentes de bean corporativo.
A tabela a seguir lista vários parâmetros de ajuste de melhora de alto desempenho:
Os parâmetros a seguir ajudam
a prevenir problemas funcionais:
| Parâmetro ListenBackLog: Aplica-se se o Windows NT/2000 for executado com o IIS sob uma carga pesada do cliente |
| Tipo de transporte: Utilize Soquetes INET no Solaris (o padrão para o WebSphere Application Server) |
| Número de conexões ao DB2: Se você estabelecer mais conexões do que o DB2 configura por padrão |
| Permitir alocação de thread além do máximo foi selecionado e o sistema está sobrecarregado porque muitos threads estão alocados. |
| Utilizando os Soquetes TCP para DB2 no Linux: Para bancos de dados locais |
| Tamanho do conjunto de conexões da origem de dados do WebSphere: Certifique-se de ter conexões suficientes para tratar de conexões extras requeridas para o processamento de transação com Entity EJBs e para evitar bloqueios. |
O WebSphere Application Server possui uma série de componentes inter-relacionados que devem estar bem ajustados entre si para suportar as necessidades habituais de seu aplicativo de e-business de ponta a ponta. Esses ajustes ajudam o sistema a atingir um rendimento máximo, enquanto mantém a estabilidade geral do sistema.
O WebSphere Application Server estabelece uma rede de enfileiramento, que é uma rede de filas interconectadas que representam os vários componentes do aplicativo que atende a plataforma. Essas filas incluem a rede, o servidor Web, o contêiner da Web, o contêiner de EJB, a origem de dados e, possivelmente, um gerenciador de conexões para um sistema backend personalizado. Cada um desses recursos representa uma fila de pedidos que aguardam para utilizar esse recurso.
As filas do WebSphere são recursos dependentes de carga. O tempo médio de atendimento de um pedido depende do número de clientes simultâneos.
A maioria das filas que constituem a rede de enfileiramento são filas fechadas. Em comparação com uma fila aberta, uma fila fechada coloca um limite no número máximo de pedidos presentes na fila.
Uma fila fechada permite que os recursos do sistema sejam rigorosamente gerenciados. Por exemplo, a definição Número Máximo de Conexões do contêiner da Web controla o tamanho da fila do contêiner da Web. Se a média de execução do servlet em um contêiner da Web criar 10 MB de objetos durante cada pedido, definir o número máximo de conexões com um valor de 100 limitaria a memória consumida pelo contêiner da Web para 1 GB.
Em uma fila fechada, um pedido pode ter um de dois estados: ativo ou aguardando. Um pedido ativo está em execução ou aguardando uma resposta de uma fila downstream. Por exemplo, um pedido ativo no servidor Web está executando trabalho (como por exemplo, recuperando HTML estático) ou aguardando a conclusão de um pedido no contêiner da Web. No estado aguardando, o pedido está aguardando para se tornar ativo. O pedido permanecerá no estado aguardando até que um dos pedidos ativos saia da fila.
Todos os servidores Web suportados pelo WebSphere Application Server são filas fechadas, assim como as origens de dados do WebSphere Application Server. Os contêineres da Web podem ser configurados como filas abertas ou fechadas. Em geral, é melhor que sejam filas fechadas. Os contêiners de EJB são filas abertas; se não houver threads disponíveis no conjunto, um novo será criado para a duração do pedido.
Se os beans corporativos estiverem sendo chamados por servlets, o contêiner da Web limitará o número total de pedidos simultâneos em um contêiner de EJB porque o contêiner da Web também possui um limite. Isto só se aplicará se beans corporativos forem chamados a partir do thread de execução do servlet. Não há impedimentos para que você crie threads e encha o contêiner de EJB com pedidos. Esta é uma das razões pelas quais não é recomendável que um servlet crie seus próprios threads de trabalho.
Os itens a seguir destacam as várias definições de fila:
A seção a seguir descreve a metodologia para a configuração de filas do WebSphere Application Server. A dinâmica do sistema pode ser alterada e, portanto, seus parâmetros de ajuste, movendo recursos (por exemplo, mover seu servidor de banco de dados para outra máquina) ou fornecendo recursos mais potentes, como um conjunto de CPUs mais rápidas com mais memória. Assim, ajuste os parâmetros de ajuste para uma configuração específica do ambiente de produção.
A primeira regra de ajuste é reduzir o número de pedidos nas filas do WebSphere Application Server. Em geral, é melhor que os pedidos aguardem na rede (na frente do servidor Web) do que no WebSphere Application Server. Essa configuração permitirá que fiquem na rede de enfileiramento somente os pedidos que estiverem prontos para serem processados. Para realizar essa configuração, especifique as filas mais upstream (mais próximas do cliente) para que fiquem um pouco maiores e especifique as filas mais downstream (mais além do cliente) para que fiquem progressivamente menores.
As filas nesta rede de enfileiramento são progressivamente menores, conforme o trabalho flui no sentido downstream. Quando 200 clientes chegarem no servidor Web, 125 pedidos permanecerão em fila na rede porque o servidor Web foi definido para tratar de 75 clientes simultâneos. À medida que os 75 pedidos passarem do servidor Web para o contêiner da Web, 25 permanecerão enfileirados no servidor Web e os 50 restantes serão tratados pelo contêiner da Web. Esse processo avançará pela origem de dados até que os 25 usuários cheguem ao destino final, o servidor do banco de dados. Porque, em cada ponto upstream, há trabalho aguardando para colocar um componente; neste sistema, nenhum componente terá que aguardar a chegada de trabalho. A quantidade em massa de pedidos aguarda na rede, fora do WebSphere Application Server. Isso dá estabilidade porque nenhum componente é sobrecarregado. Software de roteamento como o Network Dispatcher da IBM pode ser utilizado para direcionar usuários que estão aguardando para outros servidores em um cluster do WebSphere Application Server.
Utilizando uma etapa de teste que represente todo o sentido do aplicativo de produção (por exemplo, ele utiliza todos os caminhos de códigos significativos) ou utilizando o próprio aplicativo de produção, execute um conjunto de experiências para determinar quando os recursos do sistema serão maximizados (o ponto de saturação). Conduza esses testes depois que a maioria dos gargalos tiver sido removida do aplicativo. O objetivo comum desses testes é levar as CPUs a uma utilização de quase 100%.
Inicie sua primeira experiência de linha de base com filas grandes. Isso permitirá o máximo de simultaneidade no sistema. Por exemplo, inicie a primeira experiência com um tamanho de fila de 100 em cada um dos servidores na rede de enfileiramento: servidor Web, contêiner da Web e origem de dados.
A seguir, comece uma série de experiências para marcar uma curva de rendimento, aumentando o carregamento de usuários simultâneos depois de cada experiência. Por exemplo, faça experiências com 1 usuário, 2 usuários, 5, 10, 25, 50, 100, 150 e 200 usuários. Depois de cada execução, registre o rendimento (pedidos po segundo) e os tempos de resposta (segundos por pedido).
A curva resultante de suas experiências de linha de base devem ser semelhantes à curva de rendimento comum conforme mostrada:
O rendimentos do WebSphere Application Server é uma função do número de pedidos simultâneos presentes no sistema total. A seção A, a área de carregamento leve mostra que, conforme o número de pedidos de usuários simultâneos aumenta, o rendimento aumenta quase de forma linear ao número de pedidos. Isso prova que, em carregamentos leves, os pedidos simultâneos encontram muito pouco congestionamento nas filas do sistema do WebSphere Application Server. Em algum ponto, o congestionamento começa a aumentar e o rendimento aumenta em uma taxa muito mais baixa, até atingir um ponto de saturação que represente o valor de rendimento máximo, conforme determinado por algum gargalo no sistema WebSphere Application Server. O melhor tipo de gargalo gerenciável ocorre quando as CPUs das máquinas do WebSphere Application Server ficam saturadas. Isso é desejável porque é possível resolver um gargalo na CPU incluindo CPUs adicionais ou mais potentes.
Na área de carregamento pesado ou na Seção B, conforme a carga do cliente simultâneo aumenta, o rendimento permanece relativamente constante. Porém, o tempo de resposta aumentará proporcionalmente ao carregamento de usuários. Isso significa que, se você dobrar o carregamento de usuários na área de carregamento pesado, o tempo de resposta dobrará. Em algum ponto, representado pela Seção C, a área de redução, um dos componentes do sistema se esgota. Nesse ponto, o rendimento começa a diminuir. Por exemplo, o sistema pode entrar na área de redução quando as conexões da rede no servidor Web esgotarem os limites da placa de rede ou se você exceder os limites do sistema operacional para identificadores de arquivos.
Se o ponto de saturação for atingido ao levar as CPUs do sistema a uma utilização de quase 100%, passe para a próxima etapa. Se a CPU não for conduzida a 100%, provavelmente existe um gargalo que está sendo agravado pelo aplicativo. Por exemplo, o aplicativo pode estar criando objetos Java em excesso, causando gargalos na coleta de lixo no Java.
Existem duas maneiras de gerenciar gargalos do aplicativo: remover o gargalo ou clonar o gargalo. A melhor maneira de gerenciar um gargalo é removê-lo. Utilize um criador de perfil do aplicativo baseado em Java para examinar a utilização de todos os objetos. Os criadores de perfis como PTDV (Performance Trace Data Visualizer), JProbe e Jinsight podem ser utilizados.
O número de usuários simultâneos no ponto de saturação representa a simultaneidade máxima do aplicativo. Por exemplo, se o aplicativo saturou o WebSphere Application Server com 50 usuários, você perceberá que 48 usuários deram a melhor combinação de rendimento e tempo de resposta. Esse valor é chamado Simultaneidade Máxima de Aplicativos. A Simultaneidade Máxima de Aplicativos se torna o valor a ser utilizado como a base para o ajuste das filas do sistema do WebSphere Application Server. Lembre-se que é desejável que a maioria dos usuários aguarde na rede, diminuindo os tamanhos de filas, à medida que se move do cliente no sentido downstream. Por exemplo, dado um valor de Simultaneidade Máxima de Aplicativos de 48, inicie com filas do sistema nos seguintes valores: servidor Web 75, contêiner da Web 50, origem de dados 45. Faça uma série de experiências adicionais, ajustando esses valores como ligeiramente superior e inferior para encontrar as melhores definições.
O Analisador de Recursos pode ser utilizado para determinar o número usuários simultâneos através da métrica threads simultaneamente ativos do conjunto de threads do mecanismo de servlet.
Em experiências de desempenho, o rendimento aumentou de 10 a 15% quando o máximo de transporte Keep-Alive do contêiner da Web é ajustado para corresponder ao número máximo de threads do contêiner da Web.
Em muitos casos, somente uma parte dos pedidos que passam por uma fila entrará na próxima fila downstream. Em um site com várias páginas estáticas, muitos pedidos serão preenchidos no servidor Web e não passarão para o contêiner da Web. Nessas circunstâncias, a fila do servidor Web pode ser muito maior que a fila do contêiner da Web. Na seção anterior, a fila do servidor Web foi definida como 75 em vez de mais próxima ao valor de Simultaneidade Máxima de Aplicativos. É necessário fazer ajustes semelhantes quando componentes diferentes possuem tempos de execução diferentes.
Por exemplo, em um aplicativo que gaste 90% de seu tempo em um servlet complexo e somente 10% fazendo uma breve consulta de JDBC, em média, somente 10% dos servlets estarão utilizando as conexões do banco de dados a qualquer momento, portanto, a fila de conexões do banco de dados poderá ser significantemente menor que a fila do contêiner da Web. De modo contrário, se grande parte do tempo de execução de um servlet for gasta fazendo uma consulta complexa em um banco de dados, pense em aumentar os valores da fila no contêiner da Web e na origem de dados. Sempre monitore a utilização da CPU e da memória de ambos os servidores, WebSphere Application Server e de banco de dados, para assegurar-se de que não esteja saturando a CPU ou a memória.
As chamadas de métodos para os beans corporativos serão colocadas na fila somente se o cliente que estiver fazendo a chamada do método for remoto. Por exemplo, se o cliente EJB estiver sendo executado em um Java Virtual Machine separado (outro espaço de endereçamento) do bean corporativo. Por outro lado, se o cliente EJB (um servlet ou outro bean corporativo) estiver instalado na mesma JVM, o método EJB será executado no mesmo thread de execução que o cliente EJB e não haverá enfileiramento.
Os beans corporativos remotos se comunicam utilizando o protocolo RMI/IIOP. As chamadas de métodos iniciadas no RMI/IIOP são processadas por um ORB do lado do servidor. O conjunto de threads age como uma fila para pedidos de entrada. Entretanto, se um pedido de método remoto for emitido e não houver mais threads disponíveis no conjunto de threads, um novo thread será criado. Depois que o pedido de método for concluído, o thread será destruído. Portanto, quando o ORB for utilizado para processar pedidos de métodos remotos, o contêiner de EJB será uma fila aberta, porque o seu uso de threads está livre. A ilustração a seguir descreve as duas opções de enfileiramento de beans corporativos.
Ao configurar o conjunto de threads, é importante entender os padrões de chamada do cliente EJB. Se um servlet estiver fazendo um pequeno número de chamadas a beans corporativos remotos e cada chamada de método for relativamente rápida, pense em definir o número de threads no conjunto de threads do ORB com um valor menor do que o valor para o tamanho do conjunto de threads do contêiner da Web.
O Analisador de Recursos mostra uma métrica chamada porcentagem máxima utilizada para determinar quanto tempo todos os threads configurados estão em uso. Se esse valor estiver consistentemente nos dígitos duplos, o ORB poderá ser um gargalo e o número de threads deverá ser aumentado.
O grau com que se deve aumentar o valor do conjunto de threads do ORB é uma função do número de servlets simultâneos (isto é, clientes) chamando beans corporativos e a duração de cada chamada de método. Se as chamadas de método forem muito longas, pense em tornar o tamanho do conjunto de threads do ORB igual ao tamanho do contêiner da Web, porque há pouca intercalação de chamadas de métodos remotas. Se seu servlet fizer somente chamadas de pequena duração ou rápidas para o ORB, o conjunto de threads do ORB poderá ser pequeno. Vários servlets podem reutilizar o mesmo thread do ORB potencialmente. Nesse caso, o conjunto de threads do ORB pode ser pequeno, talvez até metade da definição de tamanho do conjunto de threads do contêiner da Web. Se seu aplicativo gastar muito tempo no ORB, configure um relacionamento mais equilibrado entre o contêiner da Web e o ORB.
Os recursos de clonagem dos servidores de aplicativos podem ser um item importante na configuração de ambientes de produção altamente escaláveis. Isso é verdadeiro especialmente quando o aplicativo está enfrentando gargalos que estão impedindo a total utilização da CPU de servidores SMP (Symmetric Multiprocessing). Ao ajustar as filas do sistema do WebSphere Application Server em configurações de clusters, lembre-se de que quando um servidor é incluído em um cluster, o servidor downstream recebe o dobro da carga.
Dois clones do contêiner da Web estão localizados entre um servidor Web e uma origem de dados. Podemos assumir que o servidor Web, os mecanismos de servlet e a origem de dados (mas não o banco de dados) estão em execução em um único servidor SMP. Dadas estas limitações, precisam ser feitas as seguintes considerações sobre a fila:
Quando uma conexão SSL é estabelecida, entra em ação um protocolo de reconhecimento de SSL. Após ser feita uma conexão, a SSL executa a criptografia e decriptografia em massa para cada leitura-gravação. O custo do desempenho de um protocolo de reconhecimento de SSL é maior do que da criptografia e decriptografia em massa.
Para melhorar o desempenho de SSL, o número de conexões SSL individuais e de protocolos de reconhecimento deve ser reduzido.
A redução do número de conexões aumenta o desempenho para comunicação segura através de conexões SSL, bem como comunicação não-segura através de conexões simples de TCP. Uma maneira de diminuir as conexões SSL individuais é utilizar um navegador que suporta HTTP 1.1. A redução de conexões SSL individuais poderá se impossível para alguns usuários, se elas não puderem atualizar para HTTP 1.1.
É mais comum diminuir o número de conexões (TCP e SSL) entre dois componentes do WebSphere Application Server. As instruções a seguir que ajudam a garantir o transporte HTTP do servidor de aplicativos é configurada, para que o plug-in do servidor Web não reabra repetidamente novas conexões ao servidor de aplicativos:
Os acelerador de hardware atualmente suportados pelo WebSphere Application Server, aumentam apenas o desempenho do protocolo de reconhecimento de SSL, não a criptografia/decriptografia em massa. Tipicamente, um acelerador beneficia apenas o servidor Web, porque as conexões do servidor Web são de pequena duração. Todas as outras conexões SSL no WebSphere Application Server são de longa duração; essas conexões não se beneficiam de um dispositivo de hardware que apenas acelera protocolos de reconhecimento de SSL.
O desempenho de um conjunto de cifras é diferente com o software e o hardware. Apenas porque um conjunto de cifras é melhor executado no software, isso não significa que executará melhor com o hardware. Alguns algoritmos são tipicamente ineficientes no hardware (por exemplo, DES e 3DES), entretanto, o hardware especializado fornece implementações eficientes desses mesmos algoritmos.
O desempenho de criptografia e decriptografia em massa é afetado pelo conjunto de cifras utilizado para uma conexão SSL individual. O software de teste que calcula os dados utilizou o IBM JSSE para o software do cliente e do servidor e não utilizou nenhum suporte de hardware de criptografia. O teste não incluiu o tempo para estabelecer uma conexão, mas o tempo para transmitir dados através de uma conexão estabelecida. Entretanto, os dados revelam o desempenho de SSL relativo de vários conjuntos de cifras para conexões de longa execução.
Antes de estabelecer uma conexão, o cliente ativou um único conjunto de cifras para cada etapa de teste. Após a conexão ser estabelecida, o cliente calculou quanto tempo levou para gravar um valor inteiro no servidor e do servidor para gravar o número especificado de bytes novamente para o cliente. A variação da quantidade de dados teve efeitos insignificantes no desempenho relacionado dos conjuntos de cifras. O quadro a seguir mostra o desempenho de cada conjunto de cifras.
Uma análise dos dados acima revela o seguinte:
A lista de verificação inclui estas definições:
A opção de consolidação A fornece o máximo de desempenho do bean corporativo através do armazenamento em cache de dados do banco de dados fora do escopo de transação. Geralmente, a opção de consolidação A é apenas aplicável onde o contêiner EJB possui acesso exclusivo a determinado banco de dados. Do contrário, a integridade de dados é comprometida. A opção de consolidação B fornece armazenamento em cache mais agressivo de instâncias de objetos do EJB de Entidade, o qual pode resultar no desempenho melhorado sobre a opção de consolidação C, mas também resulta na utilização de memória maior. A opção de consolidação C é a configuração de mundo real mais comum para EJBs de Entidade.
As definições das propriedades Ativar Em e Carregar Em determinam quais opções de consolidação são utilizadas.
O nível de isolamento também reproduz uma função importante no desempenho. Os níveis de isolamento superiores reduzem o desempenho através do aumento do bloqueio de linha e sobrecarga do banco de dados ao reduzir o acesso de dados simultâneo. Vários bancos de dados fornecem procedimento diferente com respeito às definições de isolamento. Em geral, a Leitura Repetível é uma definição apropriada para bancos de dados do DB2. A Leitura Consolidada, geralmente, é para o Oracle. O Oracle não suporta a Leitura Repetível e irá converter essa definição para o mais alto nível de isolamento serializável.
O nível de isolamento pode ser especificado no bean ou no nível de método. Entretanto, é possível configurar definições de isolamento diferentes para vários métodos. Isso é uma vantagem quando alguns métodos requerem isolamento superior aos outros e podem ser utilizados para atingirem o desempenho máximo ao manter os requisitos de integridade. Entretanto, o isolamento não pode alterar entre as chamadas do método dentro de uma única transação do bean corporativo. Uma exceção de tempo de execução será emitida nesse caso.
Leitura Repetível
Este nível proíbe leituras sujas e não repetíveis,
mas permite leituras irreais.
Leitura Consolidada
Este nível proíbe leituras sujas, mas permite
leituras não repetíveis e irreais.
Leitura Não Consolidada
Este nível permite leituras sujas, não repetíveis
e irreais.
O contêiner utiliza o atributo de nível de isolamento da transação da seguinte forma:
Se o cliente chamar um método bean fora de um contexto de transação, o contêiner se comportará da mesma forma que se o atributo de transação Não Suportado estivesse definido. O cliente deve chamar o método sem um contexto de transação.
Obrigatório
Esse valor legal direciona o contêiner para sempre chamar o método bean no contexto de transação associado ao cliente. Se o cliente tentar chamar o método bean sem um contexto de transação, o contêiner emitirá a exceção javax.jts.TransactionRequiredException para o cliente. O contexto de transação é passado para qualquer objeto do bean corporativo ou recurso acessado por um método de bean corporativo.
Os clientes do bean corporativo que acessam esses beans de entidade devem fazer isso em uma transação existente. Para outros beans corporativos, o método do bean ou bean corporativo deve implementar o valor Bean Gerenciado ou utilizar o valor Requerido ou Requer Novo. Para clientes de EJB de beans não corporativos, o cliente deve chamar uma transação utilizando a interface javax.transaction.UserTransaction.
Requer Novo
Esse valor legal direciona o contêiner para sempre chamar o método bean em um novo contexto de transação, independentemente de o cliente chamar o método dentro ou fora de um contexto de transação. O contexto de transação é passado para quaisquer objetos
de beans corporativos ou recursos que sejam utilizados por este método bean.
Necessário
Esse valor legal direciona o contêiner para chamar o método bean no contexto de transação. Se um cliente chamar um método bean em um contexto
de transação, o contêiner chamará o método bean no contexto de
transação do cliente. Se um cliente chamar um método bean fora de um contexto de transação, o contêiner criará um novo contexto de transação e chamará o método bean de dentro desse contexto. O contexto de transação é passado para quaisquer objetos
de beans corporativos ou recursos que sejam utilizados por este método bean.
Suportes
Esse valor legal direciona o contêiner para chamar o método bean em um contexto de transação se o cliente chamar o método bean em uma transação. Se o cliente chamar o método bean sem um contexto de transação,
o contêiner chamará o método bean sem um contexto
de transação. O contexto de transação é passado para quaisquer objetos
de beans corporativos ou recursos que sejam utilizados por este método bean.
Não Suportado
Esse valor legal direciona o contêiner para chamar métodos bean sem um contexto de transação. Se um cliente chamar um método bean em um contexto de
transação, o contêiner suspenderá a associação entre a transação e o
thread atual antes de chamar o método na instância do bean
corporativo. O contêiner então retoma a associação suspensa
quando a chamada do método é retornada. O contexto de transação suspenso não é passado para nenhum objeto de bean corporativo ou para recursos que são utilizados por este método bean.
Bean Gerenciado
Esse valor notifica o contêiner de que a classe do bean manipula diretamente a demarcação da transação. Esta propriedade pode ser especificada somente para beans de sessão e não pode ser especificada para métodos bean individuais.
Examinar a coleta de lixo do Java pode dar uma visão de como o aplicativo está utilizando a memória. A coleta de lixo é uma intensidade do Java. Ao tirar a difícil função de gerenciamento de memória do escritor de aplicativos, os aplicativos Java tendem a ser muito mais robustos do que os aplicativos escritos em linguagens que não fornecem a coleta de lixo. Esta robustez é aplicada desde que o aplicativo não esteja utilizando objetos em excesso. É normal que a coleta de lixo consuma em qualquer lugar de 5 a 20% do tempo de execução total de um aplicativo que funcione adequadamente. Se não for gerenciada, a coleta de lixo poderá ser o maior gargalo de um aplicativo, especialmente ao ser executada em máquinas de servidores SMP.
Utilize a coleta de lixo para avaliar as condições gerais de desempenho do aplicativo. Monitorando a coleta de lixo durante a execução de uma carga de trabalho fixa, os usuários poderão saber se o aplicativo está utilizando objetos em excesso. A coleta de lixo pode até mesmo ser utilizada para detectar a presença de falta de memória.
Utilize a coleta de lixo e as estatísticas de heap no Analisador de Recursos para avaliar as condições gerais de desempenho do aplicativo. Monitorando a coleta de lixo, as fugas de memória e a utilização excessiva de objetos podem ser detectadas.
Para esse tipo de investigação, defina os tamanhos mínimo e máximo do heap com o mesmo valor. Escolha uma carga de trabalho representativa, repetitiva, que corresponda o mais próximo possível ao uso de produção (erros do usuário e todos). Também é importante permitir que o aplicativo execute vários minutos até que o estado do aplicativo seja estabilizado.
Para garantir estatísticas significativas, execute a carga de trabalho fixa até que o estado do aplicativo seja fixo. Geralmente isto leva alguns minutos.Para ver se seu aplicativo está utilizando objetos em excesso, consulte o Analisador de Recursos nos contadores do criador de perfis da JVMPI. O tempo médio entre as chamadas de coleta de lixo deve ser 5 a 6 vezes a duração média de uma única coleta de lixo. Caso contrário, o aplicativo estará gastando mais de 15% de seu tempo em coleta de lixo. Examine também os números de objetos liberados, alocados e movidos.
Se as informações indicarem um gargalo da coleta de lixo, há duas maneiras de limpá-lo. A solução de menor custo para otimizar o aplicativo é implementar caches e conjuntos de objetos. Utilize um criador de perfis Java para determinar quais objetos devem ser direcionados. Se o aplicativo não puder ser otimizado, a inclusão de memória, processadores e clones poderá ajudar. A memória adicional permite que cada clone mantenha um tamanho de heap considerável. Os processadores adicionais permitem que os clones sejam executados em paralelo.
As fugas de memória no Java são um perigoso contribuinte para gargalos da coleta de lixo. Elas são piores que a utilização excessiva de memória, porque uma fuga de memória, basicamente, conduz a uma instabilidade do sistema. Com o tempo, a coleta de lixo ocorrerá mais freqüentemente, até que, finalmente, o heap seja esgotado e o Java falhe com uma exceção fatal Sem Memória. As fugas de memória ocorrem quando um objeto desnecessário tem referências que nunca são excluídas. Isso ocorre mais comumente em classes de coleta, como a Hashtable, porque a própria tabela sempre tem uma referência para o objeto, mesmo depois que as referências reais foram excluídas.
É uma reclamação comum que aplicativos quebrem imediatamente após ser implementado no ambiente de produção. A carga de trabalho alta freqüentemente é a causa. Isso é especialmente certo para aplicativos de fuga onde a carga de trabalho alta acelera a magnitude da fuga e ocorre a falha de alocação de memória.
O teste de fuga de memória relata a magnitude dos números. As fugas de memória são medidas em função da quantidade de bytes ou de kilobytes que não pode ser lixo coletado. A tarefa delicada é diferenciar essas quantidades de tamanhos esperados de memória útil e não utilizável. Essa tarefa será atingida mais facilmente, se os números forem ampliados, resultando em intervalos grandes e fácil identificação de inconsistências. A seguir encontra-se uma lista de conclusões importantes sobre fugas de memória:
Os testes repetitivos podem ser utilizados no nível do sistema ou do módulo. A vantagem com o teste modular é melhor controle. Quando um módulo é designado para que tudo que ocorra nele seja mantido em segredo e não crie efeitos colaterais externos incluindo utilização de memória, o teste de fugas de memória pode ser muito mais fácil. Primeiro, a utilização da memória antes do módulo é registrada e, em seguida, um conjunto fixo de etapas de teste é executado repetidamente. No final da execução do teste, a utilização da memória atual será repetidamente aquela registrada e verificada anteriormente, se tiver sido alterada significantemente. Lembre-se, a coleta de lixo deve ser forçada ao registrar a utilização da memória atual. Para fazer isso, insira System.gc() no módulo onde deseja que ocorra a coleta de lixo ou o uso de uma ferramenta de perfil faz com que esse evento ocorra.
Considere o seguinte quando escolher quais etapas de teste utilizar para o teste de fuga de memória:
O Analisador de Recursos ajuda a determinar se há uma fuga de memória. Para obter melhores resultados, repita as experiências com aumento de duração, como 1000, 2000 e 4000 pedidos de páginas. O gráfico do Analisador de Recursos de memória utilizada deve ter um formato de dente de serra. Cada parte do gráfico corresponde a uma coleta de lixo. Haverá uma fuga de memória se um dos seguintes itens ocorrer:
Se o consumo de heap indicar uma possível fuga durante a carga de trabalho pesada (o servidor de aplicativos está consistentemente perto de 100% de utilização da CPU), contudo o heap parece recuperar-se durante uma carga de trabalho subseqüente mais leve ou quase ociosa, essa é uma indicação de fragmentação de heap. A fragmentação de heap pode ocorrer quando a JVM consegue liberar objetos suficientes para atender pedidos de alocação de memória durante os ciclos de coleta de lixo, mas não tem tempo para compactar pequenas áreas de memória livre no heap em espaços contínuos e maiores.
Outra forma de fragmentação de heap ocorre quando pequenos objetos (menos de 512 bytes) são liberados. Os objetos são liberados, mas o armazenamento não é recuperado, resultando na fragmentação da memória.
A fragmentação de heap pode ser evitada ativando o sinalizador -Xcompactgc nos argumentos da linha de comandos de definições avançadas da JVM. O -Xcompactgc garante que cada ciclo de coleta de lixo elimina a fragmentação, mas com uma pequena penalidade de desempenho.
Os parâmetros de heap do Java também influenciam o comportamento da coleta de lixo. O aumento do tamanho do heap permite a criação de mais objetos. Como um heap grande demora mais para ser preenchido, o aplicativo é executado durante mais tempo antes de ocorrer uma coleta de lixo. Entretanto, um heap grande também demora mais para ser compactado. A coleta de lixo também demorará mais.
A ilustração representa três perfis de CPU, cada um executando uma carga de trabalho fixa com definições de heap do Java variáveis. No perfil do meio, as definições são de tamanho inicial e máximo do heap ou 128 MB. Há quatro coletas de lixo. O tempo total em coleta de lixo é de aproximadamente 15% da execução total. Quando dobramos os parâmetros do heap para 256 M, conforme no perfil superior, a quantidade de tempo de trabalho entre as coletas de lixo aumenta. Há somente três coletas de lixo, mas o comprimento de cada uma também é aumentado. No terceiro perfil, o tamanho do heap foi reduzido para 64 MB e exibe o efeito contrário. Com um heap menor, tanto o tempo entre as coletas de lixo e o tempo para cada coleta são menores. Para as três configurações, o tempo total na coleta de lixo é de aproximadamente 15%. Isso ilustra um conceito importante sobre o heap Java e seu relacionamento com a utilização de objetos. Há sempre um custo para a coleta de lixo em aplicativos Java.
Execute uma série de experiências, variando as definições de heap do Java. Por exemplo, execute experiências com 128 MB, 192 MB, 256 MB e 320 MB. Durante cada experiência, monitore o total de utilização de memória. Se você expandir o heap com muito rigor, poderá ocorrer uma paginação. (Utilize o comando vmstat ou o Monitor de Desempenho do Windows NT/2000 para verificar a paginação.) Se a paginação ocorrer, reduza o tamanho do heap ou inclua mais memória no sistema. Quando todas as execuções estiverem concluídas, compare as seguintes estatísticas:
Se o heap livre for estabelecido em 85% ou mais, considere a diminuição dos valores de tamanho máximo do heap, pois o servidor de aplicativos e o aplicativo estão sob utilização da memória alocada para o heap.
tcp_close_wait_interval/tcp_time_wait_interval do Solaris
tcp_fin_wait_2_flush_interval do Solaris
tcp_keepalive_interval do Solaris
Existem muitos outros parâmetros TCP; sua alteração pode afetar o desempenho de seu ambiente. Para obter mais informações sobre o ajuste da Pilha do TCP/IP, consulte o site na Web Ajustando sua Pilha do TCP/IP e Mais.
Antes de alterar os três parâmetros TCP, o servidor estava sendo retardado durante determinados períodos de pico. O comando netstat mostrou que muitos soquetes abertos para a porta 80 estavam no estado CLOSE_WAIT ou FIN_WAIT_2.
Em ambas as topologias, a opção passar por referência do Object Request Broker é selecionada e o banco de dados backend fica ativo em sua própria máquina dedicada.
Além disso, se a utilização do processador das quatro máquinas for quase 100%, uma quinta máquina poderá ser incluída. Ou, se a máquina do servidor Web não estiver executando na capacidade e o processamento do contêiner da Web não estiver pesado, tente liberar os processadores nas quatro máquinas movendo para a Topologia B.
A mesma relação se aplica ao número de conexões do gerenciador de sessão.
O valor da definição MaxAppls deve ser, no mínimo, igual ao número de conexões.
Se você estiver utilizando o mesmo banco de dados para sessão e origens de dados, MaxAppls precisará
ser a soma do número de definições de conexões para o gerenciador de sessão e das origens de dados.
MaxAppls = (nº de conexões definidas para origem de dados + nº de conexões no gerenciador de sessão) x nº de clones
Depois de calcular as definições de MaxAppls para o banco de dados WAS e para cada um dos bancos de dados do aplicativo, assegure-se de que a definição MaxAgents para o DB2 seja igual ou maior que a soma de todos os MaxAppls.
MaxAgents = soma de MaxAppls para todos os bancos de dados
Esta seção discute as considerações para seleção e configuração do hardware no qual os servidores de aplicativos serão executados.
Permita pelo menos 512 MB de memória para cada processador.
Consulte o documento Práticas de Melhor Administração do WebSphere Application Server para Desempenho e Escalabilidade para obter mais informações sobre a resolução de nome do host no host do cliente administrativo.
Esta seção discute as considerações para ajustar os sistemas operacionais no ambiente de servidor.
Nota:Esses dois parâmetros devem ser utilizados juntos ao ajustar o WebSphere Application Server em um sistema operacional Windows NT/2000.
ulimit -n 2000Para máquinas SMP grandes com clones, emita o seguinte comando:
ulimit -unlimited
Utilize o comando ulimit -a para exibir os valores atuais de todas as limitações dos recursos do sistema.
ulimit -n 1024
Utilize ulimit -a para exibir os valores atuais de todas as limitações dos recursos do sistema.
O servidor pode parar durante determinados períodos de pico. Se isso ocorrer, o comando netstat mostrará que muitos dos soquetes abertos para a porta 80 estavam no estado CLOSE_WAIT ou FIN_WAIT_2. Ocorreram atrasos visíveis de até quatro minutos, durante os quais o servidor não enviou nenhuma resposta, mas a utilização da CPU permaneceu alta, com toda atividade em processos do sistema.
ndd -get /dev/tcp tcp_time_wait_interval ndd -set /dev/tcp tcp_time_wait_interval 60000
O servidor pode parar durante períodos de pico. Utilizando o comando netstat indicou que muitos dos soquetes abertos para a porta 80 estavam no estado CLOSE_WAIT ou FIN_WAIT_2. Ocorreram atrasos visíveis de até quatro minutos, durante os quais o servidor não enviou nenhuma resposta, mas a utilização da CPU permaneceu alta, com toda atividade em processos do sistema.
ndd -get /dev/tcp tcp_fin_wait_2_flush_interval ndd -set /dev/tcp tcp_fin_wait_2_flush_interval 67500
ndd -get /dev/tcp tcp_keepalive_interval ndd -set /dev/tcp tcp_keepalive_interval 300000
Clientes relataram êxito ao modificar outros parâmetros TCP do Solaris, incluindo o seguinte:
tcp_conn_req_max_q tcp_comm_hash_size tcp_xmit_hiwat
Embora não se tenha visto diferenças significativas no desempenho depois de aumentar essas definições, seu sistema obterá benefícios.
Defina através da entrada /etc/system:
set semsys:seminfo_semume = 1024
Defina através da entrada /etc/system:
semsys:seminfo_semopm = 200
É possível modificar as definições do HP-UX 11 para melhorar significativamente o desempenho do WebSphere Application Server.
chatr +pi64M +pd64M /opt/WebSphere/AppServer/java/bin/PA_RISC2.0/native_threads/java
A saída do comando fornece as características atuais do sistema operacional do executável do processo.
Consulte a página na Web Hewlett Packard, para obter mais detalhes sobre essa alteração.
pedidos de conexão eliminados devido à fila cheia
ndd -set /dev/tcp tcp_conn_request_max 1024
Consulte a página na Web Hewlett Packard a seguir, para obter mais detalhes sobre essa alteração.
| Parâmetro do Kernel | Ajuste do WebSphere Application Server | Ajuste do DB2 | Ajuste do Oracle |
| maxdsiz | Não ajustado | Não ajustado | Não ajustado |
| maxdsiz_64b | Não ajustado | Não ajustado | Não ajustado |
| maxuprc | 512 | ||
| maxfiles | 2.048 | ||
| maxfiles_lim | 2.048 | ||
| nkthreads | 10.000 | ||
| max_thread_proc | 2.048 | ||
| nproc | 1.028 | ||
| nflocks | 8.192 | ||
| ninode | 2.048 | ||
| nfile | 8.192 | ||
| msgseg | 32.767 | ||
| msgmnb | 65.535 | ||
| msgmax | 65.535 | ||
| msgtql | 1.024 | ||
| msgmap | 258 | ||
| msgmni | 256 | ||
| msgssz | 16 | ||
| semmni | 512 | 70 | |
| semmap | 514 | ||
| semmns | 1.024 | 200 | |
| semmnu | 1.024 | ||
| shmmax | 966.367.642 | 1 GB | |
| shmmseg | 16 | 10 | |
| shmmni | 300 | 100 |
Consulte a página na Web Hewlett Packard a seguir, para obter mais informações sobre os parâmetros de kernel do HP-UX 11.
O produto WebSphere Application Server fornece plug-ins de várias marcas e versões de servidor Web. Cada combinação do sistema operacional do servidor Web apresenta parâmetros de ajuste específicos que afetam o desempenho do aplicativo.
Esta seção discute as definições de ajuste de desempenho associadas aos servidores Web.
IHS é um servidor de multi-processamento de thread único. Para obter mais informações, consulte essa página na Web sobre Ajustando o IBM HTTP Server
A configuração padrão do iPlanet Web Server Enterprise Edition fornece um servidor de processamento único de vários threads.
Para descobrir se o servidor Web está ficando congestionado, consulte suas estatísticas em perfdump. Examine os seguintes dados:
Nota: Pode ser necessário verificar as permissões do sePlugin:
Minimize a condição utilizando o parâmetro ListenBackLog para aumentar o número de pedidos que o IIS mantém em sua fila.
MaxPoolThreads, PoolThreadLimit
O IBM HTTP Server é facilmente configurado. Geralmente, as definições padrão são aceitáveis.
Como exibir a utilização do thread: Há duas opções para descobrir quantos threads estão sendo utilizados sob carga:
Sigas estas etapas para utilizar o status do servidor IBM HTTP Server:
Cada processo do WebSphere Application Server possui vários parâmetros que influenciam o desempenho dos aplicativos. Cada servidor de aplicativos no produto WebSphere Application Server é composto de um contêiner EJB e de um contêiner da Web.
Utilize o console administrativo do WebSphere Application Server para configurar e ajustar aplicativos, contêineres da Web, contêineres EJB, servidores de aplicativos e nós em seu domínio administrativo.
Como ver a utilização do parâmetro: No UNIX, utilize o comando ps -efl para exibir a prioridade do processo atual.
Para rotear pedidos de servlet do servidor Web para os contêineres da Web, o produto estabelece uma fila de transporte entre o plug-in do servidor Web e cada contêiner da Web.
O Analisador de Recursos mostra uma métrica chamada Porcentagem Máxima utilizada para determinar quanto tempo os threads configurados estão em uso. Se esse valor estiver consistentemente nos dígitos duplos, o contêiner da Web poderá ser um gargalo e o número de threads deverá ser aumentado.
Uma cache com o tamanho solicitado será criada para cada thread. O número de threads é determinado pela definição de tamanho máximo do thread do contêiner da Web.
Nota: Uma cache maior utiliza mais heap Java, portanto, poderá ser necessário aumentar também o tamanho máximo do heap Java. Por exemplo, se cada entrada de cache requerer 2 KB, o tamanho máximo do thread será 25, e o tamanho da cache de chamada de URL será 100, então, serão necessários 5 MB de heap Java.
Utilize o Analisador de Recursos para exibir informações de desempenho do bean.
As informações de segurança relacionadas a beans, permissões e credenciais são armazenadas em cache. Quando o tempo limite de cache for atingido, todas as informações armazenadas em cache serão invalidadas. Pedidos subseqüentes das informações irão resultar em uma procura no banco de dados. Em certas ocasiões, a aquisição das informações requer a invocação de ligações LDAP (Lightweight Directory Access Protocol) ou autenticação nativa, operações que exigem bastante desempenho.
Tente descobrir qual é a melhor configuração para seu aplicativo, com base nos padrões de utilização e necessidades de segurança do site.
As propriedades do sistema a seguir determinam o tamanho inicial das Hashtables da cache principal e secundária, que afeta a freqüência de executar o hash novamente e a distribuição de algoritmos do hash. Quanto maior o número de valores do hash disponíveis, provavelmente ocorrerá menos colisões do hash, e mais provavelmente um tempo de recuperação mais lento. Se várias entradas compõem uma Hashtable da cache, a criação da tabela em uma capacidade maior permite que as entradas sejam inseridas mais eficientemente em vez de permitir que a reexecução automática do hash determine o crescimento da tabela. A reexecução do hash faz com que cada entrada seja movida toda vez que isso for feito.
O recurso SAS (Secure Association Service) estabelecerá uma conexão SSL apenas se for proveniente da JVM (para outra JVM). Portanto, se todos os beans estiverem localizados em uma mesma JVM, o SSL utilizado pelo SAS não deverá impedir o desempenho.
Utilize a guia Serviços e, em seguida, Editar Propriedades do Object Request Broker para o servidor padrão ou qualquer servidor de aplicativos adicional configurado no domínio administrativo, para definir esses parâmetros.
AVISO: Passar por referência pode ser perigoso e pode levar a resultados inesperados. Se uma referência do objeto for modificada pelo método remoto, a alteração poderá ser vista pelo originador da chamada.
Se o servidor de aplicativos esperar uma grande carga de trabalho para os pedidos do bean corporativo, a configuração do ORB será crítica. Observe as seguintes propriedades:
Utilizar o JNIReaders requer menos memória porque um conjunto fixo de threads deve ser criado. Ele economiza tempo porque as criações de threads são feitas apenas durante a inicialização e os threads nunca são destruídos. O JNIReader é uma implementação nativa C e deve ser mais rápida do que o thread da leitora padrão.
AVISO: Certifique-se de que a implementação da biblioteca de JNI do JNIReader esteja no diretório bin do WebSphere Application Server. Para a plataforma Intel, a biblioteca é Selector.dll e para UNIX, é libSelector.a ou libSelector.so. Para Unix, se o prefixo "lib" estiver ausente, o arquivo deverá ser renomeado.
Ajustando a JVM
A JVM oferece vários parâmetros de ajuste que podem afetar o desempenho dos WebSphere Application Servers (que são, principalmente, aplicativos Java), assim como o desempenho de seus próprios aplicativos.
Em geral, o aumento do tamanho do heap Java melhora o rendimento até que o heap não resida mais na memória física. Depois que o heap começa a fazer troca no disco, o desempenho do Java sofre drasticamente. Portanto, o tamanho máximo do heap precisa ser pequeno o suficiente para conter o heap na memória física.
A utilização da memória física deve ser compartilhada entre a JVM e outros aplicativos, como o banco de dados, por exemplo. Por segurança, utilize um heap menor (por exemplo, 64 MB, em máquinas com menos memória).
Tente um heap máximo de 128 MB em uma máquina menor (isto é, menos de 1 GB de memória física), 256 MB para sistemas com 2 GB de memória) e 512 MB para sistemas maiores. O ponto de partida depende do aplicativo.
Se execuções de desempenho estiverem sendo conduzidas e resultados com repetição alta forem necessários, defina os tamanhos inicial e máximo com o mesmo valor. Isso eliminará o crescimento de heap durante a execução. Para sistemas de produção onde o tamanho do conjunto de trabalho dos aplicativos Java não é bem compreendido, uma definição inicial de um quarto da definição máxima é um bom valor de partida. A JVM então irá tentar adaptar o tamanho do heap para o conjunto de trabalho do aplicativo Java.
Utilize a propriedade de linha de comandos do servidor padrão ou qualquer servidor de aplicativos adicional configurado no domínio administrativo para definir as propriedades da JVM:
O WebSphere Application Server é totalmente integrado com um banco de dados suportado de sua escolha. Para obter informações sobre os produtos suportados pelo banco de dados, consulte o site de pré-requisitos do produto na Web no endereço www.ibm.com/software/webservers/appserv/library.html. O WebSphere Application Server utiliza o banco de dados como armazenamento persistente de apoio para administração, bem como para armazenar estados de sessões e dados de beans corporativos para seu aplicativo.
Se seu aplicativo utiliza o estado de sessão do WebSphere Application Server, o conjunto de conexões do banco de dados JDBC ou os beans corporativos, preste muita atenção na configuração desses recursos e suas definições de bancos de dados no domínio administrativo. Durante a instalação do WebSphere Application Server, um banco de dados denominado WASnn é estabelecido, onde nn é o identificador de release, embora seja possível utilizar um nome diferente. Esse documento supõe que o WAS40 é utilizado.
Para escalabilidade, provavelmente você estabeleceu o banco de dados em uma máquina separada, particularmente se estiver utilizando clusters. Isto está relacionado ao banco de dados do WebSphere Application Server, ao banco de dados de qualquer aplicativo e ao banco de dados da sessão do WebSphere Application Server (se a sessão persistente for utilizada).
Se clones forem utilizados, observe que existe um conjunto de origens de dados para cada clone. Isso é importante ao configurar o número máximo de conexões do servidor de banco de dados.
Utilize o Analisador de Recursos para localizar o número mais favorável de conexões do conjunto que pode reduzir valores para esses números. Se a Porcentagem Utilizada for consistentemente baixa, considere a diminuição do número de conexões no conjunto.
Em plataformas UNIX, um processo DB2 separado é criado para cada conexão. Isso afeta rapidamente o desempenho em sistemas com memória baixa, podendo ocorrer erros.
Cada transação de EJB da Entidade requer uma conexão adicional para o banco de dados, especificamente, para tratar da transação. Certifique-se de fazer isso na conta quando calcular o número de conexões da origem de dados. Poderá ocorrer interbloqueio se seu aplicativo requerer mais de uma conexão simultânea por thread e o conjunto de conexões do banco de dados não for grande o suficiente para o número de threads. Suponha que cada um dos threads do aplicativo requeira duas conexões simultâneas com o banco de dados e que o número de threads seja igual ao tamanho máximo do conjunto de conexões. Poderá ocorrer interbloqueio quando as duas situações abaixo forem verdadeiras:
Para evitar o interbloqueio nesse caso, o valor definido para o conjunto de conexões do banco de dados deve ser, no mínimo, uma unidade maior, para que pelo menos um dos threads que estavam aguardando possa concluir sua segunda conexão com o banco de dados, liberando, assim, conexões com o banco de dados.
Para evitar o interbloqueio, codifique o aplicativo a ser utilizado, no máximo, uma conexão por thread. Se o aplicativo for codificado para requerer conexões simultâneas C com o banco de dados por thread, o conjunto de conexões deverá suportar no mínimo o número de conexões a seguir, em que T é o número máximo de threads.
T * (C - 1) + 1
As definições do conjunto de conexões estão diretamente relacionadas ao número de conexões que o servidor de banco de dados está configurado para suportar. Se for aumentado o número máximo de conexões no conjunto e não aumentar as definições correspondentes no banco de dados, o aplicativo falhará e erros de exceção de SQL serão exibidos no arquivo stderr.log.
Nota: As instruções preparadas são otimizadas para tratar de instruções SQL de parâmetros que se beneficiam da pré-compilação. Se o driver JDBC, especificado na origem de dados, suportar pré-compilação, a criação da instrução preparada enviará a instrução para o banco de dados para pré-compilação. Alguns drivers podem não suportar pré-compilação. Neste caso, a instrução poderá não ser enviada para o banco de dados até que a instrução preparada seja executada.
A origem de dados do WebSphere Application Server gerencia um conjunto de conexões de bancos de dados, bem como uma cache associada de objetos de instrução preparada. As instruções preparadas são armazenadas em cache com uma tag que identifica cada conexão que as executa. O relacionamento entre as instruções SQL utilizadas, a cache de instrução preparada, uma origem de dados e um banco de dados é um ponto importante a ser revisto. Suponha que um aplicativo utilize 5 instruções SQL: 2 seleções, 1 exclusão, 1 inserção e 1 atualização.
A origem de dados anterior é configurada com um número máximo de três conexões simultâneas com o banco de dados. As conexões já foram criadas e muitas instruções SQL foram executadas. A cache de instrução preparada foi configurada para conter 10 instruções. Existem três instruções preparadas em cache para as Conexões 1 e 2. A conexão 3 possui quatro instruções em cache. Como as instruções são compiladas em instruções preparadas conforme são utilizadas, a cache de instrução preparada reflete os padrões de utilização do banco de dados do aplicativo. A cache de instrução preparada implementa uma fila do tipo FIFO (primeiro a entrar, primeiro a sair). Um objeto de instrução preparada, representando uma determinada instrução SQL, pode aparecer várias vezes na cache de instrução preparada. Em particular, ele pode aparecer uma vez para cada conexão no conjunto de conexões. Por exemplo, as Instruções 1 e 2 aparecem três vezes, uma para cada conexão. A Instrução 3 não aparece para a Conexão 3 e as Instruções 4 e 5 aparecem apenas para a Conexão 3. Portanto, poderá demorar um pouco mais para executar as Instruções 4 e 5 se elas ocorrerem nas Conexões 1 e 2 devido à necessidade de recompilá-las para essas conexões. Uma alternativa melhor para este exemplo é especificar a cache de instrução preparada de tamanho 15 (5 instruções preparadas para cada uma das três conexões).
O Analisador de Recursos pode ajudar a ajustar essa definição para minimizar descartes da cache. Utilize uma carga de trabalho padrão que representa um número típico de pedidos de clientes de entrada, utilize um número fixo de iterações e utilize um conjunto padrão de definições de configuração.
Siga estas instruções para utilizar o Analisador de Recursos:
O melhor valor para Origem de Dados > Conjunto de Conexões > Tamanho da Cache de Instrução é a definição utilizada para obter um valor zero ou o menor valor para Descartes da Cache do PrepStmt. Isso indica o número mais eficiente para uma carga de trabalho típica.
Outros parâmetros JDBC
Além de definir o tamanho da cache de instrução preparada, você pode definir
outras propriedades específicas dos drivers JDBC. Por exemplo, utilizando o Oracle, você
pode aumentar o número de linhas a serem buscadas enquanto obtém conjuntos de resultados com a seguinte instrução:
name="defaultRowPrefetch", value="25"
Digite esses tipos de propriedades personalizadas na guia Geral do banco de dados.
Para definir BUFFPAGE como um valor n, emita o comando do DB2 update db cfg for x using BUFFPAGE n e certifique-se de que NPAGES seja -1 como segue:
db2 <-- vá para o modo de comando do DB2, do contrário, o "select" a seguir não funcionará no estado em que se encontra
connect to x <-- (onde x é o nome do banco de dados DB2 específico)
select * from syscat.bufferpools
(e anote o nome do padrão, talvez: IBMDEFAULTBP)
(se NPAGES já for -1, você está correto e não será necessário emitir o comando a seguir)
alter bufferpool IBMDEFAULTBP size -1
(emita novamente o "select" acima e NPAGES agora deve
ser -1)
Um nível de otimização de 9 faz com que o DB2 coloque um grande período de tempo e todas as suas estatísticas disponíveis para a otimização do plano de acesso.
Para obter mais informações, consulte a documentação do DB2 e o site na Web IBM DB2.
Para certificar de que runstats foi executado, emita o seguinte comando no CLP do DB2:
db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes"
Se nenhum runstats foi executado, nleaf e nlevels serão preenchidos com -1 e stats_time terá uma entrada vazia "-".
Se runstats ainda não foi executado, a marca de tempo real quando o runstats foi concluído também será exibida em stats_time. Se você achar que o tempo mostrado para o runstats anterior é muito antigo, execute o runstats novamente.
A nova definição se efetiva imediatamente.
A seguir encontram-se várias métricas que estão relacionadas ao MinCommit do DB2:
Para obter informações adicionais sobre a definição dos parâmetros de gerenciamento de sessão, consulte o artigo InfoCenter 4.4.1.1 Modelo e ambiente de programação da sessão.
A utilização desse parâmetro pode ser vista através da ativação do rastreamento no componente cmm.
Um valor 1 deverá ser utilizado, se você desejar processar mensagens em série, isto é, apenas uma instância do bean da mensagem é utilizada para processar mensagens uma após a outra.
Um valor 20 fornecerá o melhor rendimento. Aumentar além desse valor não aumentará o rendimento. Com base no tipo de mensagem, na quantidade de trabalho e nos recursos disponíveis, um valor entre 10 e 20 deve ser utilizado para obtenção do rendimento máximo da mensagem.
O aumento no rendimento da mensagem depende de vários fatores tais como recursos do sistema e configuração do atendente. Os recursos do sistema se referem ao número e o poder dos processadores. A configuração do atendente é o número de sessões utilizadas e as interações do JMS. Incluído nas interações de JMS encontra-se a contenção no compartilhamento do acesso a recursos fundamentais do MQ Server Manager.
Siga estas etapas:
No menu Iniciar, escolha Programas > Ferramentas Administrativas > Monitor de Desempenho