记于一次写性能测试工具的经历

背景

最近接到一个需求，就是对我们的某个产品线进行压测，实际上主要还是看系统的稳定性，比如压个一晚上，看看系统是否稳定。基于这个需求，我专门去看了一些协程的知识，整个开发过程有了那么一点点的想法，作文以记之。

数据准备

要对接口做压测，很基本的一个前提，数据的准备必须要很充分。比如压一晚上，那么几万条数据你得准备好，用传统的Excel或者CSV的方式来做，那数据准备得搞死你，我之前面过一个小哥，他们准备一次压测，数据就要准备一周，要是其中某些数据做的被人破坏了，只能重新来过，整个过程非常痛苦。

• 以数据平台的方式来造数据

我们已经有了一个现成的数据平台，每次只要从这个数据平台啦数据就行了。

但是这里依然有一个问题，我们的平台并发量只有20，我在测试的时候拉取数据并发量太大就会导致数据丢失，因此在获取数据的时候，我必须要分批次的拉取数据，比如每次我只拉取10条数据保存在内存中。这样就导致了，如果每次要并发1000个请求，那么我就要先从数据平台拉取100次，然后才能往下请求，整个拉取过程中如果服务器出了点什么问题，就必须重来了。

• 性能建模

我们造数据的时候还要考虑到性能建模的问题。所谓的性能建模，也就是把生产的数据拉下来，按照一定的业务比例去造数据。比如生产上10%是成功的，%10是由于A原因导致失败的，%10是由于B原因导致失败的等等。这类数据也是需要在生成的时候去考虑的，能够配置化生成则最好。

• 业务流

涉及到业务流的接口也是非常的麻烦，尤其是业务流多的时候，比如我们信贷业务，如果要测一下还款的接口，那么就必须有授信和借款的数据，整体操作起来非常麻烦，要么就直接往数据库插数据，然后把下游给Mock掉，要么就真的去发一堆交易。

发送请求

发送请求这块我目前是用协程去做的，但是有一点问题，我做的是单进程单线程的协程，具体并发量有多大我也没有测试过，根据我统计的结果来看，响应时间是一直在递增的，所以统计的结果具体是否正确，这个必须要从服务端的角度来监控，并且并发量等内容还有待测试。理论上最好还是多进程带着协程一起玩，效果可能会好很多，这块不具体描述，主要是现阶段我也还没研究透，不便记录一些误导性的信息。

结果收集

结果收集这块我是分为公共字段和私有字段。

公共字段就是我自己有做的埋点的数据（非服务端埋点），主要是请求的耗时，返回码等信息

私有字段，大多是根据业务需要自定义的，比如授信交易有对应授信的字段，借款交易有对应借款的字段。

在压测执行完毕之后，所有结果都是保存在内存中，最终会根据一个模板来生成最终的测试报告。

关于结果收集这块，我建议最好还是由服务端来做。服务端的埋点数据精准度一定是高于发起端记录的数据，在发起端收集的报告仅限于参考，除了一些业务数据的记录是正确的，性能相关的记录或多或少都会有一些误差。

总结

所有跟性能相关的事情，都会比平时多几倍的工作量。从最初的数据准备开始，一直到最后的结果反馈，中间可做的事情非常多。如果整体要做成一个平台的话，难度非常大，不仅仅是脚本的灵活度要高，周边的支持也非常重要。

比如我们的数据平台，说句实话，有20的并发量，完全能满足我们日常工作中的需要，但是用来压测数据的生成，显然还是有些低了。如果要做一些性能建模，那么实现难度将会再上一个层次，或者说再兼容一下业务流？

其他支持包括独立的环境，独立的数据库，针对性能监控的埋点，外部接口的Mock，还有系统的监控这一整套体系的支持，可能需要开发和运维都一起参与进来。

路漫漫其修远兮，吾将上下而求索。