FoxPro 客户端频繁数据库连接性能问题的分析和诊断

 

XXX系统中的XXX功能用户反应很慢，但是通过使用Profiler截取到的一系列的存储过程执行速度很快都在0.1秒级别附近，并无明显的性能瓶颈，无法重现性能问题。为了重现问题，使用LoadRunner中的ODBC协议对这个功能进行了录制，脚本中记录了所有ODBC级别的语句，通过运行5个并发用户的数据，可以看到分配单一些列操作过程的平均响应时间为76秒，而单独的查询按钮的响应也达到了22秒，说明系统的确存在较严重的性能问题。

    脚本录制完成后，首先对存储过程进行排查，对查询过程中的几个存储过程进行事务标识和命名，计算他们单独的处理时间，结果运行测试后发现它们的运行速度都极快，都在0.1，0.2秒显然不构成瓶颈。而脚本中除了存储过程的执行就是对数据库的连接操作包括开连接关连接等操作，通过在脚本编辑程序中进行回放，发现很多“卡”的情况都发生在建立数据库连接的语句上，为查明问题是否发生在建立连接的语句上，从中抽取出6个建立连接的语句并建立事务，分别命名为con1--con6,5个并发用户发现起平均响应时间居然接近0.6秒，而分配单操作总共有近100个建立数据库连接语句，这样说只是建立连接就要消耗将近60秒而总的响应时间也不过76秒。这说明系统的性能问题的根本原因就在频繁的建立和关闭数据库连接上。

    通过对程序进行分析，发现程序中每执行一个存储的确都会打开和关闭一次数据库连接。为确定是否的确为连接问题，我们将程序中数据库的连接从每次执行一个存储过程执行一组打开和关闭语句的形式，改为共享连接，并通过界面进行测试。在压力测试工具中同时有5个并发用户是，使用原来的程序执行一次查询需要30秒，而使用共享连接的方式仅需要5秒左右。

 

   以下为具体的性能测试数据，其中的con1-con6代表从100个连接语句中选取的其中6个来统计时间。

 

 

 

Transaction Summary

 

Transactions:

Total Passed: 1,507

Total Failed: 6

Total Stopped: 0

Average Response Time

 

Transaction Name	SLA Status	Minimum	Average	Maximum	Std. Deviation	90 Percent	Pass	Fail	Stop
con1		0.094	0.661	3.746	0.687	0.892	94	0	0
con2		0.142	0.617	3.772	0.613	0.847	94	0	0
con3		0.158	0.615	3.882	0.64	0.876	94	0	0
con4		0.142	0.631	3.122	0.617	0.925	94	0	0
con5		0.173	0.69	3.75	0.756	0.973	94	0	0
con6		0.149	0.718	7.566	0.964	0.798	94	0	0
Action_Transaction		35.79	76.718	133.555	20.327	105.684	92	2	0
点击查询		9.174	22.298	42.034	7.339	31.697	92	2	0
up_query_brandSeasons		0.016	0.11	1.504	0.17	0.159	94	0	0
up_query_dsshCompNew		0.031	0.124	1.329	0.151	0.173	94	0	0
up_query_shopGroupTypes		0.016	0.09	0.204	0.045	0.157	94	0	0
up_query_warehouseInfo		0.031	0.137	1.462	0.198	0.177	94	0	0
vuser_end_Transaction		0	0	0	0	0	3	2	0
vuser_init_Transaction		42.346	44.859	52.35	3.776	52.35	5	0	0

 

Service Level Agreement Legend:

Pass

Fail

No Data

 

 

 

1.