跳转到主要内容

热门内容

今日:


总体:


最近浏览:


Chinese, Simplified

category

blog/cards/benchmarking-debian-vs-alpine-as-a-base-docker-image.jpg

大多数官方Docker映像都提供基于Debian和Alpine的映像,但两者之间有一些令人惊讶的性能结果。

自从Docker宣布他们开始在正式的Docker镜像中使用Alpine以来,我就跳槽并拥抱Alpine。

我的意思是,什么都不爱。它是Linux的最小发行版,攻击面非常小。将其作为容器中的基础映像运行似乎是完美的选择。

我写了一篇关于Alpine一年多以前的文章,并且一直以来一直在使用Alpine,而没有出现任何停止演出的问题。



为什么现在要比较这两个基本镜像?



我今天绝对没有醒来,想着“老兄,我想知道Debian在2018年如何成为Alpine作为基础Docker映像”。

真正发生的是,我整理了一篇文章,介绍了一个月前的一些Docker最佳实践,并将其引入了Reddit。

令我惊讶的是,它在Reddit社区获得了150多个投票,99%的投票评分和大量参与。

老实说,这就是我写这篇文章的原因。我使用Docker已经很长时间了,多年来,我选择了一些我认为很好的模式,但是我真的很想看看其他人在做什么,以便我可以改进。我一直在向别人学习。

发现关于Alpine的2种负面趋势



如果您通过Reddit评论,就会发现很多人评论DNS在Alpine中是如何随机失败的,而其他人则评论了某些类型的活动(例如连接到数据库的网络应用)的运行时性能不佳。

DNS查找问题:



我不是一个盲目听从一个人的评论的人,但是一旦有几个人开始提及同一件事,它就会变得很有趣。但是,如果没有某种类型的科学证据,我仍然无法相信一些评论。

幸运的是,有人链接到与Alpine相关的GitHub问题,其中包含更多信息。也许该错误会在适当的时候得到修复,但是在Alpine内部进行DNS查找似乎确实有些奇怪。

也可能与BusyBox中的9年错误有关(Alpine在后台使用此操作系统)。

我没有亲身经历过,但是我也没有运行过使用大规模Kubernetes集群的rofl规模的任何事情,因此也许我不受此问题的影响。

对我们来说幸运的是,Alpine拥有有关DNS查找为何可能失败的文档,并且还解释了为什么我从未遇到过此问题。很高兴知道。

常见的Web应用程序案例会降低运行时性能:



另一位Reddit用户提到,与Debian相比,使用Alpine作为基本映像时,其Node应用的运行速度降低了15%。他还提到自己的Python应用程序也较慢。

这位Reddit评论员甚至表示,他们每天运行500-700个单元测试的真实测试套件的速度差异为35%。那真的引起了我的注意。

当然,我回答了他,要求提供更具体的信息,因为像“慢15%”这样的词在不了解具体情况的情况下并不能说太多。

我们来回了几次,他提供了一些困难的数字,他让一个Python应用程序运行在一个容器中,该应用程序在另一个容器中运行的PostgreSQL中执行10,000个数据库选择。

 

# postgres:9.6.3 and python 2.7

Total test time 15.3489780426 seconds
Total test time 13.5786788464 seconds
Total test time 14.2057600021 seconds


# postgres:9.6.3-alpine and python 2.7

Total test time 14.262032032 seconds
Total test time 13.7757499218 seconds
Total test time 14.1344659328 seconds


# postgres 9.6.3 and python:2.7-alpine

Total test time 18.1418809891 seconds
Total test time 16.0904250145 seconds
Total test time 17.1380209923 seconds

这说明Postgres映像在Alpine和Debian中的运行速度都一样快,但是当基于Alpine的Python映像尝试连接时,速度会明显下降。

这立刻让我认为,也许某些系统级软件包是这里的罪魁祸首。例如,使用Python和Ruby(和其他语言)的大多数流行的PostgreSQL连接库都需要在Debian上安装libpq-dev,在Alpine中安装postgresql-dev。

该软件包需要安装在映像中才能使用Python中的psycopg2和Ruby中的pg之类的软件包。它们使您可以从Web应用程序连接到PostgreSQL。

我们到了。现在我们有一些要测试的东西,并且是比较这两个基本镜像的真实原因。



测试两个基本镜像



在进入基准测试之前,需要指出的是,我不喜欢人为设计的微基准测试。当然,它们对于在语言/框架级别上测试回归非常有用,但是对于测试现实世界场景却毫无用处。

当人们感到“ flim flam Web框架每秒可以处理163,816个请求,而bibity bop仅处理97,471个请求/秒,这真是垃圾!”时,我总是睁大眼睛。

然后,您查看基准测试的功能,它所做的只是返回一个空的200响应。一旦执行序列化JSON或突然从模板返回HTML之类的操作,这两个框架就会变得越来越慢。

然后,您将诸如单个数据库调用之类的因素考虑在内,嘿,您知道什么,两个框架的速度下降了一个数量级。

对真实世界的Web应用程序进行基准测试



在撰写本文时,我将使用Flask课程的代码库的最新版本和完整版本,该版本运行Flask 1.0.2和所有最新的库版本。

