背景：公司接到私有化项目部署，由于没有各个微服务的真实能力，往往项目经理拉会开发评估需要的资源，但是没有测试数据支撑，导致评估的资源往往到线上真实使用量高太多，客户经常抱怨给的服务器资源使用的并不多，所以组织这次压测，目的是得到各个微服务的能力及全链路合理的资源配比（以实时在线通话2000为例）。

什么阶段的公司搞全链路压测

微服务的架构。
    需要架构组，得有Mtrace的这种微服务RPC消息跟踪体系架构，能改中间件。
    各部门能配合全链路压测调试及部署，运维的机器资源部署。
    简单性能测试要通过，即单点的性能测试要没问题。
    有更高的技术追求。

什么时间搞全链路压测

压力小的白天就行，要错过高峰期，这也是得益于数据隔离，服务器隔离。
压力大的一般凌晨进行，要错过高峰期。

谁来搞

肯定不是测试，也不是一般的性能测试工程师和测试开发工程师，基本上是一个研发团队在搞。

据说美团的压测平台前身也是测试开发工程师搞的，推广的也不错，在美团趟出了一条压测的路，但是存在了不少有待改进的地方。后来种种原因，平台移交给了开发团队，现在看起来，平台的压测性能、可用性等各方面有了很大的提升。不是说测试开发的同学做不了，而是效率和速度确实还是有差距的。开发同学的效率和速度就是特别大的优势，能加班，可以快速的让产品成型并且快速迭代。

梳理服务

1.梳理某项目所有微服务，服务架构，实现方式，调用关系，线上环境的请求配比（后续做测试数据、编写测试脚本等需要）；

2.梳理服务间调用用到的协议，为后续压测工具选型最准备，本次压测设计到freeswitch、unimrcp、http、grpc协议，由于市面上没有哪款压测工具支撑上述各种协议，最终决定用locust压测，最大好处，能支持二次开发，可以自我实现各种需求

准备环境

1.根据需求量和原有的数据大概评估一下服务器，分析哪些服务耗内存，哪些耗cpu....

2.部署相关服务，监控（grafana + prometheus），部署需要的各种exporter (服务器、服务、中间件、locust等)，由于locust本身压测数据不是持久化，prometheus提供了exporter来收集locust压测数据后展示到grafana-参看以往的博文

3.6台服务器、近50个微服务

压测策略

1.先压出单个服务的能力（不限制QOS,被压服务和压测脚本单独部署）

2.根据单个服务的能力和各个微服务的QPS的比率关系，合理配比副本数

3.全链路压测，对资源使用进行微调

压测过程

1.由于压测涉及到大量的音频传输，先测试压测服务器的io读写速度

2.从最底层服务开始压测服务能力，不限制QOS，加大压力看QPS、响应时间、内存、cpu、磁盘io、网络io、各连接数...的使用情况,找到压力拐点为止。

3.压测次底层服务，优先增大依赖的服务能力（通过副本数或资源增大等），有些微服务只做了代理，能力太强，考虑用mock服务代替后面依赖的微服务（mock服务能力要考虑后面服务的真实能力，随机sleep一段时间）

4.重复2-3步骤，压出online核心服务的处理能力。

5.根据单服务的能力，分析2000在线通话对各个服务的资源使用情况，需要考虑全链路的压测场景，单位时间内几轮对话对请求影响比较大

遇到问题

1.测试发现，当压力上去time_wait的数量会持续增大，同时释放的速度又小于新创建连接的速度，就是导致time_wait状态持续过多，这样会导致部分连接无法创建，现象表现为电话打不通，通过修改tcp_max_tw_buckets=50000，tcp_fin_timeout=10s两个系统参数解决上述问题

2.有几个重要服务要占用大量rtp端口，当部署到同一台服务器上，会导致资源抢占厉害，分配的端口也可能给sipp和一些系统服务产生冲突导致无法注册，所以通过调整部署方式和可用端口段解决上面问题

3.压力上去后，某些中间件连接数不够，服务异常后因为无法连接而重启失败

4.某些微服务也是采用了容器里的默认参数，调整后能力大幅提升

5.ELK占用大量资源。。。。

6.。。。

压测结论

1.部署方式很重要

2.要善于结合系统参数进行调优（参考How Can I View and Modify Kernel Parameters of a Linux ECS?_Elastic Cloud Server_FAQs_Network Configurations_Others_HUAWEI CLOUD）

3待补充。。。

一次全链路压测-总结相关推荐

全链路压测体系建设方案的思考与实践
在阿里淘宝双11 的过程中,长期以来都是在生产环节做全链路压测的,通过实践我们发现在生产环境中做压测,实际上会和一个 IT 组织的结构.成熟度.流程等紧密相关,所以我们把全链路压测从简单的制作范围内 ...
高德全链路压测——语料智能化演进之路
背景高德地图作为日活过亿的国民级出行生活服务平台,承载着海量用户服务的是后台的超大规模集群.从用户角度,如果出问题,影响会很大.3机房异地部署造成线上环境复杂,链路复杂.在这样的条件下,如何避免因故 ...
全链路压测自动化实践
背景境内度假是一个低频.与节假日典型相关的业务,流量在节假日较平日会上涨五到十几倍,会给生产系统带来非常大的风险.因此,在2018年春节前,我们把整个境内度假业务接入了全链路压测,来系统性地评估容量 ...
罗辑思维在全链路压测方面的实践和工作笔记
业务的知名度越高,其背后技术团队承受的压力就越大.一旦出现技术问题,就有可能被放大,尤其是当服务的是对知识获取体验要求颇高的用户群体. 提供知识服务的罗辑思维主张"省时间的获取知识" ...
美团全链路压测自动化实践
境内度假是一个低频.与节假日典型相关的业务,流量在节假日较平日会上涨五到十几倍,会给生产系统带来非常大的风险.因此,在2018年春节前,基于美团基础的压测平台Quake,我们把整个境内度假业务接入了全 ...
有赞11·11：全链路压测方案设计与实施详解
2017年双十一即将来临,对于买家来说是一年一度的购物狂欢,可是对于电商公司的技术人员来说,却是一年一次的大考.如何用更少的预算完成指定当前业务规模的流量高峰,是技术的永恒主题. \\ 由InfoQ举 ...
小工匠聊架构-写给研发工程师的全链路压测
文章目录 Pre 全链路是怎么一回事儿为什么要全链路压测全链路压测前的准备工作压测环境监控工具(推荐pinpoint) 预埋数据和背景数据压测指标 & 压测场景压测工具压测环境 ...
“敏捷版”全链路压测
作者:子矜审核&校对:风云.雨芙编辑&排版:雯燕客户的故事全链路压测被誉为大促备战的 "核武器" ,如果之前有关注过阿里双 11 相关的技术总结,对 &qu ...
dubbo 服务压测_全链路压测资料汇总——业内大厂解决方案
最近忙于公司的全链路压测平台调研和技术规划文档输出工作,参考了全网能搜到的业内大厂的全链路压测方案,这里做个汇总,以及将个人认为可以落地的方案做一个关键点整理. 技术链接滴滴全链路压测解决之道阿里 ...
干货 | 应用性能提升 70%，探究 mPaaS 全链路压测的实现原理和实施路径
简介:全链路压测方案下,非加密场景下至少有 70% 的性能提升,加密场景下 10%的性能提升,并在 MGS 扩容完成后可实现大幅的性能提升,调优的结果远超预期. 业务背景随着移动开发行业的步入存量时 ...

一次全链路压测-总结