FoxPro 客户端频繁数据库连接性能问题的分析和诊断
2008-09-09 10:15
621 查看
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秒左右。
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
以下为具体的性能测试数据,其中的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 | <?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /> | 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.
相关文章推荐
- 【性能诊断】四、单功能场景的性能分析(RedGate,找到同一个客户端的并发请求被串行化问题)
- ora-12154 TNS问题(Oracle 客户端连接数据库异常)
- 故障分析:数据库一致性关闭缓慢问题诊断
- 频繁分配释放内存导致的性能问题的分析
- 频繁分配释放内存导致的性能问题的分析 --(附)malloc分配原理浅析 mmap关注焦点 如何优化分配内存
- Mycat连接数据库之后导致表名全小写的问题分析研究
- 频繁分配释放内存导致的性能问题的分析
- 解决oracle 客户端混乱造成OBIEE Client Administration不能连接数据库问题
- 分析诊断某省公司后台数据库Oracle 11g hang住问题
- 如何通过dba_hist_active_sess_history分析历史数据库性能问题
- 频繁分配释放内存导致的性能问题的分析
- 如何使用AWR报告来诊断数据库性能问题
- 故障分析:数据库一致性关闭缓慢问题诊断
- 我用的是stringgrid连接数据库!关于提高性能的问题
- 【性能诊断】十、性能问题综合分析(案例1,windbg、Network Monitor)
- 数据库服务性能诊断分析
- Oracle客户端工具连接数据库服务器问题汇总
- 【百度分享】频繁分配释放内存导致的性能问题的分析
- 频繁分配释放内存导致的性能问题的分析
- 如何分析发生在过去的数据库性能问题