Comment optimiser les performances d'un conteneur docker?
j'ai testé Redis container basé sur. https://index.docker.io/u/dockerfile/redis /
avec le même redis-benchmark, redis-server fonctionne à l'intérieur d'un conteneur beaucoup plus lentement, que sur OS hébergé, les statistiques réelles indiquées ci-dessous. (Le premier repère est pour un conteneur docker )
Alors, est-il un moyen d'optimiser les performances d'un conteneur docker?
vagrant@precise64:/tmp$ redis-benchmark -p 49153 -q -n 100000
PING (inline): 5607.27 requests per second
PING: 6721.79 requests per second
MSET (10 keys): 6085.69 requests per second
SET: 6288.91 requests per second
GET: 6627.78 requests per second
INCR: 6454.11 requests per second
LPUSH: 6449.12 requests per second
LPOP: 5355.90 requests per second
SADD: 6237.91 requests per second
SPOP: 6794.40 requests per second
LPUSH (again, in order to bench LRANGE): 6089.76 requests per second
LRANGE (first 100 elements): 6000.24 requests per second
LRANGE (first 300 elements): 4660.70 requests per second
LRANGE (first 450 elements): 4276.79 requests per second
LRANGE (first 600 elements): 3710.85 requests per second
vagrant@precise64:/tmp$
vagrant@precise64:/tmp$ sudo /etc/init.d/redis-server start
Starting redis-server: redis-server.
vagrant@precise64:/tmp$ redis-benchmark -q -n 100000
PING (inline): 19357.34 requests per second
PING: 19175.46 requests per second
MSET (10 keys): 16697.28 requests per second
SET: 19146.08 requests per second
GET: 19175.46 requests per second
INCR: 19135.09 requests per second
LPUSH: 19168.10 requests per second
LPOP: 14976.79 requests per second
SADD: 16638.93 requests per second
SPOP: 18079.91 requests per second
LPUSH (again, in order to bench LRANGE): 18268.18 requests per second
LRANGE (first 100 elements): 16136.84 requests per second
LRANGE (first 300 elements): 11528.71 requests per second
LRANGE (first 450 elements): 9237.88 requests per second
LRANGE (first 600 elements): 8864.46 requests per second
2 réponses
Le contenant apparaît à être plus lent parce que vous allez par le biais d'un réseau supplémentaire de la couche.
dans ce cas, au lieu de se connecter directement à Redis, se connecter au serveur mandataire Userland de Docker, qui lui-même se connecte au conteneur (et au lieu de passer par une interface locale, cette connexion passe par une interface veth ).
cela ajoute un peu de latence (non mesurable par rapport à, E. g, A 10ms page web de la génération; mais 50µs est encore plus rapide que 150µs, si vous voyez ce que je veux dire).
si vous voulez faire une comparaison plus "pommes à pommes", vous pouvez:
- exécuter redis-référence à l'intérieur du conteneur (pour se connecter directement à Redis à partir de l'intérieur du conteneur);
- exécutez redis-benchmark sur une autre machine (mais gardez à l'esprit que vous aurez toujours une couche réseau supplémentaire pour le mécanisme de traduction du port);
- exécuter redis-test sur une autre machine et l'utilisation d'un mécanisme tel que tuyauterie pour donner le conteneur d'un macvlan interface avec (presque) zéro frais généraux.
la couche réseau supplémentaire du conteneur est le goulot d'étranglement de la performance dans votre scénario, et la communication de docker à docker n'aidera pas beaucoup (certaines optimisations s'appliquent, mais alors aussi certains frais généraux supplémentaires doivent être confrontés).
aussi, exécuter redis-benchmark dans le même conteneur que redis server vous donnera des performances au niveau de l'hôte, mais ce n'est pas le cas d'utilisation que vous recherchez, probablement vous aimeriez savoir les performances qui peuvent être fourni par un serveur redis dockerisé.
nous, chez Tor Usware, avons fait quelques tests pour évaluer les frais généraux des applications dockerized et nous avons réalisé que la couche réseau du conteneur limite la performance.
en fait, exécuter un Redis-benchmark dockerisé et un serveur redis dockerisé dans le même hôte ne permet d'obtenir que des requêtes GET de 38k et des requêtes SET de 46k par seconde.
Nous avons une solution pour accélérer ce scénario, de manière non intrusive (aucun changement ni dans Docker ni dans les applications). C'est notre produit Speedus Plug&Run, une bibliothèque de prises haute performance.
en utilisant le redis+Speedus Lite docker (disponible dans le registre des dockers gratuitement), vous serez en mesure de réduire de manière significative les temps de pointe (scénario du pire), de près de 1 seconde à moins de 1 milliseconde.
de plus, Redis+Speedus Lite multiplie la performance de 2,5 X pour SET (à partir de 46k TPS à 113k TPS) et se multiplie par 3X pour GET (de 39k TPS à 121k TPS).
Vérifier ce post sur notre blog pour plus de détails.
mais si vous êtes vraiment à la recherche de performances extrêmes, notre version de performances extrêmes Speedus fera fonctionner vos serveurs redis très rapidement. Grâce à notre technologie, un serveur redis dockerisé peut fournir d'autres applications dockerisées avec des requêtes 717K SET et 415k GET requests par seconde!
Vérifier les détails dans ce post .