性能测试总结

时间:2022-12-22 21:47:17

    1.在测试代发工资的时候,当10个用户并发进行企业登记,当运行2分30秒左右后,weblogic服务断掉,原因:加解密API不能在线程里反复初始化算法库,解决方法:已修改API并增加初始化唯一互斥调用机制;

    2.在测试账户管家的时候,进行交易日志明细查询的可靠性测试,运行14小时后,然后用admin登录管理端,当双击“渠道类型明细报表”,出现这个的提示:Compilation of JSP File '/jsp/manageAccount/detailReport /channelDetail/queryChannelDetailCon.jsp' failed:
--------------------------------------------------------------------------------
 
__querychanneldetailcon.java:11:1: Could not write to .class file for 'jsp_servlet/_jsp/_manageaccount/_detailreport/_channeldetail/__querychanneldetailcon': /home/weblogic/bea/user_projects/domains/paybill/./servers/AdminServer/tmp/_WL_user/orgAccount/p9ep58/jsp_servlet/_jsp/_manageaccount/_detailreport/_channeldetail/__querychanneldetailcon.class (No such file or directory)
public final class __querychanneldetailcon extends  weblogic.servlet.jsp.JspBase  implements weblogic.servlet.jsp.StaleIndicator {
^------------------------------------------------------------------------------------------------------------------------------^,原因不详,连开发都没有找到原因,所以此bug延后解决。

    3.

[步骤]

1.在进行企业登记并发10个用户性能测试的时候后,然后打开数据库中的tb_contract_info表。
2.
3.

[结果]出现如附件图中的信息,其中两个字段的值为“null”。

[期望]应该显示正确的信息,不应该是“null”。

[备注]此bug没有一定的规律性,偶尔出现。

    4.性能测试跑复合交易

[步骤]
1.在测试过程中。
2.
3.

[结果]后台accmgr不时的跳出来“扫描数据库线异常终止,重启...
扫描数据库线异常终止,重启...
扫描数据库线异常终止,重启...
扫描数据库线异常终止,重启...
扫描数据库线异常终止,重启...
扫描数据库线异常终止,重启...
扫描数据库线异常终止,重启...
扫描数据库线异常终止,重启...
扫描数据库线异常终止,重启...
扫描数据库线异常终止,重启...
扫描数据库线异常终止,重启...
扫描数据库线异常终止,重启...
扫描数据库线异常终止,重启...
扫描数据库线异常终止,重启...
扫描数据库线异常终止,重启...”

[期望]应该没有这种异常数据跳出。

    5.新架构的可靠性测试

[步骤]
1.在并发复合交易的时候,在测试过程中查看数据库中系统返回消息。
2.
3.

[结果]有下面的异常数据 “连接host系统服务[accmgrcomm,32001]失败”、“通信故障,请到储蓄所查询”和“扣款交易:[来自储蓄主机]账户已全额止付[冲正交易:成功]”,在135719笔交易中有284笔这种异常数据,虽然出现这种异常数据,但是和储蓄主机的通信还是正常。

[期望]数据库中应该没有这284条异常数据。

    6.大数据量查询

[步骤]
1.当一天的交易有62943笔的时候,在管理端以admin用户登陆,在渠道交易明细报表进行查询,查询一天的交易。
2.
3.

[结果]出现“操作失败:远程连接出错,请与管理员联系”,而查不出所要的数据。

[期望]当数据量大的时候,应该可以在查询时间长点的条件下,查询到所需的数据。

开发处理方法:数据量大的时候,会出现操时情况.可调优tuxedo和weblogic .但意义不大,因为几万笔数据显示到浏览器上,会让浏览器down掉. 根本解决方法是要修改报表,改成分页.另外不调用tuxedo,直接对数据库操作

    7.性能测试发送复合交易

[步骤]
1.可靠性测试运行22小时后。
2.
3.

[结果]做通过储蓄通信机的交易,都提示“通信故障,请到储蓄所查询”而不能进行相应的交易。

[期望]应该可以进行交易

开发回复:框架问题,正在处理。

    8.性能测试10个用户并发

[步骤]
1.做同城本行汇款,10个用户并发运行4小时30分左右。
2.
3.

[结果]出现没有收到后台数据而失败,此时数据库中出现“通信故障,请到储蓄所查询”和“连接host系统服务[accmgrcomm,32001]失败”,此后再发送自助“同城本行”的信息时,能成功进行交易,此时lr中成功事务数为110305,而数据库中是110297。

[期望]数据库中应该不会出现此异常数据,lr中的事务数应该和数据库中的一致。

开发意见:由于储蓄通信机用的是旧框架,新框架已没有该问题,但是考虑目前要修改成新框架的工作量及影响较大,暂不修改。如后继业务无法满足时再考虑更换。

