跳转到主要内容

【容器架构】将Debian vs Alpine作为基准Docker映像的基准

5星评论
没有投票
Last modified
星期三, 十二月 22, 2021 - 22:30

大多数官方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://nickjanetakis.com/blog/benchmarking-debian-vs-alpine-as-a-base-docker-image

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

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

Article

标签(Tags)

企业架构(35) 数据分析(35) Power BI(32) 微服务(31) 微服务架构(30) Data Analysis(30) 商务智能(30) BI(30) 认证考试(30) 微软认证(30) DA-100(28) 应用安全(27) 考试题(26) 物联网(25) 敏捷(25) Enterprise Architecture(24) 试题(20) 首席架构师(19) 首席架构师推荐(19) 云计算(19) 网络安全(18) 技术架构(17) 机器学习(17) 试卷(17) SAFe(16) 大数据(15) Kafka(15) 规模化敏捷(14) enterprise security architecture(14) 企业安全架构(14) 前端架构(14) microservice(13) 业务架构(13) 数据架构(13) IOT(13) 安全运营(13) 容器云(12) 敏捷建模(12) 服务网格(12) 数据分析师(12) 事件驱动架构(12) 区块链(12) 数据安全(12) 数据湖(11) 应用架构(10) AWS(10) 数据科学(10) 人工智能(10) Kubernetes(10) 产品管理(9) BI数据分析师(9) NGINX(9) 数字化转型(9) 深度学习(9) 软件架构(9) 架构师(9) machine learning(9) 商务智能分析师(8) CIO(8) 技术选型(8) 安全战略(8) 软件测试(8) ArchiMate(8) PostgreSQL(8) Azure(8) Cloud Computing(8) Big Data(8) API(8) MSA(8) MDM(8) 技术趋势(7) 容器云架构(7) 核心实践(7) 无服务器架构(7) JavaScript框架(7) Vue(7) React(7) 参考架构(7) DevOps(7) 数据仓库(7) Data Lake(7) Envoy architecture(7) 容器(7) 主数据架构(7) microservices(7) 技术架构师(7) digital transformation(7) 投资组合管理(6) 安全架构(6) 集成架构(6) 合同测试(6) 工控协议(6) ICS(6) Micro Service Architecture(6) Envoy架构(6) 事件驱动(6) 数字化(6) 微服务架构师(6) strategy(6) 安全工具(6) application security principle(6) Angular(6) Postgresql架构(6) 网络架构(6) agilemodeling(6) 首席架构师精选(6) 高管洞察与创新(6) 云安全(6) 合约测试(5) Event Hub(5) 应用安全原则(5) Enterprise Portfolio Management(5) WAF(5) 编程语言(5) JavaScript Frameworks(5) 用户体验(5) 云原生(5) Agile(5) Python(5) IT战略(5) 企业敏捷性(5) 数字化业务(5) API Gateway(5) 项目管理(5) Digital business(5) 工业控制系统(5) Microservice Architecture(5) ICP(5) 软件架构师(5) 数据挖掘(5) Data Architecture(5) 主数据管理(5) 性能(5) Architecture Overview(5) Best Practices(5) Data Warehouse(5) k8s(5) 战略(5) IoT(5) 解决方案(5) 工业物联网(5) 数据科学家(5) 敏捷数据(4) 领导力(4) IPS(4) 领域驱动设计(4) DDD(4) 性能调优(4) 微前端(4) Vue.js(4) Docker(4) 敏捷核心实践(4) 应用组合管理(4) Agile Core Practice(4) 程序员(4) 数据可视化(4) 前端开发(4) 前端架构师(4) 前端开发工程师(4) 容器云架构师(4) 职业发展(4) executive insights and innovation(4) enterprise agility(4) 数据湖架构师(4) 开源合规(4) 敏捷模型(4) 业务转型(4) 企业微服务架构(4) 消费者驱动的合同测试(4) JWT(4) security(4) 企业架构师(4) architecture(4) 应用架构师(4) blockchain(4) 存储架构(4) GDPR(4) Cloud(4) RESTful(4) 最佳实践(4) 分布式计算(4) 数据湖架构(4) Service Mesh(4) BDD(4) 解决方案架构师(4) Event-Driven(4) SCADA(4) 云原生架构(4) 去中心化(4) IoT(4) IoT(4) Deep Learning(4) EA(3) technology(3) NFR(3) 安全(3) 应用现代化(3) Big Data(3) Spark(3) Microservice(3)