阿里云容器服务网络性能测试

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 从时延和吞吐这两个维度测试了四种不同的服务之间相互访问的模式的网络性能并给出了测试结论。最后提出了几个应用方面的问题。

背景

我们正在将测试环境逐步从mesos框架迁移到阿里云的容器服务,在此过程中测试了四种不同的服务之间相互访问的模式的网络性能。本文阐述了该性能测试的方法,数据和结论。

测试目标

服务容器之间的交互存在四种不同的访问方式:

docker link

docker提供的link方式,可以在一个容器中访问另一个容器。 测试host为app-link。

hostname

在编排服务时,为每一个服务指定一个hostname,在其他服务中可以使用hostname访问对应的服务。测试host为app。

服务发现

容器服务基于HAProxy实现的一套服务间HTTP访问和负载均衡的机制。测试host为app.local。

SLB

传统的负载均衡服务,有HTTP和TCP两种监听模式。测试中HTTP SLB host为192.168.1.10,TCP SLB host为192.168.1.40。

分别通过这四种网络访问目标机器上的http服务接口/ok并测试延迟(latency)和吞吐量(throughput)。

测试工具

  • httping:测试延迟
  • ab(apache benchmarking tool):测试吞吐量

ubuntu 下安装:

  apt-get install httping
  apt-get install apache2-utils

延迟测试:

  1. link:
  httping -c100 -i 0.01 -g 'http://app-link/ok'
  ...
  connected to 172.18.1.3:80 (121 bytes), seq=96 time=0.45 ms
  connected to 172.18.1.3:80 (121 bytes), seq=97 time=0.46 ms
  connected to 172.18.1.3:80 (121 bytes), seq=98 time=0.42 ms
  connected to 172.18.1.3:80 (121 bytes), seq=99 time=1.63 ms
  --- http://app-link/ok ping statistics ---
  100 connects, 100 ok, 0.00% failed, time 1050ms
  round-trip min/avg/max = 0.4/0.5/1.6 ms
  1. hostname
  httping -c100 -i 0.01 -g 'http://app/ok'
  ...
  connected to 172.18.1.3:80 (121 bytes), seq=96 time=10.80 ms
  connected to 172.18.1.3:80 (121 bytes), seq=97 time=0.43 ms
  connected to 172.18.1.3:80 (121 bytes), seq=98 time=0.44 ms
  connected to 172.18.1.3:80 (121 bytes), seq=99 time=0.46 ms
  --- http://app/ok ping statistics ---
  100 connects, 100 ok, 0.00% failed, time 1073ms
  round-trip min/avg/max = 0.4/0.7/10.8 ms
  1. 服务发现
  httping -c100 -i 0.01 -g 'http://app.local/ok'
  ...
  connected to 172.18.1.2:80 (219 bytes), seq=96 time=0.69 ms
  connected to 172.18.1.2:80 (219 bytes), seq=97 time=0.67 ms
  connected to 172.18.1.2:80 (219 bytes), seq=98 time=0.74 ms
  connected to 172.18.1.2:80 (219 bytes), seq=99 time=0.65 ms
  --- http://app.local/ok ping statistics ---
  100 connects, 100 ok, 0.00% failed, time 1090ms
  round-trip min/avg/max = 0.6/0.9/6.0 ms
  1. HTTP SLB
  httping -c100 -i 0.01 -g 'http://192.168.1.10/ok'
  ...
  connected to 192.168.1.10:80 (140 bytes), seq=96 time=1.19 ms
  connected to 192.168.1.10:80 (140 bytes), seq=97 time=1.08 ms
  connected to 192.168.1.10:80 (140 bytes), seq=98 time=1.15 ms
  connected to 192.168.1.10:80 (140 bytes), seq=99 time=1.30 ms
  --- http://192.168.1.10/ok ping statistics ---
  100 connects, 100 ok, 0.00% failed, time 1123ms
  round-trip min/avg/max = 1.0/1.2/2.9 ms
  1. TCP SLB
  httping -c100 -i 0.01 -g 'http://192.168.1.40/ok'
  ...
  connected to 192.168.1.40:80 (121 bytes), seq=96 time=1.18 ms
  connected to 192.168.1.40:80 (121 bytes), seq=97 time=1.25 ms
  connected to 192.168.1.40:80 (121 bytes), seq=98 time=1.06 ms
  connected to 192.168.1.40:80 (121 bytes), seq=99 time=1.34 ms
  --- http://192.168.1.40/ok ping statistics ---
  100 connects, 100 ok, 0.00% failed, time 1137ms
  round-trip min/avg/max = 1.0/1.3/2.7 ms

测试结果

测试了100次HEAD请求,平均时延如下表:

访问方式 延时(ms)
docker link 0.5
hostname 0.7
服务发现 0.9
HTTP SLB 1.2
TCP SLB 1.3

