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

本文涉及的产品
容器镜像服务 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模式,内网使用这三个要求,是否有推荐使用的网络模式?
相关实践学习
巧用云服务器ECS制作节日贺卡
本场景带您体验如何在一台CentOS 7操作系统的ECS实例上,通过搭建web服务器,上传源码到web容器,制作节日贺卡网页。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
10天前
|
供应链 安全 Cloud Native
阿里云飞天企业版获【可信云·容器平台安全能力】先进级认证
阿里云飞天企业版容器系列产品获中国信息通信研究院【可信云·容器平台安全能力】先进级认证,这是飞天企业版容器产品获得《等保四级PaaS平台》和《 云原生安全配置基线规范V2.0》之后,本年度再一次获得行业权威认可,证明飞天企业版的容器解决方案具备符合行业标准的最高等级容器安全能力。
阿里云飞天企业版获【可信云·容器平台安全能力】先进级认证
|
1月前
|
人工智能 弹性计算 运维
ACK Edge与IDC:高效容器网络通信新突破
本文介绍如何基于ACK Edge以及高效的容器网络插件管理IDC进行容器化。
|
14天前
|
人工智能 运维 Kubernetes
阿里云容器服务AI助手2.0 - 新一代容器智能运维能力
2024年11月,阿里云容器服务团队进一步深度融合现有运维可观测体系,在场景上覆盖了K8s用户的全生命周期,正式推出升级版AI助手2.0,旨在更好地为用户使用和运维K8S保驾护航。
|
11天前
|
负载均衡 容灾 Cloud Native
云原生应用网关进阶:阿里云网络ALB Ingress 全能增强
在过去半年,ALB Ingress Controller推出了多项高级特性,包括支持AScript自定义脚本、慢启动、连接优雅中断等功能,增强了产品的灵活性和用户体验。此外,还推出了ingress2Albconfig工具,方便用户从Nginx Ingress迁移到ALB Ingress,以及通过Webhook服务实现更智能的配置校验,减少错误配置带来的影响。在容灾部署方面,支持了多集群网关,提高了系统的高可用性和容灾能力。这些改进旨在为用户提供更强大、更安全的云原生网关解决方案。
214 10
|
1月前
|
人工智能 运维 监控
阿里云ACK容器服务生产级可观测体系建设实践
本文整理自2024云栖大会冯诗淳(花名:行疾)的演讲,介绍了阿里云容器服务团队在生产级可观测体系建设方面的实践。冯诗淳详细阐述了容器化架构带来的挑战及解决方案,强调了可观测性对于构建稳健运维体系的重要性。文中提到,阿里云作为亚洲唯一蝉联全球领导者的容器管理平台,其可观测能力在多项关键评测中表现优异,支持AI、容器网络、存储等多个场景的高级容器可观测能力。此外,还介绍了阿里云容器服务在多云管理、成本优化等方面的最新进展,以及即将推出的ACK AI助手2.0,旨在通过智能引擎和专家诊断经验,简化异常数据查找,缩短故障响应时间。
阿里云ACK容器服务生产级可观测体系建设实践
|
19天前
|
Prometheus Kubernetes 监控
OpenAI故障复盘 - 阿里云容器服务与可观测产品如何保障大规模K8s集群稳定性
聚焦近日OpenAI的大规模K8s集群故障,介绍阿里云容器服务与可观测团队在大规模K8s场景下我们的建设与沉淀。以及分享对类似故障问题的应对方案:包括在K8s和Prometheus的高可用架构设计方面、事前事后的稳定性保障体系方面。
|
16天前
|
运维 供应链 安全
阿里云先知安全沙龙(武汉站) - 网络空间安全中的红蓝对抗实践
网络空间安全中的红蓝对抗场景通过模拟真实的攻防演练,帮助国家关键基础设施单位提升安全水平。具体案例包括快递单位、航空公司、一线城市及智能汽车品牌等,在演练中发现潜在攻击路径,有效识别和防范风险,确保系统稳定运行。演练涵盖情报收集、无差别攻击、针对性打击、稳固据点、横向渗透和控制目标等关键步骤,全面提升防护能力。
|
11天前
|
监控 安全 Cloud Native
阿里云容器服务&云安全中心团队荣获信通院“云原生安全标杆案例”奖
2024年12月24日,阿里云容器服务团队与云安全中心团队获得中国信息通信研究院「云原生安全标杆案例」奖。
|
18天前
|
存储 监控 安全
网络安全视角:从地域到账号的阿里云日志审计实践
日志审计的必要性在于其能够帮助企业和组织落实法律要求,打破信息孤岛和应对安全威胁。选择 SLS 下日志审计应用,一方面是选择国家网络安全专用认证的日志分析产品,另一方面可以快速帮助大型公司统一管理多组地域、多个账号的日志数据。除了在日志服务中存储、查看和分析日志外,还可通过报表分析和告警配置,主动发现潜在的安全威胁,增强云上资产安全。
|
1月前
|
人工智能 Cloud Native 调度
阿里云容器服务在AI智算场景的创新与实践
本文源自张凯在2024云栖大会的演讲,介绍了阿里云容器服务在AI智算领域的创新与实践。从2018年推出首个开源GPU容器共享调度方案至今,阿里云容器服务不断推进云原生AI的发展,包括增强GPU可观测性、实现多集群跨地域统一调度、优化大模型推理引擎部署、提供灵活的弹性伸缩策略等,旨在为客户提供高效、低成本的云原生AI解决方案。

相关产品

  • 容器计算服务