    9.性能测试发现,并发疲劳测试出错

[步骤]
1.用复合脚本给5个用户,一共25个用户进行并发15小时,然后查看后台数据库。
2.
3.

[结果]出现下面的错误,"连接host系统服务[accmgrcomm,32001]失败、通信故障,请到储蓄所查询”,此时附件为日志和,系统资源。

[期望]应该没有此异常信息,而且cpu有时候闲置很多,和刚开始发送闲置1%左右相差很多。

 

09:18:36          CPU     %user     %nice   %system   %iowait     %idle
09:18:37          all     15.52      0.00      3.88     11.58     69.02
09:18:38          all     14.48      0.00      5.06     12.36     68.10
09:18:39          all     20.54      0.00      6.30     13.17     59.99
09:18:40          all     18.21      0.00      7.32     14.46     60.01

09:18:40          CPU     %user     %nice   %system   %iowait     %idle
09:18:41          all     18.68      0.00      6.12     15.30     59.90
09:18:42          all     25.03      0.00      6.57     12.89     55.51
09:18:43          all     57.49      0.00     30.09      2.31     10.11
09:18:44          all     22.84      0.00     25.16      8.57     43.43

09:18:44          CPU     %user     %nice   %system   %iowait     %idle
09:18:45          all     18.94      0.00      4.62     10.25     66.19
09:18:46          all     16.02      0.00      5.38      9.51     69.09
Average:          all     22.78      0.00     10.05     11.04     56.13

09:20:48    kbmemfree kbmemused  %memused kbbuffers  kbcached kbswpfree kbswpused  %swpused  kbswpcad
09:20:49        16856   8291100     99.80      1356   2249136   5526248   2666892     32.55     71828
09:20:50        16216   8291740     99.80      1320   2249952   5526248   2666892     32.55     71828
09:20:51        16024   8291932     99.81      1232   2249520   5526248   2666892     32.55     71828
09:20:52        16792   8291164     99.80      1200   2249292   5526248   2666892     32.55     71828

09:20:52    kbmemfree kbmemused  %memused kbbuffers  kbcached kbswpfree kbswpused  %swpused  kbswpcad
09:20:53        16232   8291724     99.80      1228   2249784   5526248   2666892     32.55     71828
09:20:54        15344   8292612     99.82      1288   2251284   5526248   2666892     32.55     71828
09:20:55        19376   8288580     99.77      1336   2258520   5526248   2666892     32.55     71824
09:20:56        24944   8283012     99.70      1484   2267472   5526248   2666892     32.55     71824

09:20:56    kbmemfree kbmemused  %memused kbbuffers  kbcached kbswpfree kbswpused  %swpused  kbswpcad
09:20:57        15968   8291988     99.81      1516   2255220   5526248   2666892     32.55     71824
09:20:58        15328   8292628     99.82      1544   2248432   5526248   2666892     32.55     71824
Average:        17308   8290648     99.79      1350   2252861   5526248   2666892     32.55     71826

 

开发意见:该bug是框架组的旧程序所造成,需要后期统一考虑修改方案

    10.性能测试,地址查询

[步骤]
1.如附件图,录制地址查询脚本,然后用25个用户进行并发,运行1小时34分58秒后。
2.
3.

[结果]出现附件图中的错误而而停止,此时用ps -u front查看服务,此时前置的服务停止了。

[期望]应该不会停止。

开发意见:与公司框架组的架构有关系。请后继跟进该框架是否还有此问题。

    11.性能测试复合交易

[步骤]
1.在25个用户进行并发四个半小时后,此时可用内存为17424K左右,停止loadrunner,此时不发送交易,可用内存不增长,过了大约十分钟,可用内存为54808K左右,此时一直在此值徘徊,用stopbu和startbu重启服务后,此时可用内存为2207354K左右。
2.
3.

[结果]

[期望]当停止并发交易后,后台已用内存应该降下来,同时可用内存应该增加到重启服务后那个值,或接近此值。

用sar命令只能看到整个linux内存的占用情况,看不到具体的进程内存占用情况,此时用用ps --auxw查看,linux内存机制:因为linux空闲的内存, 会被系统当作缓冲区来使用,所以即使你不运行任何程序,长时间后用sar命令看内存的时候,也是显示99%,所以这次测试是失败的

 

    12.可靠行测试saving通信机,加密方式从加密变成了软加密,而不能进行交易,原因分析:可能由于内存泄虑,即其他程序改变了内存中的加密方式。

解决方法:由于原来实现加密的方式是读一次配置文件到内存,以后的交易就就直接在内存中读取,不再读加密配置文件,后来修改程序,每次交易都读配置文件,而不是保存在内存中,去内存中进行读写,问题得到解决。