吞吐量测试:

  1. link
  ab -lkc 10000 -n 10000 'http://app-link/ok'
  Concurrency Level:      10000
  Time taken for tests:   0.864 seconds
  Complete requests:      10000
  Failed requests:        0
  Keep-Alive requests:    10000
  Total transferred:      2020000 bytes
  HTML transferred:       610000 bytes
  Requests per second:    11571.74 [#/sec](mean)
  Time per request:       864.174 [ms](mean)
  Time per request:       0.086 [ms](mean, across all concurrent requests)
  Transfer rate:          2282.71 [Kbytes/sec] received
  1. hostname
  ab -lkc 10000 -n 10000 'http://app/ok'
  Concurrency Level:      10000
  Time taken for tests:   1.055 seconds
  Complete requests:      10000
  Failed requests:        0
  Keep-Alive requests:    10000
  Total transferred:      2020000 bytes
  HTML transferred:       610000 bytes
  Requests per second:    9476.49 [#/sec](mean)
  Time per request:       1055.243 [ms](mean)
  Time per request:       0.106 [ms](mean, across all concurrent requests)
  Transfer rate:          1869.39 [Kbytes/sec] received
  1. 服务发现
  ab -lkc 10000 -n 10000 'http://app.local/ok'
  Concurrency Level:      10000
  Time taken for tests:   4.276 seconds
  Complete requests:      10000
  Failed requests:        0
  Keep-Alive requests:    10000
  Total transferred:      3000000 bytes
  HTML transferred:       610000 bytes
  Requests per second:    2338.60 [#/sec](mean)
  Time per request:       4276.066 [ms](mean)
  Time per request:       0.428 [ms](mean, across all concurrent requests)
  Transfer rate:          685.14 [Kbytes/sec] received
  1. HTTP SLB
  ab -lkc 10000 -n 10000 'http://192.168.1.10/ok'
  Concurrency Level:      10000
  Time taken for tests:   6.308 seconds
  Complete requests:      10000
  Failed requests:        0
  Non-2xx responses:      580
  Keep-Alive requests:    10000
  Total transferred:      2141800 bytes
  HTML transferred:       732380 bytes
  Requests per second:    1585.41 [#/sec](mean)
  Time per request:       6307.517 [ms](mean)
  Time per request:       0.631 [ms](mean, across all concurrent requests)
  Transfer rate:          331.60 [Kbytes/sec] received

同时10000个并发请求,有580个请求SLB nginx返回了504错误,以下为response。

  <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
  <html>
  <head><title>504 Gateway Time-out</title></head>
  <body bgcolor="white">
  <h1>504 Gateway Time-out</h1>
  <p>The gateway did not receive a timely response from the upstream server or application.</body>
  </html>

  WARNING: Response code not 2xx (504)
  1. TCP SLB
  ab -lkc 10000 -n 10000 'http://192.168.1.40/ok'
  Concurrency Level:      10000
  Time taken for tests:   1.891 seconds
  Complete requests:      10000
  Failed requests:        0
  Keep-Alive requests:    10000
  Total transferred:      2020000 bytes
  HTML transferred:       610000 bytes
  Requests per second:    5287.14 [#/sec](mean)
  Time per request:       1891.383 [ms](mean)
  Time per request:       0.189 [ms](mean, across all concurrent requests)
  Transfer rate:          1042.97 [Kbytes/sec] received

测试结果

并发请求10000次,每秒处理的请求数如下表:

访问方式 吞吐量(RPS)
docker link 11571.74
hostname 9476.49
服务发现 2338.60
HTTP SLB 1585.41
TCP SLB 5287.14

结论:

  1. 从数据上看,使用docker link机制访问服务,无论是延迟和吞吐量都是最好的,hostname方式其次
  2. 同是 HTTP 模式的服务发现和HTTP SLB,性能最差
  3. HTTP SLB的并发性能似乎并不理想,10000个请求有5.8%的请求返回了504 Gateway错误

问题:

虽然docker link和hostname网络性能最佳,但不清楚其负载能力如何。测试中我们发现hostname方式是具有负载能力的,不过在官方帮助文档中,hostname访问方式被放在『不具备负载均衡能力的访问方式』中,而且被描述为『能做到一定的负载均衡的作用』。可见阿里云并没有强调其负载能力。如果在生产环境中使用,负载均衡能力也是相当重要的一个指标。

最后,这两个问题还需要向阿里云进一步确认:

  1. link和hostname模式的负载能力到底如何?
  2. 对于具备负载衡量能力、HTTP模式,内网使用这三个要求,是否有推荐使用的网络模式?
相关实践学习
使用ACS算力快速搭建生成式会话应用
阿里云容器计算服务 ACS(Container Compute Service)以Kubernetes为使用界面,采用Serverless形态提供弹性的算力资源,使您轻松高效运行容器应用。本文将指导您如何通过ACS控制台及ACS集群证书在ACS集群中快速部署并公开一个容器化生成式AI会话应用,并监控应用的运行情况。
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
4月前
|
存储 运维 监控
云服务运行安全创新标杆:阿里云飞天洛神云网络子系统“齐天”再次斩获奖项
阿里云“超大规模云计算网络一体化运行管理平台——齐天系统”凭借卓越的技术创新与实践成果,荣获“云服务运行安全创新成果奖”,同时,齐天团队负责人吕彪获评“全栈型”专家认证。
|
1月前
|
存储 Kubernetes 网络安全
关于阿里云 Kubernetes 容器服务(ACK)添加镜像仓库的快速说明
本文介绍了在中国大陆地区因网络限制无法正常拉取 Docker 镜像的解决方案。作者所在的阿里云 Kubernetes 集群使用的是较旧版本的 containerd(1.2x),且无法直接通过 SSH 修改节点配置,因此采用了一种无需更改 Kubernetes 配置文件的方法。通过为 `docker.io` 添加 containerd 的镜像源,并使用脚本自动修改 containerd 配置文件中的路径错误(将错误的 `cert.d` 改为 `certs.d`),最终实现了通过多个镜像站点拉取镜像。作者还提供了一个可重复运行的脚本,用于动态配置镜像源。虽然该方案能缓解镜像拉取问题,
217 2
|
6月前
|
供应链 安全 网络协议
|
6月前
|
边缘计算 安全 算法
阿里云CDN:构建全球化智能加速网络的数字高速公路
阿里云CDN构建全球化智能加速网络,拥有2800多个边缘节点覆盖67个国家,实现毫秒级网络延迟。其三级节点拓扑结构与智能路由系统,结合流量预测模型,确保高命中率。全栈式加速技术包括QUIC协议优化和Brotli压缩算法,保障安全与性能。五层防御机制有效抵御攻击,行业解决方案涵盖视频、物联网及游戏等领域,支持新兴AR/VR与元宇宙需求,持续推动数字内容分发技术边界。
415 13
|
5月前
|
人工智能 算法 异构计算
阿里云基础网络技术5篇论文入选全球网络顶会NSDI
近日,阿里云基础网络技术5篇论文被NSDI 2025主会录用。研究涵盖大模型训练网络故障诊断、仿真、容器网络性能诊断、CDN流控算法智能选择及GPU解耦推理优化等领域。其中,《Evolution of Aegis》提出增强现有体系+训练过程感知的两阶段演进路线,显著降低故障诊断耗时;《SimAI》实现高精度大模型集群训练模拟;《Learning Production-Optimized Congestion Control Selection》通过AliCCS优化CDN拥塞控制;《Prism》设计全新GPU解耦推理方案;《ScalaCN》解决容器化RDMA场景性能问题。
199 7
阿里云基础网络技术5篇论文入选全球网络顶会NSDI
|
5月前
|
canal 负载均衡 智能网卡
阿里云洛神云网络论文入选SIGCOMM'25主会,相关实习生岗位火热招聘中
阿里云飞天洛神云网络的两项核心技术Nezha和Hermes被SIGCOMM 2025主会录用。Nezha通过计算网络解耦实现vSwitch池化架构,大幅提升网络性能;Hermes则提出用户态引导I/O事件通知框架,优化L7负载均衡。这两项技术突破解决了云网络中的关键问题,展现了阿里云在网络领域的领先实力。
822 2
|
6月前
|
人工智能 运维 监控
阿里云携手神州灵云打造云内网络性能监测标杆 斩获中国信通院高质量数字化转型十大案例——金保信“云内网络可观测”方案树立云原生运维新范式
2025年,金保信社保卡有限公司联合阿里云与神州灵云申报的《云内网络性能可观测解决方案》入选高质量数字化转型典型案例。该方案基于阿里云飞天企业版,融合云原生引流技术和流量“染色”专利,解决云内运维难题,实现主动预警和精准观测,将故障排查时间从数小时缩短至15分钟,助力企业降本增效,形成可跨行业复制的数字化转型方法论。
294 6
|
10月前
|
SQL 安全 网络安全
网络安全与信息安全:知识分享####
【10月更文挑战第21天】 随着数字化时代的快速发展,网络安全和信息安全已成为个人和企业不可忽视的关键问题。本文将探讨网络安全漏洞、加密技术以及安全意识的重要性,并提供一些实用的建议,帮助读者提高自身的网络安全防护能力。 ####
231 17
|
10月前
|
SQL 安全 网络安全
网络安全与信息安全:关于网络安全漏洞、加密技术、安全意识等方面的知识分享
随着互联网的普及,网络安全问题日益突出。本文将从网络安全漏洞、加密技术和安全意识三个方面进行探讨,旨在提高读者对网络安全的认识和防范能力。通过分析常见的网络安全漏洞,介绍加密技术的基本原理和应用,以及强调安全意识的重要性,帮助读者更好地保护自己的网络信息安全。
185 10

相关产品

  • 容器计算服务
  • 容器服务Kubernetes版