Documentation Oracle Cloud Infrastructure

Paramètres de délai d'expiration de connexion

Sur Compute Cloud@Customer, vous pouvez configurer des processus d'écoute d'équilibreur de charge afin de contrôler le temps d'inactivité maximal autorisé pour chaque connexion TCP ou paire demande/réponse HTTP.

Les équilibreurs de charge prennent en charge le multiplexage des connexions. L'équilibreur de charge peut acheminer un grand nombre de demandes entrantes de plusieurs clients vers le serveur back-end de destination via un petit nombre (un ou plusieurs) de connexions back-end.

Une fois que l'équilibreur de charge a connecté un client à un serveur back-end, la connexion peut être fermée pour cause d'inactivité. Vous pouvez configurer des processus d'écoute d'équilibreur de charge afin de contrôler le temps d'inactivité maximal autorisé pour chaque connexion TCP ou paire demande/ réponse HTTP.

Les paramètres de délai d'expiration suivants ont une incidence sur le comportement de l'équilibreur de charge :

  • Paramètre de persistance des connexions entre l'équilibreur de charge et le client

  • Paramètre de persistance de connexion entre l'équilibreur de charge et le serveur back-end

  • Temps d'inactivité en secondes

Paramètres de maintien des connexions

Le service Load Balancing ne respecte pas les paramètres de persistance de connexion des serveurs back-end. L'équilibreur de charge ferme les connexions au serveur back-end qui restent inactives pendant plus de 300 secondes. Nous vous recommandons de ne pas autoriser les serveurs back-end à fermer les connexions à l'équilibreur de charge. Pour éviter les éventuelles erreurs 502, assurez-vous que vos serveurs back-end ne ferment pas les connexions inactives en moins de 310 secondes.

Le service Load Balancing définit la valeur de persistance de connexion de façon à conserver la connexion jusqu'à ce qu'elle soit inactive pendant 65 secondes. Impossible de modifier la valeur de ce paramètre.

Paramètres de délai d'inactivité

Lorsque vous créez ou modifiez un processus d'écoute TCP ou HTTP, vous pouvez indiquer le temps d'inactivité maximal en secondes. Ce paramètre s'applique au délai autorisé entre deux opérations d'entrée/de sortie réseau successives de réception ou d'envoi lors de la phase demande-réponse HTTP. Si le délai d'attente configuré est écoulé sans aucun paquet envoyé ou reçu, la connexion du client est fermée. Pour les connexions HTTP et WebSocket, les opérations d'envoi ne réinitialisent pas l'horloge des opérations de réception et les opérations de réception ne le sont pas.

Remarque

Ce paramètre de délai d'expiration ne s'applique pas au temps d'inactivité entre une réponse terminée et la demande HTTP suivante.

Les valeurs de délai d'expiration par défaut sont les suivantes : 300 secondes pour les processus d'écoute TCP et 60 secondes pour les processus d'écoute HTTP. La valeur d'expiration maximale est de 7200 secondes.

Modifiez le paramètre de délai d'expiration si le client ou le serveur back-end exige un délai plus long pour transmettre les données. Par exemple :

  • Le client envoie une requête de base de données au serveur back-end et l'exécution de la base de données prend plus de 300 secondes. Par conséquent, le serveur back-end ne peut pas transmettre de données dans les 300 secondes.

  • Le client télécharge des données à l'aide du protocole HTTP. Lors du téléchargement, le back-end ne transmet aucune donnée au client pendant plus de 60 secondes.

  • Le client télécharge des données à l'aide du protocole HTTP. Après la demande initiale, il cesse de transmettre les données au serveur back-end pendant plus de 60 secondes.

  • Le client commence à transmettre des données après l'établissement d'une connexion WebSocket, mais le serveur back-end ne transmet pas les données pendant plus de 60 secondes.

  • Le serveur back-end commence à transmettre des données après l'établissement d'une connexion WebSocket, mais le client ne transmet pas les données pendant plus de 60 secondes.