如何优化码头容器的性能？ [英] How to optimize performance for a docker container?

问题描述

我测试了redis容器。
https://index.docker.io/u/dockerfile/redis/

与同样的redis-benchmark相比，redis-server在容器内运行比在托管os上运行的慢得多，实际的统计数据如下所示。 （第一个基准是用于码头集装箱）

所以，是否有优化码头服务的性能？

  vagrant @ precise64：/ tmp $ redis-benchmark -p 49153 -q -n 100000 
 PING（内联）：每秒5607.27个请求
 PING：每秒6721.79个请求
 MSET（10键）：每秒6085.69个请求
 SET：每秒6288.91个请求
 GET：每秒6627.78个请求
 INCR：6454.11每秒请求
 LPUSH：6449.12每秒请求
 LPOP：每秒5355.90个请求
 SADD：每秒6237.91个请求
 SPOP：每秒6794.40个请求
 LPUSH（再次，为了长凳LRANGE）：6089.76个请求每秒
 LRANGE（前100个元素）：每秒6000.24个请求
 LRANGE（前300个元素）：每秒4660.70个请求
 LRANGE（前450个元素）：每秒4276.79个请求
 LRANGE（前600个元素）：每秒3710.85个请求
 
 vagrant @ precise64：/ tmp $ 
 vagrant @ precise64：/ tmp $ sudo /etc/init.d/redis-server start 
启动redis-server：redis-server。 
 vagrant @ precise64：/ tmp $ redis-benchmark -q -n 100000 
 PING（内联）：每秒19357.34个请求
 PING：每秒19175.46个请求
 MSET（10个键）：16697.28每秒请求
 SET：每秒19146.08个请求
 GET：每秒19175.46个请求
 INCR：每秒19135.09个请求
 LPUSH：每秒19168.10个请求
 LPOP：每秒14976.79个请求
 SADD：每秒16638.93个请求
 SPOP：每秒18079.91个请求
 LPUSH（再次，为了长凳LRANGE）：每秒18268.18个请求
 LRANGE （前100个元素）：每秒16136.84个请求
 LRANGE（前300个元素）：每秒11528.71个请求
 LRANGE（前450个元素）：每秒9237.88个请求
 LRANGE（前600个元素） ：8864.46每秒请求
  

解决方案

容器出现要慢一点，因为你要经历一个额外的网络层。

在这种情况下，我直接连接到Redis，连接到Docker用户地址代理，该代理本身连接到容器（而不是通过本地界面）连接到$ code> veth 接口）。

这增加了一点延迟（与10ms网页生成相比，不可衡量）但是50μs仍然比150μs快，如果你看到我的意思）。

如果你想做一个更苹果的比较，你可以：在容器内运行redis-benchmark（从容器内直接连接到Redis）;

<在另一台机器上运行redis-benchmark（但是请记住，端口转换机制仍然有一个额外的网络层）;

在另一台机器上运行redis-benchmark 使用管道作业等机制为容器提供（几乎）零开销的macvlan接口。

I tested redis container based on. https://index.docker.io/u/dockerfile/redis/

With same redis-benchmark, redis-server runs inside container much slower than run on hosted os, the actual statistics shows below. (first benchmark is for dock container)

So, Is there away to optimize performance for 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

解决方案

The container appears to be slower because you are going through an extra network layer.

In that case, instead of connecting directly to Redis, to connect to the Docker userland proxy, which itself connects back to the container (and instead of going over a local interface, this connection goes over a veth interface).

This adds a little bit of latency (not measurable compared to, e.g, a 10ms webpage generation; but 50µs is still faster than 150µs, if you see what I mean).

If you want to do a more "apples to apples" comparison, you could:

• run redis-benchmark inside the container (to connect directly to Redis from within the container);
• run redis-benchmark on another machine (but keep in mind that you will still have an extra network layer for the port translation mechanism);
• run redis-benchmark on another machine and use a mechanism like pipework to give the container a macvlan interface with (almost) zero overhead.

这篇关于如何优化码头容器的性能？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！