做了4个迭代的性能测试，在没有需求的情况下步步艰辛，把代码和框架独立开发从0到一万多行代码的测试工具（脚本），作为性能测试工具佼佼者Lr，我时而拿他作参考，山寨了它很多东西，同时带有很多疑问对它实现性能测试的原因渡过了为期3个月的性能测试之旅。以下是我对比测试脚本和LR所得出的详细问题：

　　1、如何计算每秒处理包的数量

　　我针对这个曾经研究了很久。在多线程的情况下，压服务器的时候，是专门建立一个线程去采集这些信息，还是说在每个线程里面实现这个时间。后来我采取了后者。因为在到达了某项瓶颈之后，这段时间的变化是很小但是也不能忽略了。

　　例如下面的伪代码1：

　　伪代码2：

　　第一种，是每个线程自己算时间，然后在point为true的时间内算出每秒的收到的包，然后把所有线程的包加起来。第二种是线程不做任何算法操作。让单独线程来做。第一种的好处是数值很准确，同时没有在关键点用了影响性能的锁。第二种则对总执行时间的统计很准确，但是里面用了锁。就2种来说一般第一种用比较多，但是假如在延时比较大的发包或者关注整体事件流用的过程中，第二种的算法比较准确些（注意有时候延时越小不代表压力越大）。这里我带有的疑问是，lr他是如何设定这个TPS的数字呢？是否2种结合还是只用了其中一种？

　　说到了锁，在很多性能测试中都会和数据库打交道。我们当然想建立n多线程去冲击数据库（无论数据库是不是被测系统），但是数据库本身能够接受的线程就是有限制，而且其限制很低，虽然我们在数据库的操作用线程锁是可以，但是造成个缺点是假如事件流很多，创建虚拟数据，和下发及时命令再带多并发的操作时，这个锁就会让很多线程（尤其是延时小的线程）会卡在某个事件流的点上，导致socket断了。也影响数据结果（因为不知道算出来数据是否有别的事件导致出现误差）。解决方法是尽量不影响测试的情况下把能做的数据库数据先做了，实时的数据库建议先在某个点做集合点，统计够了再做压力冲击。这里就用了Lr的集合点概念，注意的还是算平均值的开始和结束事件要抓准。

　　说到数据库，假如你的db知识不是很牛的话测试数据lr是个好首选，但是一些复杂情况下我们不是每种用例都适用Lr测试。这时候你需要非常清晰的了解你的测试需求。下面的伪代码：