![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Diretrizes de Ajuste do Agente de Pedido de Objetos
Utilize as orientações deste documento sempre que o ORB (Object Request Broker) for utilizado em uma carga de trabalho.
O ORB é utilizado sempre que beans corporativos são acessados através de uma interface remota. Se você tiver um consumo de CPU especialmente alto ou baixo, você pode ter um problema com o valor de um dos seguintes parâmetros. Examine estes parâmetros de ajuste principais para toda implementação de aplicativo.
Ajustes do Conjunto de Encadeamentos
Size
Ajuste o tamanho do conjunto de encadeamentos do ORB de acordo com sua carga de trabalho. Evite suspender encadeamentos por não terem nenhum trabalho pronto para processar. Se os encadeamentos não tiverem trabalho pronto para processar, o tempo de CPU será consumido chamando-se o método Object.wait, executando uma comutação de contexto. Ajuste o tamanho do conjunto de encadeamentos de forma que a duração de tempo que os encadeamentos aguardam seja curta o suficiente para evitar que sejam eliminados por estarem inativos por muito tempo.
O tamanho do conjunto de encadeamentos depende de sua carga de trabalho e do sistema. Nas configurações comuns, os aplicativos precisam de 10 ou menos encadeamentos por processador.
No entanto, se seu aplicativo estiver executando um pedido de backend muito lento, como um pedido para um sistema de banco de dados, um encadeamento do servidor é bloqueado, aguardando a conclusão do pedido de backend. Com pedidos de backend, a utilização da CPU é bastante lenta. Nesse caso, aumentar a carga não aumenta a utilização nem o rendimento do processamento da CPU. Os dumps de encadeamentos indicam que praticamente todos os encadeamentos estão em uma chamada ao recurso de backend. Nesse caso, considere aumentar o número de encadeamentos por processador até o rendimento do processamento melhorar e os dumps de encadeamentos mostrarem que os encadeamentos estão em outras áreas do tempo de execução além da chamada de backend. Você deve ajustar o número de encadeamentos somente se seu recurso de backend estiver ajustado corretamente.
O parâmetro Permitir Alocação de Encadeamento Além do Tamanho Máximo de Encadeamento também afeta o tamanho do conjunto de encadeamentos, mas não utilize esse parâmetro a menos que seu backend pare por longos períodos de tempo, causando o bloqueamento de todos os encadeamentos do tempo de execução que estão aguardando o sistema de backend em vez de processando outros trabalhos que não envolvam o sistema de backend.
Você pode ajustar as configurações do tamanho do conjunto de encadeamentos no console administrativo. Clique em Servidores > Tipos de Servidor > Servidores de Aplicativos >server_name > Serviços do Contêiner > Serviço de ORB > Conjunto de Encadeamentos. É possível ajustar o número mínimo e máximo de encadeamentos.
Tempo Limite do Conjunto de Encadeamentos
Cada pedido de entrada e de saída através do ORB requer um encadeamento do conjunto de encadeamentos do ORB. Em cenários de carga pesada ou em cenários em que pedidos de ORB se aninham profundamente, é possível para uma Java™ Virtual Machine (JVM) ter todos os encadeamentos do conjunto de encadeamentos do ORB tentando enviar pedidos. Enquanto isso, o ORB da JVM remota que processa esses pedidos tem todos os encadeamentos de seu conjunto de encadeamentos do ORB tentando enviar pedidos. Como resultado, nunca é feito progresso, encadeamentos não são liberados de volta para o conjunto de encadeamentos do ORB e o ORB não pode processar pedidos. Como resultado, há um conflito potencial. Utilizando o console administrativo, é possível ajustar esse comportamento através da propriedade customizada com.ibm.websphere.orb.threadPoolTimeout do ORB. Para obter informações adicionais, consulte a documentação sobre as propriedades customizadas do Object Request Broker.
Tamanho do Fragmento
O ORB separa mensagens em fragmentos para enviar através da conexão ORB. É possível configurar esse tamanho de fragmento por meio do parâmetro com.ibm.CORBA.FragmentSize.
- No console administrativo, ative o rastreio de ORB na página de Propriedades do ORB.
- Ative o rastreio ORBRas a partir da página de log e de rastreio.
- Aumente os tamanhos do arquivo de rastreio porque o rastreio pode gerar muitos dados.
- Reinicie o servidor e execute pelo menos uma iteração (preferivelmente várias) do caso que você está medindo.
- Consulte o arquivo de rastreio e faça uma pesquisa de Fragmento
a Ser Seguido: Sim.
Esta mensagem indica que o ORB transmitiu um fragmento, mas ele ainda possui pelo menos um fragmento restante para enviar antes de a mensagem inteira chegar. Um valor Fragmento a Ser Seguido: Não indica que o fragmento específico é o último na mensagem inteira. Esse fragmento também pode ser o primeiro, se a mensagem se encaixar inteiramente em um fragmento.
Se você for ao ponto em que Fragmento a Ser Seguido: Sim é localizado, localizará um bloco semelhante ao seguinte exemplo:
Fragmento a Ser Seguido: Sim Tamanho da Mensagem: 4988 (0x137C) -- ID da Solicitação: 1411
Esse exemplo indica que a quantidade de dados no fragmento é 4988 bytes e o ID do Pedido é 1411. Se você procurar todas as ocorrências de ID do Pedido: 1411, poderá ver o número de fragmentos utilizados para enviar a mensagem específica. Se você incluir todos os tamanhos de mensagens associados, terá o tamanho total da mensagem que está sendo enviada através do ORB.
- É possível configurar o tamanho de fragmento definindo a propriedade customizada ORB com.ibm.CORBA.FragmentSize.
Interceptores
Os interceptores são extensões do ORB que podem configurar o contexto antes de o ORB executar uma solicitação. Por exemplo, o contexto pode incluir transações ou sessões de atividade a importar. Se o cliente criar uma transação e, em seguida, fluir o contexto da transação para o servidor, o servidor importará o contexto da transação para o pedido do servidor através dos interceptores.
A maioria dos clientes não inicia transações nem sessões de atividades, portanto, a maioria dos sistemas pode beneficiar-se da remoção de interceptores que não são necessários.
Para remover os interceptores, edite manualmente o arquivo server.xml e remova as linhas do interceptor que não são necessárias na seção do ORB.
Ajustes do Cache de Conexão
Dependendo da carga de trabalho de um servidor de aplicativos, e dos requisitos de rendimento do processamento ou do tempo de resposta, poderá ser necessário ajustar o tamanho do cache de conexão do ORB. Cada entrada no cache de conexão é um objeto que representa um nó de extremidade de soquete TCP/IP distinto, identificado pelo nome do host ou endereço TCP/IP e o número da porta utilizada pelo ORB para enviar um pedido GIOP ou uma resposta GIOP para o nó de extremidade de destino remoto. A finalidade do cache de conexão é reduzir o tempo requerido para estabelecer uma conexão reutilizando objetos de conexão do ORB para pedidos ou respostas subsequentes. (O mesmo soquete TCP/IP é utilizado para o pedido e resposta correspondente).
Para cada servidor de aplicativos, o número de entradas no cache de conexão está diretamente relacionado ao número de conexões de ORB simultâneas. Estas conexões consistem em pedidos de entrada feitos a partir de clientes remotos e de pedidos de saída feitos pelo servidor de aplicativos. Quando o ORB do lado do servidor recebe um pedido de conexão, ele utiliza uma conexão existente de uma entrada no cache, ou estabelece uma nova conexão e inclui uma entrada para essa conexão no cache.
As propriedades Máximo de caches de conexão de ORB e Mínimo de caches de conexão são utilizadas para controlar os números máximo e mínimo de entradas no cache de conexão em um período especificado. Quando o número de entradas atingir o valor especificado para a propriedade Máximo de caches de conexão e for requerida uma nova conexão, o ORB criará a conexão solicitada, incluirá uma entrada no cache e procurará e tentará remover até cinco entradas de conexão inativas do cache. Como a nova conexão é incluída antes de as entradas inativas serem removidas, é possível para o número de entradas de cache exceder temporariamente o valor especificado para a propriedade Máximo de Cache de Conexão.
Uma conexão de ORB é considerada inativa se o fluxo de soquete TCP/IP não estiver sendo utilizado e se não existirem respostas GIOP pendentes para pedidos feitos nessa conexão. Conforme a carga de trabalho do aplicativo é reduzida, o ORB fecha as conexões e remove as entradas para estas conexões do cache. O ORB continua removendo entradas do cache até o número de entradas restantes estar no valor especificado para a propriedade Máximo de Cache de Conexão ou abaixo dele. O número de entradas de cache nunca é menor do que o valor especificado para a propriedade Mínimo de caches de conexão, que deve ser pelo menos cinco conexões a menos que o valor especificado para a propriedade Máximo de caches de conexão.
Geralmente, não são necessários ajustes no cache de conexão no ORB do lado cliente, porque é feito apenas um pequeno número de conexões nesse lado.
Encadeamentos da Leitora JNI
Por padrão, ORB utiliza um encadeamento Java para processar cada pedido de conexão de entrada recebido. Conforme aumenta o número de pedidos simultâneos, o armazenamento consumido por um grande número de encadeamentos da leitora aumenta e pode se tornar um gargalo em ambientes de recursos limitados. Eventualmente, o número de encadeamentos Java criados poderá causar exceções de falta de memória, se o número de pedidos simultâneos exceder os recursos disponíveis no sistema.
Para ajudar a resolver esse problema em potencial, você poderá configurar um ORB para utilizar encadeamentos leitores JNI onde um número de encadeamentos leitores, implementados utilizando encadeamentos nativos do S.O. em vez de encadeamentos Java, são criados durante a inicialização de ORB. Os encadeamentos da leitora JNI dependem do mecanismo assíncrono de TCP/IP do S.O. que permite que um único encadeamento de S.O. nativo manipule eventos de E/S a partir de vários soquetes ao mesmo tempo. O ORB gerencia a utilização dos encadeamentos da leitora JNI e designa um dos encadeamentos disponíveis para manipular o pedido de conexão, utilizando um algoritmo de rodízio. Normalmente, os encadeamentos de leitores JNI devem ser configurados apenas quando o uso dos encadeamentos Java exigir muita memória para seu ambiente de aplicativo.
- Como é alocado um número fixo de encadeamentos, o uso da memória é reduzido. Esta redução fornece um benefício significativo em ambientes que geralmente não possuem cargas de trabalho de pedidos de cliente grandes e sustentadas.
- O tempo necessário para criar e destruir de forma dinâmica os encadeamentos Java é eliminado, pois um número fixo de encadeamentos JNI é criado e alocado durante a inicialização de ORB.
- Cada encadeamento JNI pode manipular até 1024 conexões de soquete e interagir diretamente com o mecanismo de S.O. nativo de E/S assíncrona, que pode fornecer desempenho aperfeiçoado de processamento de E/S da rede.