La vitesse à laquelle mon serveur peut accepter () les nouvelles connexions TCP entrantes est vraiment mauvaise sous Xen. Le même test sur du matériel en métal nu montre des accélérations de 3-5x.
- Comment se fait-il que ce soit si grave sous Xen?
- Pouvez-vous modifier Xen pour améliorer les performances des nouvelles connexions TCP?
- Existe-t-il d'autres plateformes de virtualisation mieux adaptées à ce type de cas d'utilisation?
Contexte
Dernièrement, j'ai étudié les goulets d'étranglement des performances d'un serveur Java développé en interne sous Xen. Le serveur parle HTTP et répond aux appels de connexion / demande / réponse / déconnexion TCP simples.
Mais même en envoyant des charges de trafic au serveur, il ne peut accepter plus de 7 000 connexions TCP par seconde (sur une instance EC2 à 8 cœurs, c1.xlarge exécutant Xen). Au cours du test, le serveur présente également un comportement étrange dans lequel un cœur (pas nécessairement le processeur 0) est très chargé> 80%, tandis que les autres coeurs restent presque inactifs. Cela me porte à penser que le problème est lié à la virtualisation noyau / sous-jacente.
Lorsque je teste le même scénario sur une plate-forme simple, non virtualisée, les résultats du test indiquent des taux d'acceptation TCP () supérieurs à 35 000 / seconde. Ceci sur une machine Core i5 4 utilisant Ubuntu avec tous les cœurs presque complètement saturés. Pour moi, ce genre de chiffre semble à peu près correct.
Sur l'instance Xen encore, j'ai essayé d'activer / modifier presque tous les paramètres présents dans sysctl.conf. Y compris l’activation de Recevoir le flux de réception et le flux de réception, le pilotage et l’association de threads / processus aux CPU, mais sans gains apparents.
Je sais que des performances dégradées sont à prévoir lors de l'exécution de la virtualisation. Mais à ce degré? Un serveur nu plus lent et plus performant que virt. 8-core par un facteur de 5?
- Est-ce vraiment le comportement attendu de Xen?
- Pouvez-vous modifier Xen pour améliorer les performances des nouvelles connexions TCP?
- Existe-t-il d'autres plateformes de virtualisation mieux adaptées à ce type de cas d'utilisation?
Reproduire ce comportement
En approfondissant cette question et en identifiant le problème, j'ai découvert que l' outil de test de performances de netperf pouvait simuler le même scénario que celui que je rencontre. En utilisant le test TCP_CRR de netperf, j'ai collecté divers rapports de différents serveurs (virtualisés et non virtuels). Si vous souhaitez contribuer à quelques résultats ou consulter mes rapports actuels, veuillez consulter https://gist.github.com/985475.
Comment savoir si ce problème n'est pas dû à un logiciel mal écrit?
- Le serveur a été testé sur du matériel nu et il sature presque tous les cœurs disponibles.
- Lorsque vous utilisez des connexions TCP persistantes, le problème disparaît.
Pourquoi est-ce important?
Chez ESN (mon employeur), je suis le chef de projet de Beaconpush , un serveur Comet / Web Socket écrit en Java. Même s'il est très performant et qu'il peut saturer presque toute la bande passante qui lui est attribuée dans des conditions optimales, il reste limité à la vitesse à laquelle de nouvelles connexions TCP peuvent être établies. En d’autres termes, si vous avez un grand nombre d’utilisateurs qui vont et viennent très souvent, de nombreuses connexions TCP devront être configurées / supprimées. Nous essayons d’atténuer ce risque en maintenant les connexions en vie le plus longtemps possible. Mais au final, la performance accept () est ce qui empêche nos cœurs de tourner et nous n’aimons pas cela.
Mise à jour 1
Quelqu'un a posté cette question sur Hacker News , il y a aussi quelques questions / réponses. Mais je vais essayer de garder cette question à jour avec les informations que je trouve au fur et à mesure.
Matériel / plates-formes sur lesquelles j'ai testé ceci:
- EC2 avec les types d'instance c1.xlarge (8 cœurs, 7 Go de RAM) et cc1.4xlarge (2 x Intel Xeon X5570, 23 Go de RAM). Les AMI utilisés étaient ami-08f40561 et ami-1cad5275 respectivement. Quelqu'un a également souligné que les "groupes de sécurité" (c'est-à-dire le pare-feu de l'EC2) pourraient également affecter. Mais pour ce scénario de test, je n'ai essayé que sur localhost d'éliminer des facteurs externes tels que celui-ci. Une autre rumeur que j'ai entendue est que les instances EC2 ne peuvent pas pousser plus de 100k PPS.
- Deux serveurs virtualisés privés exécutant Xen. L'un d'eux n'avait aucune charge avant le test, mais ne faisait aucune différence.
- Serveur Xen privé dédié chez Rackspace. À peu près les mêmes résultats là-bas.
Je suis en train de réexécuter ces tests et de remplir les rapports à l' adresse https://gist.github.com/985475. Si vous souhaitez aider, donnez vos chiffres. C'est facile!
(Le plan d'action a été déplacé vers une réponse consolidée séparée)