我以为福建移动BOSS系统做的一个小规模的性能测试为例,谈谈我在数据分析中的一些经验。测试用例,模式如下图。
一台Linux模拟Browser(简称browser)向主机SUN发 HTTP请求,SUN上启动Apache Web Server将请求交给FCGI程序。FCGI程序作为TE节点CC1(简称fcgi)的客户进程发起TE事务,经GT1名字服务向CC2 (简称svr_cc)发送一个分支,CC2 上服务嵌套经GT1名字服务向ACCTFZ(在HP上,简称svr_ac)发送一个分支。
测试3种压力情况,即10browser/10fcgi/5svr_cc服务进程/2svr_ac服务进程,20browser/20fcgi /10svr_cc服务进程/2svr_ac服务进程,30browser/20fcgi/10svr_cc服务进程/2svr_ac服务进程。
一.记录数据。
各个部分的应用程序在程序中关键地方记录时间,精确到微秒(毫秒也可以),并按一定格式写入日志文件。这样可以并计算相同应用相临时间点之间的平均时间差(编程序分析日志文件或用excel导入)。有了时间差,才能分析出整个系统性能的瓶颈(处理慢的环节)。下面给出一个fcgi进程(也是TE客户端进程)的日志文件片段。
[19:21:32.628.512] begin_tpbegin
[19:21:32.628.833] end_tpbegin
[19:21:32.628.944] begin_tpsetbranch
[19:21:32.629.053] end_tpsetbranch
[19:21:32.629.487] begin_tpcall
[19:21:37.102.996] end_tpcall
[19:21:37.103.806] begin_tpcommit
[19:21:37.432.253] end_tpcommit
[19:21:40.405.345] begin_tpbegin
[19:21:40.405.532] end_tpbegin
[19:21:40.405.639] begin_tpsetbranch
[19:21:40.405.742] end_tpsetbranch
[19:21:40.406.175] begin_tpcall
[19:21:46.732.888] end_tpcall
[19:21:46.733.650] begin_tpcommit
[19:21:46.832.538] end_tpcommit
第一个字段是时间点时间,第二个字段是该时间点描述串,两个字段用空格间隔。从这个文件可以看出,fcgi进程是循环处理业务的。 begin_tpbegin处开始一笔业务,begin_tpcall和end_tpcall之间是TE_tpcall()发起请求到收到应答的时间,begin_tpbegin和end_tpbegin之间是TE_tpcommit()发起提交到收到提交应答的时间。而end_tpcommit到 begin_tpcall是fcgi进程从一笔业务结束到开始下一笔业务的时间,在这里也就是fcgi进程从Web Server获取HTTP请求的时间。
从这种格式的原始数据文件可以编程序计算出相临时间点之间的时间差,并可以计算出所有交易的平均时间差。也可以用excel打开这种格式的原始数据文件,按空格分隔各列,读入excel后就可以使用excel提供的函数(入SEC()函数从hh:mm:ss时间格式换算成秒)和公式计算时间差和平均值,以及产生图表等等。事实证明excel的功能是十分强大和方便的。
二.误差的判断和排除。
根据原始数据统计出的3种压力情况下fcgi各点时间如下。10_10_5_2(ms) | 20_20_10_2(ms) | 30_20_10_2(ms) | ||
TPC(笔/秒) | 2.16967 | 2.28571 | 2.21911 | |
fcgi | receive from fcgi | 343 | 931 | 1676 |
tpcall | 4096 | 7614 | 8067 | |
tpcommit | 176 | 204 | 205 | |
total_fcgi | 4615 | 8749 | 9731 |
比较10_10_5_2和20_20_10_2,由于20_20_10_2在SUN主机上启动fcgi进程和svr_cc服务进程数都比 10_10_5_2多,SUN上的压力也较大,因此receive from fcgi的时间也较大是合理的。比较20_20_10_2和30_20_10_2,2在SUN主机上,压力没有变化,仅是有HTTP请求的排队(因为 browser进程比fcgi进程多),SUN上的压力应基本一样,而receive from fcgi的时间有较大的差别是不合理的。考虑到在测30_20_10_2并发时有失败业务,怀疑可能由于browser上加给web Server过大造成失败。这次性能测试主要测试系统正常(业务正常,压力情况是预计压力情况)时的系统情况,而在有业务失败时往往有些前端进程工作不正常,不能对后台造成预期的压力,这时取平均值可能会造成较大误差。
原文转自:http://www.uml.org.cn/Test/200505265.htm