Resolução de Problemas do Servidor Proxy
Este tópico ajuda a resolver problemas que você possa encontrar com seu servidor proxy.
Sobre Esta Tarefa
Os erros do servidor proxy são registrados
no joblog. Consulte a lista a seguir se estiver enfrentando problemas
com o servidor proxy.
Os erros do servidor proxy são registrados no
arquivos SystemOut.log, proxy.log ou local.log. Consulte a lista a
seguir se estiver tendo problemas com o servidor proxy.
Procedimento
- O servidor proxy foi criado com êxito, mas não consigo
iniciá-lo. Verifique se há conflitos de porta no arquivo SYSOUT. Use o comando netstat –a para consultar se algum dos terminais associados ao servidor proxy já está sendo usado. É possível localizar as portas no console administrativo clicando em > Servidores > Servidores proxy > <server_name> > Portas.Se o início do servidor proxy falhar ao tentar iniciá-lo como um usuário não privilegiado nos sistemas UNIX, verifique a seguinte mensagem nos logs:
Altere as portas das cadeias de transporte PROXY_HTTP_ADDRESS e PROXY_HTTPS_ADDRESS para valores superiores a 1024.ChannelFramew E CHFW0029E: Erro ao inicializar a cadeia HTTPS_PROXY_CHAIN, por causa da Exceção com.ibm.wsspi.channel.framework.exception.RetryableChannelException: Permissão negada TCPPort E TCPC0003E: Falha na inicialização do Canal TCP TCP_7. Falha de ligação do soquete para o host * e porta 80. A porta já pode estar sendo utilizada.
- O servidor proxy roteia solicitações para o contêiner da Web usando uma porta de administração. Ele está localizado na frente de vários contêineres de Web. A configuração requer que os contêineres de Web atendam nas portas não padrão, como 9061,
9081, etc. Esse cenário é o caso padrão quando vários servidores de aplicativos estão na mesma máquina, o que força portas novas e diferentes a serem utilizadas na configuração. Neste cenário, o servidor proxy pode rotear uma solicitação de aplicativo para o contêiner da Web usando a porta de administração 9061, em vez de usar a porta 9081 esperada.
Inclua os números de porta de atendimento do contêiner da Web no host virtual que está associado ao aplicativo de destino. Esse processo garantirá que o servidor proxy roteie as solicitações para o contêiner da Web usando o número de porta correto.
- O servidor proxy foi iniciado, mas não consigo acessar os recursos de aplicativo por meio dos terminais do servidor proxy. Certifique-se de que os nós de extremidade do servidor proxy estejam entre os aliases do host no host virtual associados ao aplicativo.
- O servidor proxy é encaminhado para outro grupo principal. Verifique se as pontes do grupo principal existem entre os grupos principais da célula e se os processos escolhidos para funcionarem como pontes foram reiniciados. Se houver um firewall entre o grupo principal, verifique se as portas corretas estão abertas para o tráfego da ponte do grupo principal.
- O servidor proxy é capaz de rotear pedidos para outra célula. Reveja
as configurações de ponte do grupo principal. Se a mensagem de erro HMGR0149E for registrada em qualquer servidor, geralmente em um servidor que atua como uma ponte do grupo principal, as configurações de segurança para a célula precisarão ser modificadas para permitir a comunicação.
Consulte o tópico intitulado Exportando as Chaves LTPA (Lightweight Third Party Authentication) para obter mais informações sobre como configurar a segurança da célula entre várias células.
- Recebendo uma Página em Branco ao Fazer um Pedido para o Proxy. Considere as seguintes ações:
- Atualize o host virtual. Certifique-se de que o aplicativo de destino e a regra de roteamento estejam designadas a um host virtual que inclua as portas de atendimento do servidor proxy (padrão: HTTP 80, HTTPS 443). Inclua as portas de atendimento do servidor proxy no aplicativo ou no host virtual da regra roteamento, ou utilize o host virtual proxy_host.
- Pare o processo em conflito. Verifique seu sistema para assegurar que nenhum outro
processo (por exemplo, Apache, IBM HTTP Server e assim por diante) que utiliza
as portas do servidor proxy (padrão: HTTP 80, HTTPS 443) esteja em execução. Se esse problema
ocorrer, o servidor proxy parecerá ser iniciado normalmente, mas não poderá receber
pedidos na porta de atendimento afetada. Verifique o sistema, conforme a seguir:
- Pare o servidor proxy.
- Consulte seu sistema, utilizando os comandos netstat e ps, para determinar se um processo prejudicial está utilizando a porta em que o servidor proxy está atendendo.
- Se for encontrado um processo prejudicial, pare o processo e configure o sistema para que o processo não seja iniciado durante a inicialização do sistema.
- Ative o roteamento do proxy. Verifique se o roteamento do proxy está ativado para o módulo da Web do aplicativo. O roteamento do proxy está ativado por padrão, portanto, se nenhuma propriedade do proxy for modificada, desconsidere essa solução. Caso contrário, consulte Customizando Roteamento para Aplicativos para obter instruções sobre a modificação das propriedades do proxy.
- Teste o pedido direto. Para se certificar se de que o aplicativo de destino esteja instalado, faça um pedido diretamente para o servidor de aplicativos. Se uma resposta não for recebida, então o problema será com o servidor de aplicativos, e não com o servidor proxy. Verifique isso, indo para o servidor proxy depois de receber uma resposta diretamente do servidor de aplicativos.
- HTTP 404 (Arquivo não encontrado) erro recebido do servidor proxy. Considere as seguintes ações:
- Atualize o host virtual. Certifique-se de que o aplicativo de destino e a regra de roteamento estejam designadas a um host virtual que inclua as portas de atendimento do servidor proxy (padrão: HTTP 80, HTTPS 443). Inclua as portas de atendimento do servidor proxy no aplicativo ou no host virtual da regra roteamento, ou utilize o host virtual proxy_host.
- Ative o roteamento do proxy. Verifique se o roteamento do proxy está ativado para o módulo da Web do aplicativo. O roteamento do proxy está ativado por padrão, portanto, se nenhuma propriedade do proxy for modificada, desconsidere essa solução. Caso contrário, consulte Customizando Roteamento para Aplicativos para obter instruções sobre a modificação das propriedades do proxy.
- Teste o pedido direto. Para se certificar se de que o aplicativo de destino esteja instalado, faça um pedido diretamente para o servidor de aplicativos. Se uma resposta não for recebida, então o problema será com o servidor de aplicativos, e não com o servidor proxy. Verifique isso, indo para o servidor proxy depois de receber uma resposta diretamente do servidor de aplicativos.
- Não foi possível fazer pedidos de SSL (Secure Sockets Layer) para o aplicativo ou regra de roteamento. Certifique-se de que o host virtual do aplicativo ou regra de roteamento inclua um alias do host para a porta SSL do servidor proxy (padrão: 443).
- Não foi possível se conectar ao servidor proxy...o pedido atingiu o tempo limite. Pare o processo em conflito. Verifique seu sistema para assegurar que nenhum outro
processo (por exemplo, Apache, IBM HTTP Server e assim por diante) que utiliza
as portas do servidor proxy (padrão: HTTP 80, HTTPS 443) esteja em execução. Se essa situação
ocorrer, o servidor proxy parecerá ser iniciado normalmente, mas não poderá receber
pedidos na porta de atendimento afetada. Verifique o sistema, conforme a seguir:
- Pare o servidor proxy.
- Consulte seu sistema, utilizando os netstat e ps para determinar se um processo prejudicial está utilizando a porta em que o servidor proxy está atendendo.
- Se for encontrado um processo prejudicial, pare o processo e configure o sistema para que o processo não seja iniciado durante a inicialização do sistema.
- Não foi recebida uma resposta do aplicativo da página de erro quando o erro HTTP ocorreu (por exemplo, 404). Certifique-se de que o URI da página de erro seja digitado corretamente. Além disso, certifique-se de que a opção Manipular erros remotos esteja selecionada se você estiver manipulando respostas de erro HTTP dos servidores de backend. Para obter informações mais detalhadas, consulte Visão Geral da política de Página de Erro Customizada e a seção de política da página de erro customizada de Definições de servidor proxy.
- Quais Pacotes Posso Ativar ao Rastrear o Servidor Proxy? Todos os pacotes a seguir não são necessários para cada rastreio, mas, se
não tiver certeza, utilize todos eles:
- *=info
- WebSphere Proxy=all
- GenericBNF=all
- HAManager=all
- HTTPChannel=all
- TCPChannel=all
- WLM*=all
- DCS=all
- ChannelFrameworkService=all
- com.ibm.ws.dwlm.*=all
- com.ibm.ws.odc.*=all
- Como Posso Ativar/Desativar a Carga de SSL? Ativar/desativar carga de SSL é referido como o protocolo de transporte no console administrativo e o protocolo de transporte é uma propriedade do módulo da Web. Consulte Customizando Roteamento para Aplicativos para ver como configurar as propriedades do módulo da Web. Nenhuma propriedade de ativação/desativação de carga de SSL ou do protocolo de transporte existe para as regras de roteamento, porque o protocolo de transporte é herdado para o cluster do servidor genérico especificado na regra de roteamento.
- Quando solicitado pelo IBM HTTP Server ou por um plug-in de servidor da Web, como eu configuro o servidor proxy para que não seja necessário incluir uma porta para ele no host virtual? Para que o servidor proxy confie nas informações relacionadas à segurança que são incluídas em um pedido, como cabeçalhos privados incluídos pelo produto, inclua o originador do pedido na lista de proxies de segurança confiável do servidor proxy. Por exemplo, inclua um IBM HTTP Server ou um plug-in de servidor da Web que envie solicitações para o servidor proxy, para a lista de proxies de segurança confiável do servidor proxy. O plug-in do servidor da Web pode então enviar informações de cabeçalho privado incluídas no produto que contêm as informações de host virtual de uma solicitação. Se o proxy não confiar nesses cabeçalhos privados do plug-in de servidor da Web ou de qualquer cliente, o servidor proxy incluirá seus próprios cabeçalhos privados, o que exigirá a inclusão de portas HTTP e HTTPS do servidor proxy para o host virtual. Geralmente, quando um plug-in de servidor da Web é usado com o servidor proxy, a intenção é usar o servidor proxy como um servidor de backend. Portanto, inclua o plug-in como proxy de segurança confiável para evitar ter de expor as portas do servidor proxy. Roteando Pedidos de um Plug-in para um Servidor Proxy fornece mais informações sobre como configurar um plug-in de servidor da Web para usar com o servidor proxy. Definições de servidor proxy fornece mais informações sobre a configuração de proxies de segurança confiáveis.
- O servidor proxy parece interrompido quando sobrecarregado, ou exceções
Muitos Arquivos Abertos são exibidas em ffdc ou em SystemErr.log. Com
altas cargas de conexão, o número de descritores do sistema de arquivo pode esgotar-se e
o servidor proxy pode parecer interromper e descartar Muitas Exceções Abertas de Arquivos no
diretório ffdc ou no arquivo SystemError.log, porque não pode abrir um soquete.
Para atenuar este problema, modifique um ou mais dos seguintes parâmetros
no nível do sistema operacional e no nível do servidor proxy para otimizar
o uso de conexões para o servidor proxy:
Ajuste de Sistema Operacional para Windows 2003 e XP
- TcpTimedWaitDelay - Determina o tempo que deve decorrer antes que o TCP/IP
libere uma conexão fechada e possa reutilizar seus recursos. Esse intervalo entre o
fechamento e a liberação é conhecido como o estado TIME_WAIT ou o dobro do estado de duração máxima do segmento (2MSL). Durante esse tempo, a reabertura da conexão com o cliente e com o servidor
custa menos que estabelecer uma nova conexão. Reduzindo o valor dessa entrada,
o TCP/IP libera conexões fechadas mais rapidamente e fornecer mais
recursos para novas conexões. Ajuste este parâmetro se o aplicativo em execução
exigir liberação rápida, a criação de novas conexões ou um ajuste, devido
a um baixo rendimento do processamento causado por várias conexões no
estado TIME_WAIT. Visualize ou defina essa valor da seguinte forma:
- Utilize o comando regedit e acesse a subchave do registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters para criar um novo valor REG_DWORD chamado TcpTimedWaitDelay.
- Defina o valor como 30 decimal, o qual é Hex 0x0000001e. Esse valor define o tempo de espera para 30 segundos.
- Pare e reinicie o sistema.
Informações Valor Valor padrão 0xF0, que define o tempo de espera como 240 segundos (4 minutos). Valor Recomendado Um valor mínimo de 0x1E, que define o tempo de espera como 30 segundos. - MaxUserPort - Determina o número de porta mais alto que o TCP/IP pode
designar quando um aplicativo solicita uma porta do usuário disponível no sistema. Visualize ou defina essa valor da seguinte forma:
- Utilize o comando regedit, acesse a subchave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters registry e crie um novo valor REG_DWORD chamado MaxUserPort.
- Defina esse valor como pelo menos decimal 32768.
- Pare e reinicie o sistema.
Informações Valor Valor Padrão Nenhuma Valor Recomendado Pelo menos decimal 32768.
- TcpTimedWaitDelay - Determina o tempo que deve decorrer antes que o TCP/IP
libere uma conexão fechada e possa reutilizar seus recursos. Esse intervalo entre o
fechamento e a liberação é conhecido como o estado TIME_WAIT ou o dobro do estado de duração máxima do segmento (2MSL). Durante esse tempo, a reabertura da conexão com o cliente e com o servidor
custa menos que estabelecer uma nova conexão. Reduzindo o valor dessa entrada,
o TCP/IP libera conexões fechadas mais rapidamente e fornecer mais
recursos para novas conexões. Ajuste este parâmetro se o aplicativo em execução
exigir liberação rápida, a criação de novas conexões ou um ajuste, devido
a um baixo rendimento do processamento causado por várias conexões no
estado TIME_WAIT.
Ajuste do sistema operacional para Linux
- timeout_timewait parameter - Determina o tempo que deve decorrer antes que o TCP/IP
libere uma conexão fechada e possa reutilizar seus recursos.
Esse intervalo entre o
fechamento e a liberação é conhecido como o estado TIME_WAIT ou o dobro do estado de duração máxima do segmento (2MSL). Durante esse tempo, a reabertura da conexão com o cliente e com o servidor
custa menos que estabelecer uma nova conexão. Reduzindo o valor desta entrada,
o TCP/IP pode liberar conexões fechadas mais rapidamente, fornecendo mais
recursos para novas conexões. Ajuste este parâmetro se o aplicativo em execução exigir
liberação rápida, a criação de novas conexões e um baixo rendimento do processamento
devido a muitas conexões estarem aguardando no estado TIME_WAIT. Para visualizar ou definir esse valor, emita o seguinte comando para definir o parâmetro de espera do tempo limite como 30 segundos:
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
- Descritores de arquivo Linux
(ulimit) - Especifica o número de arquivos abertos que são suportados.
A definição
padrão em geral é suficiente para a maioria dos aplicativos.
Se o valor definido para esse parâmetro for muito baixo, um erro de abertura do arquivo, uma falha de alocação de memória ou um erro de estabelecimento de conexão pode ser exibido.
Visualize ou configure este valor verificando as páginas de referência do UNIX no comando ulimit para a sintaxe de shells diferentes. Para definir o comando ulimit como 65535 para a shell KornShell (ksh), emita o comando ulimit -n 65535. Utilize o comando ulimit -a para exibir os valores atuais de todas as limitações dos recursos do sistema.
Informações Valor Valor Padrão 1024 Valor Recomendado 65535
- timeout_timewait parameter - Determina o tempo que deve decorrer antes que o TCP/IP
libere uma conexão fechada e possa reutilizar seus recursos.
Esse intervalo entre o
fechamento e a liberação é conhecido como o estado TIME_WAIT ou o dobro do estado de duração máxima do segmento (2MSL). Durante esse tempo, a reabertura da conexão com o cliente e com o servidor
custa menos que estabelecer uma nova conexão. Reduzindo o valor desta entrada,
o TCP/IP pode liberar conexões fechadas mais rapidamente, fornecendo mais
recursos para novas conexões. Ajuste este parâmetro se o aplicativo em execução exigir
liberação rápida, a criação de novas conexões e um baixo rendimento do processamento
devido a muitas conexões estarem aguardando no estado TIME_WAIT. Para visualizar ou definir esse valor, emita o seguinte comando para definir o parâmetro de espera do tempo limite como 30 segundos:
Ajuste do sistema operacional para AIX
- TCP_TIMEWAIT - Determina o tempo que deve decorrer antes que o TCP/IP
libere uma conexão fechada e possa reutilizar seus recursos. Esse intervalo entre o
fechamento e a liberação é conhecido como o estado TIME_WAIT ou o dobro do estado de duração máxima do segmento (2MSL). Durante esse tempo, a reabertura da conexão com o cliente e com o servidor
custa menos que estabelecer uma nova conexão. Reduzindo o valor desta entrada,
o TCP/IP pode liberar conexões fechadas mais rapidamente, fornecendo mais
recursos para novas conexões. Ajuste este parâmetro, se o aplicativo em execução
exigir liberação rápida ou a criação de novas conexões, ou se ocorrer um baixo
rendimento do processamento devido a muitas conexões estarem aguardando no estado TIME_WAIT. Para visualizar ou definir esse valor, emita o seguinte comando para definir o estado TCP_TIMEWAIT como 15 segundos:
/usr/sbin/no -o tcp_timewait =1
- Descritores de arquivo AIX
(ulimit) - Especifica o número de arquivos abertos que são permitidos. A definição
padrão em geral é suficiente para a maioria dos aplicativos. Se o valor
definido para este parâmetro for muito baixo, poderão ocorrer erros ao abrir arquivos
ou ao estabelecer conexões, e um erro de estabelecimento de conexão pode ser exibido. Para impedir que o WebSphere Application Server fique com poucos recursos, remova os limites (ulimit) para os recursos na conta do usuário na qual o processo do
WebSphere Application Server é executado.Para visualizar ou definir esse valor, altere as configurações de ulimit conforme a seguir:
- Abra a janela de comandos.
- Digite Usuários do smitty para abrir o programa de configuração do AIX.
- Selecione Alterar ou Mostrar Características de um usuário.
- Digite o nome da conta de usuário na qual o WebSphere Application Server é executado.
- Pressione Enter.
- Altere as seguintes definições para o valor indicado:
Informações Valor Tamanho de ARQUIVO Flexível -1 Tempo de CPU Flexível -1 Tamanho de PILHA Flexível -1 Tamanho do Arquivo PRINCIPAL Flexível -1 Tamanho de ARQUIVO Rígido -1 Tempo de CPU Rígido -1 Tamanho de PILHA Rígido -1 Tamanho do Arquivo PRINCIPAL Rígido -1 - Pressione Enter para salvar as alterações.
- Efetue logout e login em sua conta.
- Reinicie o produto.
Informações Valor Valor padrão 2000 Valor Recomendado sem limite
- TCP_TIMEWAIT - Determina o tempo que deve decorrer antes que o TCP/IP
libere uma conexão fechada e possa reutilizar seus recursos. Esse intervalo entre o
fechamento e a liberação é conhecido como o estado TIME_WAIT ou o dobro do estado de duração máxima do segmento (2MSL). Durante esse tempo, a reabertura da conexão com o cliente e com o servidor
custa menos que estabelecer uma nova conexão. Reduzindo o valor desta entrada,
o TCP/IP pode liberar conexões fechadas mais rapidamente, fornecendo mais
recursos para novas conexões. Ajuste este parâmetro, se o aplicativo em execução
exigir liberação rápida ou a criação de novas conexões, ou se ocorrer um baixo
rendimento do processamento devido a muitas conexões estarem aguardando no estado TIME_WAIT. Para visualizar ou definir esse valor, emita o seguinte comando para definir o estado TCP_TIMEWAIT como 15 segundos:
Ajuste do sistema operacional para HP-UX
Parâmetro do kernel nfile do HP-UX - Especifica o número máximo de arquivos que podem ser abertos no sistema a qualquer momento. A não especificação de um número alto o suficiente pode restringir a capacidade de processamento de seu sistema.
Parâmetro do kernel ninode do HP-UX - Especifica o número máximo de inodes abertos que podem estar na memória. Um inode aberto está associado a cada arquivo aberto exclusivo. Portanto, o valor especificado para o parâmetro ninode deve ser maior do que o número de arquivos exclusivos que devem estar abertos ao mesmo tempo.
Ajuste do Sistema Operacional para o Solaris
- Descritores de arquivo do Solaris (ulimit) - Especifica o número de arquivos
abertos suportados. Se o valor especificado para este parâmetro for muito baixo,
poderá ser exibido um erro de abertura de arquivo, uma falha de alocação de memória ou
um erro de estabelecimento de conexão. Visualize ou configure este
valor verificando as páginas de referência do UNIX no comando ulimit para a sintaxe
de shells diferentes.
- Emita o comando ulimit -a para exibir os valores atuais para todas as limitações em recursos do sistema.
- Emita o comando ulimit -n 65535 para configurar o comando ulimit como 65535 para o shell KornShell (ksh).
- O número máximo de arquivos que podem ser abertos para um processo também é afetado pelas configurações de rlim_fd_max e rlim_fd_cur do limite de kernel global. Pode ser necessário aumentar os valores destas configurações no arquivo /etc/system.
O Solaris 10 fornece um novo mecanismo para configurar parâmetros do kernel. Emita um dos seguintes comandos para especificar um novo limite para o número máximo de parâmetros do kernel do descritor de arquivo no Solaris 10:- Para alterar o valor para a sessão shell atual:
prctl -n process.max-file-descriptor -r -v 65535 $$
- Para tornar a mudança uma mudança em todo o sistema:
projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)' sistema
É necessário ter cuidado ao emitir este comando, porque ele altera a configuração para todos os usuários e todos os projetos.
- Para alterar o valor para todos os projetos pertencentes ao usuário root:
projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)' user.root
- Para alterar o valor de todos os projetos de propriedade do usuário não raiz
projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)' user.username
- TCP_TIME_WAIT_INTERVAL - Notifica o TCP/IP quanto tempo manter os blocos de controle de conexão fechados. Depois que os aplicativos concluem a conexão TCP/IP, os blocos de
controle são mantidos pelo tempo especificado. Quando ocorrem altas taxas de
conexão, um grande número de conexões TCP/IP se acumula e pode tornar mais lento o desempenho do
servidor. O servidor pode parar durante determinados períodos de pico. Se o servidor
ficar lento, o comando netstat mostrará que muitos dos soquetes abertos
para o servidor HTTP estão no estado CLOSE_WAIT ou FIN_WAIT_2. Retardos visíveis
podem ocorrer por até quatro minutos e, durante esse tempo, o servidor não envia
nenhuma resposta, mas a utilização da CPU permanece alta, com todas as atividades
em processos do sistema. Para visualizar ou definir esse valor, altere o comando get para determinar o intervalo atual e defina o comando para especificar um intervalo de 30 segundos. Por exemplo:
ndd -get /dev/tcp tcp_time_wait_interval ndd -set /dev/tcp tcp_time_wait_interval 30000
Informações Valor Valor padrão 240000 milissegundos, que é igual a 4 minutos. Valor Recomendado 60000 milissegundos
- Descritores de arquivo do Solaris (ulimit) - Especifica o número de arquivos
abertos suportados. Se o valor especificado para este parâmetro for muito baixo,
poderá ser exibido um erro de abertura de arquivo, uma falha de alocação de memória ou
um erro de estabelecimento de conexão. Visualize ou configure este
valor verificando as páginas de referência do UNIX no comando ulimit para a sintaxe
de shells diferentes.
- Ajuste do Servidor Proxy
- Pedidos Persistentes - Um pedido persistente é um enviado em uma
conexão TCP existente. Para maximizar o desempenho, aumente o número de
pedidos recebidos em uma conexão TCP de um cliente. O valor deve representar o número máximo de objetos integrados, por exemplo, GIF, etc, em uma página da Web +1.
Visualize ou configure este valor no console administrativo do WebSphere Application Server clicando em Servidores > Servidores Proxy > server_name > Transportes de Servidor Proxy > HTTP_PROXY_CHAIN/HTTPS_PROXY_CHAIN.
Informações Valor Valor padrão 100 Valor Recomendado Um valor que representa o número máximo de objetos integrados em uma página da Web + 1. - Tamanho do Conjunto de Conexões de Saída - As conexões de saída dos conjuntos de servidores proxy para servidores de destino e o número de conexões que reside
no conjunto é configurável. Se o conjunto de conexões for reduzido ou esvaziado, o servidor proxy criará uma nova conexão com o servidor de destino.
Se houver uma alta taxa de cargas concorrentes, aumente o tamanho do conjunto de conexões para o valor da carga de clientes concorrentes esperada para melhorar o desempenho.
Visualize ou configure este valor no console administrativo do WebSphere Application Server clicando emServidores > Servidores Proxy > server_name > Transportes de Servidor Proxy > Configurações do Servidor Proxy HTTP. Na seção Conexão do Servidor de Conteúdo, aumente o máximo de conexões por campo do servidor para um valor que seja igual ou maior que o número máximo esperado de clientes conectados. Salve suas alterações, sincronize as alterações para o nó do servidor proxy e reinicie o servidor proxy.
Informações Valor Valor Recomendado Valor consistente com a carga de clientes concorrentes esperada. - Tempo Limite de Pedidos de Saída - Geralmente, os servidores aplicativos de backend que são confrontados pelo servidor proxy podem estar com carga elevada e não responderem no tempo adequado, portanto as conexões do servidor proxy
podem ficar aguardando a resposta do servidor de aplicativos de backend. Para resolver isso, configure o tempo que o servidor proxy aguarda uma resposta do
servidor de destino. Esse é o valor do Tempo Limite do Pedido de Saída. Controlando o tempo que o servidor proxy aguarda um servidor de aplicativos de backend
lento, as conexões são liberadas mais rápido e utilizadas para que outros pedidos
funcionem.Visualize ou configure esse valor no console administrativo clicando em Servidores > Tipos de Servidores > Servidores Proxy do WebSphere > proxy_server_name > Configurações do Servidor Proxy HTTP. Na seção Conexão do Servidor de Conteúdo, defina o Tempo Limite do Pedido de Saída como um valor que represente o tempo de resposta aceitável do ponto de vista do cliente.
Informações Valor Valor padrão 120 Valor Recomendado Um valor que represente o tempo de resposta aceitável do ponto de vista do cliente.
- Pedidos Persistentes - Um pedido persistente é um enviado em uma
conexão TCP existente. Para maximizar o desempenho, aumente o número de
pedidos recebidos em uma conexão TCP de um cliente. O valor deve representar o número máximo de objetos integrados, por exemplo, GIF, etc, em uma página da Web +1.
Subtópicos
Resolução de Problemas de Encaminhamento de Pedido e Gerenciamento de Carga de Trabalho por meio do Servidor Proxy
Esta seção fornece informações sobre como resolver problemas no tráfego de pedidos que flui pelo servidor proxy.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tjpx_troubproxy
Nome do arquivo: tjpx_troubproxy.html