11.3.4 性能结果量化分析
1．数据库死锁问题及相关解决建议
当执行100用户并发审批二种票场景时，Loadrunner提示100个审批事务全部成功通过，而通过应用查询，实际提交数目却为60个。Loadrunner出现“误判”是由于HTTP协议的本身的限制，由于HTTP协议的无状态特点，Loadrunner只能通过HTTP协议返回码来判断脚本是否执行成功，而不是在业务层次上做判断。
经排查，发现在并发负载下，提交审批二种票时，失败的页面上出现了如下错误信息：
信息：执行查询SQL语句时发生错误：[IBM][CLI Driver][DB2/AIX64] SQL0911N The current transaction has been rolled back because of a deadlock or timeout. Reason code "68". SQLSTATE=40001
[IBM][CLI Driver][DB2/AIX64] SQL0911N The current transaction has been rolled back because of a deadlock or timeout. Reason code "68". SQLSTATE=40001
从DB2的监控数据来看，在并发数目超过30后，lock time大大增加，超过10秒，最终导致死锁超时。
问题可能根源在：
（1）开发人员在提交sql语句，做update，insert等操作时，启用了排它锁，导致死锁。
（2）数据库的locktimeout参数设置过小。
在针对locktimeout参数做过优化调试后，成功提交数有所提升，但仍无法从根本上消除死锁问题的发生。因此，建议在应用程序jdbc层上修改代码，避免死锁发生，才是解决问题根本之道。
具体解决建议：
建议开发人员检查jdbc层上可能存在死锁语句，这有可能：
● 一次commit包含多条sql语句
● 涉及同时多表操作的sql语句
● 逻辑死锁
2．数据库表索引设计相关问题及解决建议
数据库在设计上存在如下两个问题：
（1）表设计存在大表风险
在测试过程中，发现工单和两票在做删除操作时，记录只是改变状态字段，而始终分别保存在USERID.T_GDMX_GD，USERID.T_LP_GZP，USERID.T_LP_ CZP表中。
这可能会导致在生产环境下，随着运行时间和用户数的增加，如上表数据记录越来越多，最终成为大表，引起查询性能的下降。一般，业界通常的解决类似问题的办法是另建备份表保存被删除的记录。
