Identification et résolution des incidents liés au serveur proxy
Cette rubrique vous permet de résoudre les problèmes que vous êtes susceptible de rencontrer avec votre serveur proxy.
Pourquoi et quand exécuter cette tâche
Les erreurs du serveur proxy sont consignées dans le
journal des travaux. Consultez la liste suivante en cas d'incident avec votre
serveur proxy.
Les erreurs du serveur proxy sont consignées
dans les fichiers SystemOut.log, proxy.log ou local.log. Consultez la
liste suivante en cas d'incident avec votre serveur proxy.
Procédure
- Le serveur proxy a été créé avec succès, mais je suis incapable de le
démarrer. Recherchez d'éventuels conflits de ports dans le fichier SYSOUT. Utilisez la commande netstat –a pour déterminer si l'un
des noeuds finaux associés au serveur proxy est déjà utilisé. Vous
pouvez trouver les ports dans la console d'administration en cliquant
sur
> Serveurs > Serveurs proxy > <
nom_serveur > Ports.En cas d'échec du démarrage du serveur proxy lorsque vous essayez de le lancer en tant qu'utilisateur non privilégié sur des systèmes UNIX, recherchez le message suivant dans les journaux :
Donnez aux ports des chaînes de transport PROXY_HTTP_ADDRESS et PROXY_HTTPS_ADDRESS des valeurs supérieures à 1024.ChannelFramew E CHFW0029E: Erreur d'initialisation de la chaîne HTTPS_PROXY_CHAIN en raison d'une exception com.ibm.wsspi.channel.framework.exception.RetryableChannelException: Permission refusée TCPPort E TCPC0003E: Echec de l'initialisation du canal TCP TCP_7. La liaison de le socket n'a pas abouti pour l'hôte * et le port 80. Il est possible que le port soit déjà utilisé.
- Le serveur proxy achemine les demandes vers le conteneur Web via un port d'administration. Le serveur proxy est situé avant plusieurs conteneurs Web. La configuration demande que les conteneurs Web écoutent les ports autres que ceux par défaut, tels que les ports 9061, 9081, etc. Ce scénario correspond au cas par défaut lorsque plusieurs serveurs d'applications se trouvent sur la même machine, ce qui force l'utilisation de nouveaux ports dans la configuration. Dans ce scénario, le serveur proxy peut acheminer une requête d'application vers le conteneur Web via le port d'administration 9061 à la place du port attendu (9081).
Ajoutez les numéros des ports d'écoute du conteneur Web à l'hôte virtuel associé à l'application cible. Ce processus vise à garantir que le serveur proxy achemine la requête au conteneur Web via le numéro de port approprié.
- Le serveur proxy a démarré, mais je suis incapable de le démarrer. Assurez-vous que les noeuds finaux du serveur proxy sont les alias hôte de l'hôte virtuel associés à l'application.
- Le serveur proxy achemine vers un autre groupe central. Vérifiez que les passerelles de groupe central existent entre les groupes centraux de la cellule et que les processus choisis comme passerelles sont redémarrés. S'il existe un pare-feu entre le groupe central, vérifiez que les ports ouverts pour le trafic de passerelle de groupe central sont corrects.
- Le serveur proxy ne peut pas acheminer des demandes à une autre cellule. Révisez
les paramètres de passerelle de groupe central. Si le message d'erreur HMGR0149E est consigné sur un serveur quelconque, de façon générale sur un serveur fonctionnant en tant que passerelles de groupe central, vous devez alors modifier les paramètres de sécurité de la cellule pour que la communication ait lieu.
Voir la rubrique Exportation des clés LTPA pour plus d'informations sur la configuration de la sécurité entre plusieurs cellules.
- Réception d'une page blanche lors d'une requête au proxy. Prenez en compte les actions ci-dessous :
- Mettez à jour l'hôte virtuel. Assurez-vous que l'application cible et les règles d'acheminement sont affectées à un hôte virtuel incluant les ports d'écoute du serveur proxy (par défaut : HTTP 80, HTTPS 443). Ajoutez les ports d'écoute du serveur proxy à l'application ou à l'hôte virtuel des règles d'acheminement, ou utilisez l'hôte virtuel hôte_proxy.
- Arrêtez le processus en conflit. Contrôlez le système afin de vous assurer qu'aucun autre
processus (par exemple Apache, IBM HTTP Server, etc.) utilisant les ports
de serveur proxy (par défaut : HTTP 80, HTTPS 443) n'est en cours d'exécution. Si ce problème
survient, le serveur proxy semble démarrer normalement, mais il est incapable de recevoir des requêtes sur le port d'écoute concerné. Contrôlez votre système comme suit :
- Arrêtez le serveur proxy.
- Lancez une requête sur votre système à l'aide des commandes netstat et ps afin de déterminer si un processus défectueux utilise le port sur lequel le serveur proxy écoute.
- Si un processus défectueux est trouvé, arrêtez le processus et configurez votre système afin que le processus ne démarre pas lors du démarrage du système.
- Activez l'acheminement du proxy. Assurez-vous que l'acheminement du proxy est activé pour le module Web de l'application. L'acheminement du proxy est activé par défaut, donc si aucune propriété de proxy n'est modifiée, ne tenez pas compte de cette solution. Sinon, voir Personnalisation du routage vers des applications pour des instructions relatives à la modification des propriétés du serveur proxy.
- Testez les requêtes directes. Assurez-vous que l'application cible est installée en envoyant une requête directement au serveur d'applications. Si vous ne recevez aucune réponse, le problème se trouve au niveau du serveur d'applications et non au niveau du serveur proxy. Vérifiez cette possibilité en examinant le serveur proxy après avoir reçu une réponse directement de la part du serveur d'applications.
- Erreur HTTP 404 (Fichier introuvable) reçue de la part du serveur proxy. Prenez en compte les actions ci-dessous :
- Mettez à jour l'hôte virtuel. Assurez-vous que l'application cible et les règles d'acheminement sont affectées à un hôte virtuel incluant les ports d'écoute du serveur proxy (par défaut : HTTP 80, HTTPS 443). Ajoutez les ports d'écoute du serveur proxy à l'application ou à l'hôte virtuel des règles d'acheminement, ou utilisez l'hôte virtuel hôte_proxy.
- Activez l'acheminement du proxy. Assurez-vous que l'acheminement du proxy est activé pour le module Web de l'application. L'acheminement du proxy est activé par défaut, donc si aucune propriété de proxy n'est modifiée, ne tenez pas compte de cette solution. Sinon, voir Personnalisation du routage vers des applications pour des instructions relatives à la modification des propriétés du serveur proxy.
- Testez les requêtes directes. Assurez-vous que l'application cible est installée en envoyant une requête directement au serveur d'applications. Si vous ne recevez aucune réponse, le problème se trouve au niveau du serveur d'applications et non au niveau du serveur proxy. Vérifiez cette possibilité en examinant le serveur proxy lorsque vous réussissez à recevoir une réponse directement de la part du serveur d'applications.
- Impossible de lancer des requêtes Secure Sockets Layer (SSL) à l'application ou aux règles d'acheminement. Assurez-vous que l'hôte virtuel de l'application ou des règles d'acheminement inclut un alias d'hôte pour le port SSL du serveur proxy (par défaut : 443).
- Impossible de connecter le serveur proxy...expiration du délai de requête. Arrêtez le processus en conflit. Contrôlez le système afin de vous assurer qu'aucun autre
processus (par exemple Apache, IBM HTTP Server, etc.) utilisant les ports
de serveur proxy (par défaut : HTTP 80, HTTPS 443) n'est en cours d'exécution. Si cette situation
survient, le serveur proxy semble démarrer normalement, mais il est incapable de recevoir des requêtes sur le port d'écoute concerné. Contrôlez votre système comme suit :
- Arrêtez le serveur proxy.
- Lancez une requête sur votre système à l'aide des commandes netstat et ps afin de déterminer si un processus défectueux utilise un port sur lequel le serveur proxy écoute.
- Si un processus défectueux est trouvé, arrêtez le processus et configurez votre système afin que le processus ne démarre pas lors du démarrage du système.
- N'a pas reçu de réponse de la part de l'application de page d'erreur lorsque l'erreur HTTP est survenue (par exemple, 404). Assurez-vous que l'URI de la page d'erreur a été correctement saisi. Assurez-vous également que l'option Gérer les options éloignées est sélectionnée si vous gérez les réponses d'erreur HTTP depuis des serveur d'arrière-plan. Pour plus d'informations, voir Présentation de la règle de page d'erreurs personnalisée et les règles des pages d'erreurs personnalisées de Paramètres du serveur proxy.
- Quels packages dois-je activer lors du traçage du serveur proxy ? Tous les traçages ne nécessitent pas les packages suivants, mais utilisez-les tous en cas de doute :
- *=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
- Comment puis-je activer la charge on/off SSL ? La charge on/off SSL est le protocole de transport dans la console d'administration et le protocole de transport est une propriété de module Web. Pour savoir comment configurer les propriétés de module Web, voir Personnalisation du routage vers des applications. Aucune charge on/off SSL ni aucune propriété de protocole de transport n'existe pour les règles d'acheminement car le protocole de transport est inhérent au cluster de serveur générique spécifié dans les règles d'acheminement.
- Face à un serveur IBM HTTP ou à un plug-in de serveur Web, comment dois-je configurer le serveur proxy afin de ne pas avoir à ajouter de port correspondant au hôte virtuel ? Pour que le serveur proxy sécurise les informations relatives à la sécurité d'une requête, par exemple les en-têtes privés du produit, ajoutez l'émetteur de la requête à la liste des serveurs proxy de sécurité sécurisés du serveur proxy. Par exemple, ajoutez un serveur IBM HTTP ou un plug-in de serveur Web qui envoie des demandes au serveur proxy, à la liste des proxy de sécurité sécurisés du serveur proxy. Le plug-in de serveur Web envoie alors des informations d'en-têtes privés qui contiennent les informations d'hôte virtuel d'une requête. Si le proxy ne sécurise pas ces en-têtes privés à partir du plug-in de serveur Web ou de n'importe quel client, le serveur proxy ajoute ses propres en-têtes privés, ce qui nécessite l'ajout de ports de serveur proxy (HTTP et HTTPS) à l'hôte virtuel. Plus probablement, le but de l'utilisation du plug-in de serveur Web avec le serveur proxy est d'utiliser le serveur proxy comme serveur d'arrière-plan. Veillez à ajouter le plug-in en tant que proxy de sécurité sécurisé afin d'éviter de devoir exposer les ports de serveur proxy. Pour plus d'informations sur la configuration d'un plug-in de serveur Web afin de l'utiliser avec le serveur proxy, voir Routage des demandes entre un plug-in et un serveur proxy. Pour plus d'informations sur les serveurs proxy de sécurité sécurisés, voir Paramètres du serveur proxy.
- Le serveur proxy semble se bloquer lorsqu'il est surchargé ou l'exception Trop de fichiers
ouverts s'affiche dans ffdc ou SystemErr.log. Si le nombre de connexions est élevé, le nombre de descripteurs
de système de fichiers peut être dépassé et le serveur proxy peut
sembler se bloquer et émettre l'exception "Trop de fichiers ouverts"
dans le répertoire ffdc ou dans le fichier
SystemError.log car il est incapable d'ouvrir un connecteur.
Pour résoudre ce problème, modifiez un ou
plusieurs des paramètres suivants au niveau du système d'exploitation et du serveur proxy
pour optimiser l'utilisation des connexions du serveur proxy :
Optimisation du système d'exploitation pour Windows 2003 et XP
- TcpTimedWaitDelay - Délai qui doit s'écouler avant que TCP/IP
ne libère une connexion fermée et ne réutilise ses ressources. Cet intervalle entre la fermeture et la libération correspond à l'état TIME_WAIT
ou à une valeur représentant le double de la durée de vie maximale du segment (2MSL). Pendant cette période, il est plus avantageux en terme de coût de rouvrir la connexion
sur le client et le serveur que d'établir une nouvelle connexion. Si vous réduisez la valeur de cette entrée, TCP/IP
libère plus rapidement les connexions fermées et peut fournir davantage de ressources
pour les nouvelles connexions. Modifiez ce paramètre si l'application en cours
d'exécution requiert une libération rapide, la création de nouvelles connexions ou un
ajustement en raison d'un faible débit dû à un nombre élevé de connexions à l'état
TIME_WAIT. Visualisez ou définissez ces valeurs comme suit :
- Utilisez la commande regedit et accédez à la sous-clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters afin de créer une nouvelle valeur REG_DWORD appelée TcpTimedWaitDelay.
- Choisissez la valeur décimale 30, qui correspond à la valeur hexadécimale 0x0000001e. Cette valeur fixe le délai d'attente à 30 secondes.
- Arrêtez et redémarrez votre serveur.
Information valeur Valeur par défaut 0xF0, qui fixe le délai d'attente à 240 secondes (4 minutes). Valeur recommandée Valeur minimale de 0x1E, qui fixe le délai d'attente à 30 secondes. - MaxUserPort - Détermine le numéro de port le plus élevé que TCP/IP peut
allouer lorsqu'une application demande un port utilisateur disponible sur le système. Visualisez ou définissez ces valeurs comme suit :
- Utilisez la commande regedit, accédez à la sous-clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ ervices\TCPIP\Parameters registry et créez une valeur REG_DWORD nommée MaxUserPort.
- Choisissez une valeur décimale supérieure ou égale à 32768.
- Arrêtez et redémarrez votre serveur.
Information valeur Valeur par défaut Aucun Valeur recommandée Supérieure ou égale à 32768.
- TcpTimedWaitDelay - Délai qui doit s'écouler avant que TCP/IP
ne libère une connexion fermée et ne réutilise ses ressources. Cet intervalle entre la fermeture et la libération correspond à l'état TIME_WAIT
ou à une valeur représentant le double de la durée de vie maximale du segment (2MSL). Pendant cette période, il est plus avantageux en terme de coût de rouvrir la connexion
sur le client et le serveur que d'établir une nouvelle connexion. Si vous réduisez la valeur de cette entrée, TCP/IP
libère plus rapidement les connexions fermées et peut fournir davantage de ressources
pour les nouvelles connexions. Modifiez ce paramètre si l'application en cours
d'exécution requiert une libération rapide, la création de nouvelles connexions ou un
ajustement en raison d'un faible débit dû à un nombre élevé de connexions à l'état
TIME_WAIT.
Optimisation du système d'exploitation pour Linux
- Paramètre timeout_timewait - Délai qui doit s'écouler avant que TCP/IP
ne libère une connexion fermée et ne puisse réutiliser ses ressources.
Cet intervalle entre la fermeture et la libération correspond à l'état TIME_WAIT
ou à une valeur représentant le double de la durée de vie maximale du segment (2MSL). Pendant cette période, il est plus avantageux en terme de coût de rouvrir la connexion
sur le client et le serveur que d'établir une nouvelle connexion. Si vous réduisez la valeur de cette entrée, TCP/IP
peut libérer plus rapidement les connexions fermées, ce qui augmente le nombre de
ressources disponibles pour les nouvelles connexions. Optimisez ce paramètre si
l'application en cours d'exécution requiert une libération rapide, la création de
nouvelles connexions et un faible débit en raison du nombre élevé de
connexions à l'état TIME_WAIT. Visualisez ou définissez cette valeur en exécutant la commande suivante pour affecter
au paramètre timeout_timewait une valeur de 30 secondes :
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
- Linux file descriptors
(ulimit) - Specifies the number of open files that are supported.
The default setting is typically sufficient for most applications.
If the value set for this parameter is too low, a file open error,
memory allocation failure, or connection establishment error might
display.
View or set this value by checking the UNIX reference pages on the ulimit command for the syntax of different shells. Set the ulimit command to 65535 for the KornShell shell (ksh), by issuing the ulimit -n 65535 command. Use the ulimit -a command to display the current values for all limitations on system resources.
Information Value Default value 1024 Recommended value 65535
- Paramètre timeout_timewait - Délai qui doit s'écouler avant que TCP/IP
ne libère une connexion fermée et ne puisse réutiliser ses ressources.
Cet intervalle entre la fermeture et la libération correspond à l'état TIME_WAIT
ou à une valeur représentant le double de la durée de vie maximale du segment (2MSL). Pendant cette période, il est plus avantageux en terme de coût de rouvrir la connexion
sur le client et le serveur que d'établir une nouvelle connexion. Si vous réduisez la valeur de cette entrée, TCP/IP
peut libérer plus rapidement les connexions fermées, ce qui augmente le nombre de
ressources disponibles pour les nouvelles connexions. Optimisez ce paramètre si
l'application en cours d'exécution requiert une libération rapide, la création de
nouvelles connexions et un faible débit en raison du nombre élevé de
connexions à l'état TIME_WAIT. Visualisez ou définissez cette valeur en exécutant la commande suivante pour affecter
au paramètre timeout_timewait une valeur de 30 secondes :
Operating system tuning for AIX
- TCP_TIMEWAIT - Determines the time that must elapse before TCP/IP
releases a closed connection and can reuse its resources. This interval
between closure and release is known as the TIME_WAIT state, or twice
the maximum segment lifetime (2MSL) state. During this time, reopening
the connection to the client and server costs less than establishing
a new connection. By reducing the value of this entry, TCP/IP can
release closed connections faster, providing more resources for new
connections. Adjust this parameter, if the running application requires
rapid release or the creation of new connections, or if a low throughput
occurs due to many connections sitting in the TIME_WAIT state. View
or set this value by issuing the following command to set the TCP_TIMEWAIT
state to 15 seconds:
/usr/sbin/no -o tcp_timewait =1
- AIX file descriptors (ulimit) - Specifies the number of
open files that are permitted. The default setting is typically sufficient for most applications. If
the value set for this parameter is too low, errors can occur when opening files or establishing
connections, and a memory allocation error might display. To prevent WebSphere Application Server from running short on resources, remove the
limits (ulimit) for resources on the user account on which the WebSphere Application Server process runs.View or set this value by changing the ulimit settings as follows:
- Open the command window.
- Type smitty users to open the AIX configuration program.
- Select Change or Show Characteristics of a user.
- Type the name of the user account on which the WebSphere Application Server runs.
- Press Enter.
- Change the following settings to the indicated value:
Information Value Soft FILE Size -1 Soft CPU Time -1 Soft STACK Size -1 Soft CORE File Size -1 Hard FILE Size -1 Hard CPU Time -1 Hard STACK Size -1 Hard CORE File Size -1 - Press Enter to save changes.
- Log out and log into your account.
- Restart the product.
Information Value Default value 2000 Recommended value unlimited
- TCP_TIMEWAIT - Determines the time that must elapse before TCP/IP
releases a closed connection and can reuse its resources. This interval
between closure and release is known as the TIME_WAIT state, or twice
the maximum segment lifetime (2MSL) state. During this time, reopening
the connection to the client and server costs less than establishing
a new connection. By reducing the value of this entry, TCP/IP can
release closed connections faster, providing more resources for new
connections. Adjust this parameter, if the running application requires
rapid release or the creation of new connections, or if a low throughput
occurs due to many connections sitting in the TIME_WAIT state. View
or set this value by issuing the following command to set the TCP_TIMEWAIT
state to 15 seconds:
Operating system tuning for HP-UX
HP-UX nfile kernel parameter - Specifies the maximum number of files that can be open on the system at any given time. Not specifying a large enough number might restrict your system processing capacity.
HP-UX ninode kernel parameter - Specifies the maximum number of open inodes that can be in memory. An open inode is associated with each unique open file. Therefore, the value you specify for the ninode parameter should be larger than the number of unique files that must be open at the same time.
Operating system tuning for Solaris
- Solaris file descriptors (ulimit) - Specifies the number of open
files that are supported. If the value specified for this parameter
is too low, a file open error, memory allocation failure, or connection
establishment error might display. View or set this value by checking
the UNIX reference pages on
the ulimit command for the syntax of different shells.
- Issue the ulimit -a command to display the current values for all limitations on system resources.
- Issue the ulimit -n 65535 command to set the ulimit command to 65535 for the KornShell shell (ksh).
- The maximum number of files that can be open for a process is also affected by the rlim_fd_max, and rlim_fd_cur settings for the global kernel limit. You might need to increase the values of these settings in the /etc/system file.
Solaris 10 provides a new mechanism for setting kernel parameters. Issue one of the following commands to specify a new limit for the max number of file descriptor kernel parameter on Solaris 10:- To change the value for the current shell session:
prctl -n process.max-file-descriptor -r -v 65535 $$
- To make the change a system wide change:
projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)' system
Faites attention quand vous émettez cette commande car elle modifie le paramètre pour tous les utilisateurs et tous les projets.
- Pour modifier la valeur pour tous les projets appartenant à l'utilisateur racine :
projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)' user.root
- Pour modifier la valeur pour tous les projets appartenant à un utilisateur non racine :
projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)' user.username
- TCP_TIME_WAIT_INTERVAL - Indique au protocole TCP/IP la durée pendant laquelle les blocs
de contrôle de connexion doivent rester fermés. Une fois la connexion TCP/IP des applications achevée, les
blocs de contrôle sont conservés pendant l'intervalle d'attente demandé. Aux heures de pointe, il se forme un gros arriéré de connexions
TCP/IP susceptible de ralentir les performances du serveur. Le serveur peut se bloquer lors des périodes de pointe. Si le serveur se bloque, la commande netstat indique qu'un grand nombre de sockets
ouverts sur le serveur HTTP sont à l'état CLOSE_WAIT ou FIN_WAIT_2. Des délais allant
jusqu'à 4 minutes ont été observés, au cours desquels le serveur n'envoyait aucune
réponse. Cependant, le taux d'utilisation des processeurs demeurait élevé, toutes leurs
activités étant concentrées dans les processus système. Visualisez et définissez cette valeur en utilisant le commande get pour déterminer l'intervalle en cours et la commande set pour définir un intervalle de 30 secondes. Par exemple :
ndd -get /dev/tcp tcp_time_wait_interval ndd -set /dev/tcp tcp_time_wait_interval 30000
Information valeur Valeur par défaut 240000 millisecondes, ce qui correspond à 4 minutes. Valeur recommandée 60000 millisecondes
- Solaris file descriptors (ulimit) - Specifies the number of open
files that are supported. If the value specified for this parameter
is too low, a file open error, memory allocation failure, or connection
establishment error might display. View or set this value by checking
the UNIX reference pages on
the ulimit command for the syntax of different shells.
- Optimisation du serveur proxy
- Requêtes persistantes - Une requête persistante fait partie de celles envoyées sur une
connexion TCP existante. Vous pouvez améliorer les performances en augmentant le nombre
de requêtes reçues sur une connexion TCP de la part d'un client. La valeur
doit représenter le nombre maximal d'objets imbriqués, par exemple GIF
ou autre, dans une page Web +1.
Visualisez ou définissez cette valeur dans la console d'administration WebSphere Application Server en cliquant sur Serveurs > Serveurs proxy > nom_serveur > Transports de serveur proxy > HTTP_PROXY_CHAIN/HTTPS_PROXY_CHAIN.
Information valeur Valeur par défaut 100 Valeur recommandée Une valeur représentant le nombre maximal d'objets imbriqués dans une page Web +1. - Taille de pools de connexions sortantes - Les connexions sortant des pools de serveur proxy
vers les serveurs cible et le nombre de connexions résidant dans le pool peuvent être
configurés. Si le pool de connexions est vide ou presque, le serveur proxy
crée une nouvelle connexion vers le serveur cible.
Si les charges simultanées sont élevées,
augmentez la taille du pool de connexions jusqu'à la valeur de charges client simultanés attendue
afin d'atteindre les performances optimales.
Visualisez ou définissez cette valeur dans la console d'administration WebSphere Application Server en cliquant sur Serveurs > Serveurs proxy > nom_serveur > Transports de serveur proxy > Paramètres du serveur proxy HTTP. Dans la section Connexion de serveur de contenu, augmentez la valeur de la zone Nombre maximal de connexions par serveur jusqu'à une valeur supérieure ou égale au nombre maximal attendu de clients connectés. Sauvegardez vos modifications, synchronisez les modifications au noeud de serveur proxy, puis redémarrez le serveur proxy.
Information valeur Valeur recommandée Valeur cohérente par rapport à la charge client simultanée attendue. - Délai de requête sortante - Souvent, les serveurs d'applications en arrière-plan
qui sont précédés par le serveur proxy peuvent être soumis à une charge élevée et peuvent ne pas répondre
dans un délai approprié, c'est pourquoi les connexions sur le serveur proxy
peuvent être liées à l'attente de la réponse du serveur d'applications en arrière-plan. Arrangez ceci en configurant la durée pendant laquelle le serveur proxy attend une réponse du serveur cible. Il s'agit de la valeur de Délai de requête sortante. En gérant la durée pendant laquelle le serveur proxy attend un serveur d'applications en arrière-plan lent, les connexions sont libérées plus rapidement et sont utilisées pour d'autres travaux de requêtes.Affichez ou définissez cette valeur dans la console d'administration en cliquant sur Serveurs > Types de serveurs > Serveurs proxy WebSphere > nom_serveur_proxy > Paramètres du serveur proxy HTTP. Dans la section Connexion de serveur de contenu, définissez une valeur Délai de requête sortante représentant un délai de réponse acceptable du point de vue du client.
Information valeur Valeur par défaut 120 Valeur recommandée Une valeur représentant un délai de réponse acceptable du point de vue du client.
- Requêtes persistantes - Une requête persistante fait partie de celles envoyées sur une
connexion TCP existante. Vous pouvez améliorer les performances en augmentant le nombre
de requêtes reçues sur une connexion TCP de la part d'un client. La valeur
doit représenter le nombre maximal d'objets imbriqués, par exemple GIF
ou autre, dans une page Web +1.
Sous-rubriques
Identification des incidents d'acheminement des requêtes et de gestion de charge de travail au travers du serveur proxy
Cette section fournit des informations sur l'identification des incidents de trafic des requêtes qui passent pas le serveur proxy.


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