这是一个尺寸适中的Flask应用程序,具有4,000多行代码,几个蓝图,并由SQLAlchemy驱动的PostreSQL数据库提供支持,并且还具有许多其他活动部件。

测试环境:



测试用例将是加载一个页面,该页面使用服务器呈现的模板返回HTML,还包括执行1个SELECT语句以按ID在数据库中查找用户。

Flask应用配置了:

  • gunicorn with Flask in production mode (not debug mode)
  • gunicorn running with 8 threads (gthread) and 8 workers
  • Logging level INFO



测试系统(我的开发箱)配置有:

  • i5 3.2GHz CPU with 16GB of RAM and an SSD
  • Docker Compose to launch the project with no app bind volumes
  • Docker for Windows to run the Docker daemon (rebooted between each test)
  • WSL to run the Docker CLI

通用测试策略:

我将运行一个名为wrk的HTTP基准测试工具,以向Flask应用发出请求。对于每个基本映像,我将对其运行5次,并获得最快的结果。

我将使用Debian和Alpine作为基本映像执行此测试,而无需对代码库,应用程序配置,应用程序运行方式或测试机器进行其他更改。

我将在后台运行docker-compose up -d以启动Compose项目,并运行wrk -t8 -c50 -d30 <url to test>以使用8个线程启动wrk,同时保持与该页面的50个HTTP连接。测试将运行30秒。

剧透警报:在这两个测试案例中,我的CPU都达到约65%的最高负荷,因此我们不受CPU限制。

Debian设置



这是我使用的Dockerfile:

FROM python:2.7-slim
LABEL maintainer="Nick Janetakis <nick.janetakis@gmail.com>"

RUN apt-get update && apt-get install -qq -y \
  build-essential libpq-dev --no-install-recommends

WORKDIR /app

COPY requirements.txt requirements.txt
RUN pip install -r requirements.txt

COPY . .
RUN pip install --editable .

CMD gunicorn -c "python:config.gunicorn" "snakeeyes.app:create_app()"

以下是基准测试结果:

nick@workstation:/e/tmp/bsawf$ docker-compose up -d
Recreating snakeeyestest_celery_1  ... done
Starting snakeeyestest_redis_1     ... done
Starting snakeeyestest_postgres_1  ... done
Recreating snakeeyestest_website_1 ... done

nick@workstation:/e/tmp/bsawf$ wrk -t8 -c50 -d30 localhost:8000/subscription/pricing
Running 30s test @ localhost:8000/subscription/pricing
  8 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   167.45ms  171.80ms   1.99s    87.87%
    Req/Sec    39.13     29.99   168.00     74.85%
  8468 requests in 30.05s, 56.17MB read
  Socket errors: connect 0, read 0, write 0, timeout 42
Requests/sec:    281.83
Transfer/sec:      1.87MB

Alpine 设置



这是我使用的Dockerfile:

FROM python:2.7-alpine
LABEL maintainer="Nick Janetakis <nick.janetakis@gmail.com>"

RUN apk update && apk add build-base postgresql-dev

WORKDIR /app

COPY requirements.txt requirements.txt
RUN pip install -r requirements.txt

COPY . .
RUN pip install --editable .

CMD gunicorn -c "python:config.gunicorn" "snakeeyes.app:create_app()"

以下是基准测试结果:

nick@workstation:/e/tmp/bsawf$ docker-compose up -d
Recreating snakeeyestest_celery_1  ... done
Starting snakeeyestest_redis_1     ... done
Starting snakeeyestest_postgres_1  ... done
Recreating snakeeyestest_website_1 ... done

nick@workstation:/e/tmp/bsawf$ wrk -t8 -c50 -d30 localhost:8000/subscription/pricing
Running 30s test @ localhost:8000/subscription/pricing
  8 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   223.56ms  270.60ms   1.96s    88.41%
    Req/Sec    39.53     25.02   140.00     65.12%
  8667 requests in 30.05s, 57.49MB read
  Socket errors: connect 0, read 0, write 0, timeout 20
Requests/sec:    288.38
Transfer/sec:      1.91MB

让我们来谈谈结果



有点古怪。我希望Debian能够打破Alpine的大门,然后进行一次远征军,将我使用的一切都更改为Debian。

如果您考虑系统差异,那么我可以说两个发行版的性能大致相同,尽管Alpine的stdev有点高,但是另一方面,Debian的超时时间更多。在如此短暂的测试中,这两者仍可能是差异。

我毫不怀疑这些Reddit评论员的结果,并且如果有任何发现,该测试表明并非所有测试用例都被等同创建。

我要指出的一件事是Reddit用户的测试执行了10,000条SELECT语句,而我的应用程序执行了1条SELECT语句。那是很大的区别。我想知道如果使用15个数据库查询而不是1个数据库查询,在更复杂的页面上会发生什么。

如果您想拿起手电筒,并使用不同的语言或Python版本创建更多的测试用例,请这样做,并告诉我们它的工作方式。

现在,我将继续使用Alpine,但是如果遇到问题或迫切需要切换的原因,那么我将切换到Debian。

 

本文:https://jiagoushi.pro/benchmarking-debian-vs-alpine-base-docker-image

讨论:请加入知识星球或者微信圈子【首席架构师圈】

本文地址
最后修改
星期一, 三月 4, 2024 - 22:00
Article