三月初，接到同事抛来一个性能测试任务，一个单接口的压测，背后涉及的业务我也熟悉，但他因为其他项目赶进度，只好交给了我。

起初我还真以为一个接口很简单，可是同事就只丢给我一个接口设计文档，其他什么也没有了。里面写的也非常简单，一大段的业务处理逻辑说明，
什么鸟用都没有，翻到下面对于性能方面的描述也说得不清不楚，特么指标公式、说明，一大份都是套用上一个项目的，连相关描述都没有改就得出
一个 TPS。(黑人摊手，what?)

这又是一个坑。没办法，靠他是不可能，只有自己出马搜集资料了。追到开发那边，要架构说明、需求说明等文档，开发来一句，这就是客户的一句话需求，
没什么文档。(what? what? what?) 没什么需求文档、没什么具体指标的活也敢接，我真是服了。

坑是接下了，但咱也不能像别人一样敷衍。找到具体的具体的开发人员，缠着他讲解了一下改接口后面的代码逻辑、相关环境的部署情况 (这个很重要),
以及这个接口的相关要求。好在开发还能提供一些有用的东西。压测环境已经部署，相关服务器配置情况也清楚了；功能测试方法第一轮已经完成，关键
功能点没有问题；性能指标与开发初步讨论后定了一个参考值；压测所需的数据可以直接从数据库提取，幸好可以重复不停的使用，不用造数据，免去了
麻烦；压测工具和监控工具按照自己熟悉的来选。

基本一切准备就绪，开始编写测试计划和压测方案。因为认为只是涉及一个接口，原本定为两周，可是没想到最后测了一个月左右（原因后面再解释）

压测方案也没花太多时间，找了一个以前做过的项目，套用了一下模板，很快就完成了。但要包含以下几个方面：测试环境 (软硬件)、性能指标、测试模型 (场景)、
监控模型、压力策略、准入准出和风险。

万事具备，干就完了！

说说这次的监控工具。当前服务器都是其它部门的人管理，基本不给管理员账号，临时找人搭建监控环境也来不及。在没有可视化界面帮助的情况下，使用命令工具
是最好的助手。于是赶紧申请叫人安装了几个常用的工具，其中一个是 arthas（阿尔萨斯）。说实话，到今年三月份以前，基本没听说过这个工具，在一次别人的公开课上听到这个工具，看别人介绍一些功能，还挺好用，上手也相对容易，于是决定此次压测用这个工具试试。

我主要是针对 arthas 的 trace 命令而安装的。以往想要查看某个运行繁忙的线程堆栈信息，操作过程比较麻烦。首先找到占用 CPU 最高的进程号，然后根据该进程号进一步
查看该进程下面哪个线程最繁忙，将线程转为十六进制，然后用 jstack 命令输出该进程的实时堆栈信息。
相关过程命令如下：

$ top -Hp <pid> # 查看某个进程下面线程的摘要信息，包括线程id，cpu占用，内存占用，虚拟内存，运行时间等
$ printf "%x\n" <tid> # 将线程ID转为16进制
$ jstack pid | grep tid -A # 打印进程中该线程的堆栈信息

这个操作过程相对繁琐，有时可能开几个窗口，来回切换，且堆栈信息打印出来后，是一整块内容，还需要一步一步的去查找某个类，再追进去。

换了 arthas 后，可以更加便捷的查找某个线程的堆栈信息，甚至直接查找到具体的类、方法的堆栈。

通过 trace 命令定位到具体的类、方法，系统会追踪该类下面相关调用方法的耗时以及堆栈信息。通过一步一步往下查找，能更深入快捷的定位到具体代码。

此次做的比较好的一点是，用了新的监控工具，分析问题后，查找原因的效率大大提高。不过也有些部分做的不是很好。

1. 没有提前要求开发做挡板服务。
   假如自己能力不够，无法 moke 相关服务，那就需要开发协助。与开发协调，将相关外部的调用影响降低到最低。此次的接口压测，有一个依赖性很强影响也挺大的服务
   调用，没有 moke 的情况下，响应时间能去到 20,30 多秒，moke 之后，能降到十秒以下。通过 moke 工具挡掉不相干的服务，能更加真实的测出接口的性能。做到后期剩下一周
   多，才要求开发弄一个简易的挡板服务，将重点关注在该测试的接口上。

2. 没有针对数据器进行监控。
   一直以来这块是我的弱点。此次接口调用，后台有挺多地方会进行数据库查询，而每次压测时，我都逃避了数据库的监控，只对应用服务器做监控。说到底，还是自己
   对数据库这块不熟悉。只能通过一些表面现象，对应的修改数据库连接池的配置。或者当表空间占用过高时，清除相关日志信息。这里提醒一点，若是压测过程中有大量
   的日志信息或其他信息写入数据库，要时刻关注表空间的变化，一旦相关表空间占满，容易引起超时异常的报错。

3. 其它杂事太多，分散了注意力。
   性能测试是一项繁琐，要来回频繁沟通交流的任务。若是执行期间，无法全力投入去执行，那必然很可能导致执行延期。这次接口压测，因其他同事要离职，不得已临时接了
   另外一个坑，于是两头兼顾，有很多时间本该跟开发讨论，分析问题，但都拿去执行其他任务。无法系统、完整的执行整个过程，很多东西都是临时学习，也没有什么记录。

虽然这次只是一个简单的单接口压测，但也学到了很多，同时也暴露一些明显的短板。

当你要解决的问题因你的短板无法支撑你从容的去应对问题时，那就是你抓狂的开始，那就是你要学习的开始，为了下次不再 “丢人现眼”。