做了4个迭代的性能测试,在没有需求的情况下步步艰辛,把代码和框架独立开发从0到一万多行代码的测试工具(脚本),作为性能测试工具佼佼者Lr,我时而拿他作参考,山寨了它很多东西,同时带有很多疑问对它实现性能测试的原因渡过了为期3个月的性能测试之旅.以下是我对比测试脚本和LR所得出的详细问题:
1. 如何计算每秒处理包的数量.
我针对这个曾经研究了很久.在多线程的情况下,压服务器的时候,是专门建立一个线程去采集这些信息,还是说在每个线程里面实现这个时间.后来我采取了后者.因为在到达了某项瓶颈之后,这段时间的变化是很小但是也不能忽略了.
例如下面的伪代码1:
EachThread:
BeginTime =
time.time()
Count = 0
While point:
If RevPackage() == true:
Count = Count + 1
EndTime =
time.time()
Runtime = BeginTime
– EndTime
EachsecondRpackage
= float(Count) / float (Runtime)
EachsecondRpackage = SumAll(EachsecondRpackage)
伪代码2:
Count = 0
EachThread:
global
Count
While point:
If RevPackage() == true:
加锁
Count = Count + 1
解锁
TraceThread:
Time.sleep(runtime)
EachsecondRpackage
= Count / runtime
第一种,是每个线程自己算时间,然后在point为true的时间内算出每秒的收到的包,然后把所有线程的包加起来.第二种是线程不做任何算法操作.让单独线程来做.第一种的好处是数值很准确,同时没有在关键点用了影响性能的锁.第二种则对总执行时间的统计很准确,但是里面用了锁.就2种来说一般第一种用比较多,但是假如在延时比较大的发包或者关注整体事件流用的过程中,第二种的算法比较准确些(注意有时候延时越小不代表压力越大).这里我带有的疑问是,lr他是如何设定这个TPS的数字呢?是否2种结合还是只用了其中一种?
说到了锁,在很多性能测试中都会和数据库打交道.我们当然想建立n多线程去冲击数据库(无论数据库是不是被测系统),但是数据库本身能够接受的线程就是有限制,而且其限制很低,虽然我们在数据库的操作用线程锁是可以,但是造成个缺点是假如事件流很多,创建虚拟数据,和下发及时命令再带多并发的操作时,这个锁就会让很多线程(尤其是延时小的线程)会卡在某个事件流的点上,导致socket断了.也影响数据结果(因为不知道算出来数据是否有别的事件导致出现误差).解决方法是尽量不影响测试的情况下把能做的数据库数据先做了,实时的数据库建议先在某个点做集合点,统计够了再做压力冲击.这里就用了Lr的集合点概念,注意的还是算平均值的开始和结束事件要抓准.
说到数据库,假如你的db知识不是很牛的话测试数据lr是个好首选,但是一些复杂情况下我们不是每种用例都适用Lr测试.这时候你需要非常清晰的了解你的测试需求.下面的伪代码:
Python:
for i in range(1000):
cursor.execute(SQL);
C++:
For (I = 0;i<1000 ;i++)
{
cursor.execute(SQL);
}
SQL:
FOR i IN 1 .. 1000 LOOP
(SQL)
commit;
END LOOP;
这里用了py和C++,还有数据库本身的循环,3种循环用的时间都是不一样.SQL的最快,C++其次,然后是PY,不同被测系统的需求用不同的方式测试性能,假如你直接测试数据库某个存储过程,则能用SQL就用SQL,或者其他语言调用的时候循环都要用SQL的,对比被测产品调用SQL的话,则拿其中一种语言对比调用被测产品和直接调用数据库的差别.对于LR的疑问它假如测试出很多SQL的性能指标后,到底它是如何解决我上面提到的问题呢?
说到循环,每次我们做完测试报告写完宣讲时,开发人员总会问这个瓶颈是产品的瓶颈,还是你测试脚本的瓶颈?所以作为测试用脚本语言当然是首选,但是脚本语言的效率不高是弱点,所以每次用脚本语言做多线程压力测试的时候,每个关键的循环尽量调用C++等效率高的语句来做,同时注意调用时间.LR这块其实用的时候偏事件流的方式做,所以像这种变态的压其实比较少.
说到多线程,这是我研究Lr比较多的一个地方.当我自己写脚本的时候经常会深入研究不同操作系统不同硬件对线程的利用率的影响,还有线程锁,和该不该配合队列,进程来做测试.当然理想是越多测试机做分布式,甚至用云台来做更好.但是现实情况你不仅仅考虑开多少个线程多少个测试机,而是说100个线程用1台机器跑,和用10台机器跑的差别,测试产品瓶颈首先要测试网络,系统的瓶颈.一台机器假如到达了50个线程和100个线程所出的吞吐量是一样的话,那么这台机器最佳启动线程是50个.我听说Lr有队列有线程有进程一起配合的情况下做制作并发测试.我也按照他的负载测试方式设计脚本,但是即使是云台也存在分析操作系统和硬件的弱点,假设lr在单台服务器做1000(假设数据)个并发(不考虑多条件)的话,它到底是怎么实现并发的?
