最近几天听到的最高频词汇可能就是“压测”了，今天聊一下这个
#结尾额外送一个两分钟#
也可能是最近述职的原因，也可能是我大优选热火朝天，上线项目太多，频繁的出现“压测”这个词，尤其很多项目对一些新同学也有这方面的诉求，我做过的系统很多，全链路压测系统也正好做过，有一些理解，希望能十分钟深入浅出的聊点内容出来。
如果有一种途径，能快速的让你技术水平上一个台阶，那一定是压测了。 什么时候做到了不压测那么你可能就是技术专家或架构师了。看到这里的同学可千万别停下来，继续看，别理解错了。
压测是通过对系统发起大量的输入请求，收集系统运行过程中的环境信息及返回信息的过程。他的目标是了解系统容量、寻找出系统瓶颈。
先解释为什么上边说是技术上一个台阶的捷径（所谓捷径也是不容易走的路）。从压测目标可以看到，越经验丰富的高水平研发，越是在系统设计之初，就能比较准确的预估出系统容量，也会清晰的知道自己设计的系统的瓶颈在哪里，甚至留好了快速扩容方案。
在任何的生产环境或场景中，公司是绝不会也不可能接受一个大型系统在实施之前不知道将来获取的这个系统的容量及瓶颈的，总不可能系统设计出来压测一下看看，容量不满足生产需要推倒重来吧？ 这损失的时间成本和资源投入都是不可接受的。所以这也是越大型、越重要的项目，越需要高阶的研发来带领。因为老板为结果负责，这就预设了老板们是不接受风险的。所以，同学们如果你什么时候不压测能达到这个目标，你就基本上是高阶研发了（为啥是“基本上”？）。
这里我们也应该了解，在个人视角多压测是为了将来不压测。但是在团队视角，尤其是高阶研发或者团队管理员视角来看，还是会强制要求项目上线压测的，这是为了降低成本（懒），毕竟系统迭代过程中，会有大量的初中阶研发参与，总有方案review缺失的，而又不想系统恶化的太明显或问题不能提前暴露出来。
压测目标说完了，再说一下手段。磨刀不误砍柴工，压测要有趁手的工具（wrk挺不错的，特殊逻辑还能方便的写压测插件），如果有特殊诉求，自己造个轮子也行，很简单，达成就是持续并发发送请求有结果收集统计即可。再有一种就是线上流量复制，然后测试环境重放压测，都差不多，更真实一些，但与自己造请求相比，可能测不到边界值特殊值的情况，参数分布会非常不匀均，有可能都落到热点数据或容易获取的数据上。还有与流量录制重放类似的一种压测，是生产环境缩容压测，这种压测也非常好，服务巡检之类的用起了就很舒服，也适合做生产环境的全链路压测（多个环境一起压测）巡检。
上边说了一些概念、目标及手段，再说一下过程。在过程中，一般是从小流量开始，压测的同学要关注环境变化，如CPU负载、内存使用、带宽情况，甚至业务内的指标如数据库使用呀、缓存命中率啊、外部依赖成功率延迟啊之类的。
然后逐步增加流量，关注的指标出现异常（瓶颈）就把环境信息记录下来，停止压测，分析原因，解决问题，再次循环这个步骤，直到所压测的目标系统达到预定的容量要求。系统容量大家一般用吞吐量来衡量，就是每秒系统完成任务的次数。
一般在生产中还会对系统要求“稳定性”，就是系统在达成目标吞吐量的同时，他的稳定性指标也应该符合预期，稳定性定义可以理解为方差，方差不能太大，一般关注的就是请求延时的分位数指标，比如TP999、TP9999等。
业务生产中，有时候还会顺带的做系统的输出结果可靠性验证。
至此，完成了系统的压测任务。
这次有丰富经验的老程序员要把同学们潜在的问题放在后边了!，如何做到不压测就能准确预估出来系统容量呢？（今日份十分钟赠送一个问题）
首先你要做到对自己设计的系统心中有数，涉及了那些流程和操作，每种操作的耗时预估都要清楚。比如你提供了一个HTTP服务，这个服务里查了一次远端Cache、未命中又查了一次MySQL，然后又有一次3000个元素双重循环的本地计算。
你要做的就是把压测环境记录清楚（CPU主频、核数、内存大小主频、机械磁盘还是SSD还有网卡大小等等），经常记录跨机房网络延迟、专线非专线延迟、跨多省域延迟这些信息，还要清楚的记录MySQL什么数据规模（条数、大小）什么样的查询（简单select、有无索引、返回大小、复合select）等等的耗时和相应硬件环境下MySQL的容量等等，其他的都做都类似。
这样经过一次次的压测实践，你会发现压测数据你大脑里都有了啊，这还压测啥？
老程序员再多说一句：压测一次要有压测一次实践的进步，别瞎测一下应付工作，应付的都是自己。别干或尽量少干没有成长的事情。
