性能测试总结
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通信机，加密方式从加密变成了软加密，而不能进行交易，原因分析：可能由于内存泄虑，即其他程序改变了内存中的加密方式。
解决方法：由于原来实现加密的方式是读一次配置文件到内存，以后的交易就就直接在内存中读取，不再读加密配置文件，后来修改程序，每次交易都读配置文件，而不是保存在内存中，去内存中进行读写，问题得到解决。
