Optimisation des performances de Docker

Les informations d'optimisation des performances suivantes peuvent être utilisées pour vous aider à configurer vos environnements HCL Commerceconteneurisés pour des performances optimales.

Dans HCL Commerce Version 9.1, les serveurs d'applications (Store, Transaction, Search) s'exécutent dans les conteneurs Docker. Ces conteneurs Docker sont souvent gérés par un système d'orchestration Docker, K8S, IBM Cloud Private, etc.

Auparavant, les serveurs d'applications HCL Commerce fonctionnaient dans des environnements physiques (serveurs Bare Metal) ou virtuels, comme LPAR, VMware et XEN. Docker apporte un autre niveau de virtualisation, mais la technologie d'implémentation Docker diffère de la virtualisation traditionnelle, ce qui a un impact sur la façon dont vous optimisez les performances.

Les spécifications suivantes sont basées sur les résultats des tests internes. Votre environnement de production peut différer des environnements utilisés pour les tests internes. Surveillez toujours l'état de votre environnement de production pour ajuster votre optimisation des performances.

Configuration des ressources de conteneur Docker

Les conteneurs Docker comprennent les ressources informatiques générales suivantes :

UC
Mémoire
E/S de réseau
E/S disque

En général, les E/S de réseau ou de disque pour les conteneurs d'application Docker ne sont pas limitées. Les limitations sont placées uniquement sur l'utilisation de l'UC et de la mémoire des conteneurs d'application. La limitation des ressources mémoire est plus simple, puisqu'elle utilise un paramètre de taille unique. La limitation des ressources d'UC est un peu plus complexe.

Comparaison entre deux paramètres de ressources d'UC différents

Docker fournit plusieurs approches différentes pour contrôler les ressources d'UC. Pour plus d'informations sur le contrôle des ressources d'UC, voir Contraintes d'exécution de Docker sur les ressources.

CPUset/CPU-binding et CPU-quota sont des approches d'optimisation couramment utilisées qui sont simples à comprendre. Les hôtes Docker concurrents sur Linux ont souvent plusieurs UC virtuelles. CPUset lie les processus de conteneur Docker à des UC virtuelles spécifiques. Ainsi, la limite supérieure de la ressource UC que le conteneur Docker peut utiliser est définie par le nombre d'UC virtuelles attribuées. Dans les environnements Docker de production, le conteneur Docker peut ne pas utiliser la limite car d'autres conteneurs Docker peuvent rivaliser avec lui sur la même UC virtuelle. CPU-quota est une autre approche temporelle de l'UC. Cette approche contrôle le temps total de l'UC spécifique que le conteneur Docker peut utiliser, mais le conteneur Docker peut utiliser différentes UC virtuelles librement. A première vue, les deux approches peuvent sembler les mêmes. Toutefois, en présence de nombreuses UC virtuelles, il peut y avoir des différences de performance significatives entre les deux approches. Faire basculer les processus Docker entre différentes UC virtuelles a son propre coût. Plus l'écart qui se situe entre le nombre de CPU-quota et le nombre total d'UC virtuelles est élevé, plus grande est la possibilité qu'un processus Docker doive basculer entre différentes UC virtuelles.

Des tests internes ont permis de comparer les deux approches en ce qui concerne la limitation des ressources UC. Le test a utilisé un serveur Bare Metal avec 24 UC virtuelles. Trois situations de test ont été effectuées avec les trois différents serveurs d'application HCL Commerce : de stockage, de transaction et de recherche. Pour chaque test, un conteneur Docker a été utilisé pour le niveau d'application cible. L'environnement a également été configuré de sorte que le seul goulot d'étranglement possible soit la ressource d'UC pour le niveau d'application cible. En d'autres termes, tous les autres goulots d'étranglement potentiels ont été éliminés.

Les tests internes ont révélé le même modèle pour les trois serveurs :

En général, CPUset a montré une meilleure performance que l'approche CPUquota.
Le nombre idéal d'UC virtuelles est 6~8. Un nombre insuffisant (<=4) ou excessif (>=10) d'UC virtuelles peut nuire aux performances.

Recommandation pour le paramètre des ressources d'UC

En général, CPUset constitue une approche sûre pour limiter les ressources d'UC pour les conteneurs HCL Commerce Docker. Cette approche peut être utilisée avec docker-run ou docker-compose pour gérer ou exécuter vos conteneurs. Malheureusement, le mode CPUset limite votre capacité à déplacer librement les Dockers entre les différents hôtes Docker, ce qui peut limiter la conception du système d'orchestration Docker. Ainsi, la plupart des systèmes Docker ne supportent que l'approche CPUquota pour contrôler l'utilisation des ressources d'UC. En outre, il y a souvent un nombre d'UC "par défaut" pour chaque application Docker. Par exemple, la limite de ressources d'UC est de 2 UC virtuelles dans les systèmes K8S/IBM Cloud Private. Cela ne devrait pas être un problème si l'hôte Docker n'a que quelques UC virtuelles. Toutefois, si l'hôte Docker dispose de nombreuses UC virtuelles, envisagez de modifier la limite du processeur à 6~8 pour les conteneurs d'application.

Recommandation pour le paramètre des ressources de mémoire

HCL Commerce repose sur des serveurs d'applications qui sont tous des programmes Java. Avec l'introduction de la conteneurisation, une confusion peut se produire autour de la taille du segment JVM et de la taille de la mémoire du processus Docker. Les programmes Java nécessitent deux parties de mémoire : le segment JVM et le segment natif, en particulier la mémoire qui est utilisée pour le programme de gestion JVM plutôt que le code d'application Java. La mémoire physique totale requise pour les conteneurs HCL Commerce Docker est la somme des deux parties.

Actuellement, les serveurs d'applications HCL Commerce nécessitent une taille de segment JVM de 2 Go~4 Go. Pour plus d'informations, voir Valeurs réglables par défaut de HCL Commerce.

La limite de ressource mémoire par défaut pour les conteneurs d'applications dans le système K8S/IBM Cloud Private est de 4 Go. Lorsque le segment JVM d'application HCL Commerce se rapproche de 4 Go, la taille totale de la mémoire est supérieure à 4 Go, car davantage d'espace est nécessaire pour le segment natif. Par conséquent, la mémoire est plafonnée et le conteneur d'application est arrêté.

Dans ce cas, la solution à adopter est d'ajouter une mémoire tampon supplémentaire pour le segment natif. Dans la plupart des cas, vous pouvez ajouter une mémoire tampon de 2 Go pour le segment natif. Si la taille maximale du segment JVM est de 4 Go, définissez la limite de ressources pour le conteneur d'application sur 6 Go. Si la taille maximale du segment JVM est supérieure à 4 Go, augmentez la limite de mémoire Docker en conséquence. Comme toutes les optimisations de performances, des tests de performances sont nécessaires pour déterminer ces valeurs.

Note: Tous les paramètres précédents d'UC/de mémoire sont spécifiques à la production ou aux environnements de test de performances. Pour la création ou les environnements de test fonctionnels, le système est souvent sous-utilisé, de sorte que la limite d'UC/de mémoire peut être définie sur une valeur plus faible ; par exemple, 2 UC virtuelles/4 Go de mémoire.