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

起初我还真以为一个接口很简单,可是同事就只丢给我一个接口设计文档,其他什么也没有了。里面写的也非常简单,一大段的业务处理逻辑说明,
什么鸟用都没有,翻到下面对于性能方面的描述也说得不清不楚,特么指标公式、说明,一大份都是套用上一个项目的,连相关描述都没有改就得出
一个 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. 其它杂事太多,分散了注意力。
    性能测试是一项繁琐,要来回频繁沟通交流的任务。若是执行期间,无法全力投入去执行,那必然很可能导致执行延期。这次接口压测,因其他同事要离职,不得已临时接了
    另外一个坑,于是两头兼顾,有很多时间本该跟开发讨论,分析问题,但都拿去执行其他任务。无法系统、完整的执行整个过程,很多东西都是临时学习,也没有什么记录。

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

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


↙↙↙阅读原文可查看相关链接,并与作者交流