问题描述
我注意到，在python:2-alpine3.6上运行我的Python应用程序比在Ubuntu上不运行Docker时要慢得多。我想出了两个小的基准测试命令，当我在Ubuntu服务器上运行它们以及使用Mac的Docker时，这两个操作系统之间存在着巨大的差异。
$ BENCHMARK="import timeit; print(timeit.timeit('import json; json.dumps(list(range(10000)))', number=5000))"
$ docker run python:2-alpine3.6 python -c $BENCHMARK
7.6094589233
$ docker run python:2-slim python -c $BENCHMARK
4.3410820961
$ docker run python:3-alpine3.6 python -c $BENCHMARK
7.0276606959
$ docker run python:3-slim python -c $BENCHMARK
5.6621271420
我还尝试了以下不使用Python的’benchmark’：
$ docker run -ti ubuntu bash
root@6b633e9197cc:/# time $(i=0; while (( i < 9999999 )); do (( i ++
)); done)
real 0m39.053s
user 0m39.050s
sys 0m0.000s
$ docker run -ti alpine sh
/ # apk add --no-cache bash > /dev/null
/ # bash
bash-4.3# time $(i=0; while (( i < 9999999 )); do (( i ++ )); done)
real 1m4.277s
user 1m4.290s
sys 0m0.000s
是什么造成了这种差异？
最佳思路
我使用Python 3运行了与您相同的基准测试：
$ docker run python:3-alpine3.6 python --version
Python 3.6.2
$ docker run python:3-slim python --version
Python 3.6.2
导致2秒以上的差异：
$ docker run python:3-slim python -c "$BENCHMARK"
3.6475560404360294
$ docker run python:3-alpine3.6 python -c "$BENCHMARK"
5.834922112524509
Alpine正在使用musl项目(mirror URL)中的libc(基本系统库)的不同实现。有很多differences between those libraries。结果，每个库在某些用例中可能会表现更好。
这是strace diff between those commands above。输出开始与第269行不同。当然，内存中有不同的地址，但其他方面非常相似。很显然，大部分时间都在等待python命令完成。
将strace安装到两个容器中之后，我们可以获得a more interesting trace(我已将基准测试中的迭代次数减少到10个)。
例如，glibc以以下方式加载库(第182行)：
openat(AT_FDCWD, "/usr/local/lib/python3.6", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 205 entries */, 32768) = 6824
getdents(3, /* 0 entries */, 32768) = 0
musl中的相同代码：
open("/usr/local/lib/python3.6", O_RDONLY|O_DIRECTORY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 62 entries */, 2048) = 2040
getdents64(3, /* 61 entries */, 2048) = 2024
getdents64(3, /* 60 entries */, 2048) = 2032
getdents64(3, /* 22 entries */, 2048) = 728
getdents64(3, /* 0 entries */, 2048) = 0
我并不是说这是关键的区别，但是减少核心库中的I /O操作数量可能有助于提高性能。从差异中可以看到，执行完全相同的Python代码可能会导致稍微不同的系统调用。最重要的可能是优化循环性能。我没有资格判断性能问题是由内存分配还是其他指令引起的。
-
glibc具有10次迭代：write(1, "0.032388824969530106\n", 210.032388824969530106) -
musl具有10次迭代：write(1, "0.035214247182011604\n", 210.035214247182011604)
musl的速度降低了0.0028254222124814987秒。随着差异随着迭代次数的增加而增加，我认为差异在于JSON对象的内存分配。
如果将基准降低为仅导入json，则我们注意到差异并不大：
$ BENCHMARK="import timeit; print(timeit.timeit('import json;', number=5000))"
$ docker run python:3-slim python -c "$BENCHMARK"
0.03683806210756302
$ docker run python:3-alpine3.6 python -c "$BENCHMARK"
0.038280246779322624
加载Python库看起来相当。生成list()会产生更大的差异：
$ BENCHMARK="import timeit; print(timeit.timeit('list(range(10000))', number=5000))"
$ docker run python:3-slim python -c "$BENCHMARK"
0.5666235145181417
$ docker run python:3-alpine3.6 python -c "$BENCHMARK"
0.6885563563555479
显然，最昂贵的操作是json.dumps()，这可能表明这些库之间的内存分配存在差异。
再次查看the benchmark，musl的内存分配确实稍微慢一些：
musl | glibc
-----------------------+--------+--------+
Tiny allocation & free | 0.005 | 0.002 |
-----------------------+--------+--------+
Big allocation & free | 0.027 | 0.016 |
-----------------------+--------+--------+
我不确定”big allocation”是什么意思，但是musl慢了将近2倍，当您重复进行数千或数百万次此类操作时，这可能会变得很重要。