Chapitre 9. Optimisation de l'acheminement
Le routeur HAProxy d'OpenShift Container Platform peut être dimensionné ou configuré pour optimiser les performances.
9.1. Performances de base du contrôleur d'entrée (routeur)
Le contrôleur d'entrée de la plateforme OpenShift Container, ou routeur, est le point d'entrée du trafic d'entrée pour les applications et les services qui sont configurés à l'aide de routes et d'entrées.
Lorsque l'on évalue les performances d'un routeur HAProxy unique en termes de requêtes HTTP traitées par seconde, les performances varient en fonction de nombreux facteurs. En particulier :
- Mode de maintien/fermeture HTTP
- Type d'itinéraire
- Prise en charge du client de reprise de session TLS
- Nombre de connexions simultanées par route cible
- Nombre de routes cibles
- Taille des pages du serveur dorsal
- Infrastructure sous-jacente (solution réseau/SDN, CPU, etc.)
Bien que les performances dans votre environnement spécifique varient, les tests du laboratoire Red Hat sur une instance de cloud public de taille 4 vCPU/16GB RAM. Un routeur HAProxy unique gérant 100 routes terminées par des backends servant des pages statiques de 1kB est capable de gérer le nombre suivant de transactions par seconde.
Dans les scénarios du mode "keep-alive" de HTTP :
| Encryption | LoadBalancerService | HostNetwork |
|---|---|---|
| aucun | 21515 | 29622 |
| bord | 16743 | 22913 |
| traversée | 36786 | 53295 |
| ré-encrypter | 21583 | 25198 |
Dans les scénarios de fermeture HTTP (pas de keep-alive) :
| Encryption | LoadBalancerService | HostNetwork |
|---|---|---|
| aucun | 5719 | 8273 |
| bord | 2729 | 4069 |
| traversée | 4121 | 5344 |
| ré-encrypter | 2320 | 2941 |
La configuration par défaut du contrôleur d'entrée a été utilisée avec le champ spec.tuningOptions.threadCount défini sur 4. Deux stratégies différentes de publication des points finaux ont été testées : Load Balancer Service et Host Network. La reprise de session TLS a été utilisée pour les itinéraires cryptés. Avec HTTP keep-alive, un seul routeur HAProxy est capable de saturer un NIC de 1 Gbit avec des pages d'une taille aussi petite que 8 kB.
Lorsque le système est exécuté sur du métal nu avec des processeurs modernes, vous pouvez vous attendre à des performances environ deux fois supérieures à celles de l'instance de nuage public ci-dessus. Cette surcharge est introduite par la couche de virtualisation en place sur les nuages publics et s'applique également à la virtualisation basée sur les nuages privés. Le tableau suivant indique le nombre d'applications à utiliser derrière le routeur :
| Number of applications | Application type |
|---|---|
| 5-10 | fichier statique/serveur web ou proxy de mise en cache |
| 100-1000 | les applications générant un contenu dynamique |
En général, HAProxy peut prendre en charge des routes pour un maximum de 1 000 applications, en fonction de la technologie utilisée. Les performances du contrôleur d'entrée peuvent être limitées par les capacités et les performances des applications qui se trouvent derrière lui, comme la langue ou le contenu statique par rapport au contenu dynamique.
La mise en commun des entrées, ou routeurs, devrait être utilisée pour servir davantage de routes vers les applications et contribuer à la mise à l'échelle horizontale du niveau de routage.
Pour plus d'informations sur la répartition des entrées, voir Configuration de la répartition du contrôleur d'entrée à l'aide d'étiquettes d'itinéraire et Configuration de la répartition du contrôleur d'entrée à l'aide d'étiquettes d'espace de noms.
Vous pouvez modifier le déploiement du contrôleur d'ingestion à l'aide des informations fournies dans la section Définition du nombre de threads du contrôleur d'ing estion et des paramètres de configuration du contrôleur d'ing estion pour les délais d'attente, ainsi que d'autres configurations de réglage dans la spécification du contrôleur d'ingestion.
