关键字：ASP.NET, Oracle, 数据库连接池, 性能瓶颈
摘 要：本文通过笔者所经历的一个案例，介绍Asp.net连接Oracle因连接池的问题造成的性能瓶颈的现象，以及解决的办法。
1 问题的发现
2006年下半年，笔者在山东临淄齐鲁石化驻地参与一个项目的开发。公司的另外一个项目《合同管理系统》正处于实施后期阶段。该项目采用.Net开发的B/S架构的系统，使用Oracle做后台数据库。先后两次发现，当在线用户较多的时候，客户端感觉服务系统反应很慢（多数用户报告在登录界面点击登录按钮后，一直处于等待状态，系统不再反应）。查看服务器使用情况，CPU和硬盘访问并不繁忙，内存占用也不是非常大；连接到数据库没有发现死锁，但是会话非常多，大约在110个左右。开始怀疑是数据库的进程（Processes）和会话（Sessions）设置的值较低（未安装时候的默认值，分别为170和150）。但是将这两个值扩大以后仍旧未解决问题。在第二次发现该问题的时候，我注意到虽然设置值较低，但是当前并未达到这两个值得上限；同时我也注意到该系统连接数据库的会话正好是100个，由此我联想到数据库连接池。
2 相关资料
查阅过vs.net 2003的帮助之后，在
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.2052/cpguide/html/cpconconnectionpoolingforsqlservernetdataprovider.htm，基本内容如下：
使用连接字符串关键字控制连接池
SqlConnection 对象的 ConnectionString 属性支持连接字符串键/值对，这些键/值对可用于调整连接池逻辑的行为。
下表描述了可用于调整连接池行为的 ConnectionString 值。
|
名称 |
默认值 |
说明 |
|
Connection Lifetime |
0 |
当连接返回到池中时，将对它的创建时间和当前时间进行比较，如果时间间隔超过由 Connection Lifetime 指定的值（以秒为单位），则会毁坏该连接。在聚集配置中可以使用它来强制在运行服务器和刚联机的服务器之间达到负载平衡。 如果值为零 (0)，则将使池连接具有最大的超时期限。 |
|
Connection Reset |
'true' |
确定在从池中移除数据库连接时是否将其重置。对于 Microsoft SQL Server 版本 7.0，如果设置为 false，将避免在获取连接时经历一个额外的往返过程，但必须注意的是连接状态（如数据库上下文）不会被重置。 |
|
Enlist |
'true' |
当为 true 时，如果存在事务上下文，池管理程序将自动在创建线程的当前事务上下文中登记连接。 |
|
Max Pool Size |
100 |
池中允许的最大连接数。 |
|
Min Pool Size |
0 |
池中维护的最小连接数。 |
|
Pooling |
'true' |
当为 true 时，将从相应的池中取出连接，或者在必要时创建连接并将其添加到相应的池中。 |
由此可见，ASP.NET连接数据库，数据库连接池默认是开启的，并且池中允许的最大连接数默认为100。由此基本可以确定，访问系统收到的阻碍时由于连接池已满造成的。
该页面中提到，如果连接池中的连接全部占用，系统会在连接池之外开启新的连接。这个说法有疑问，该问题在后面的会体积。
3 问题的确认
为了验证ASP.NET连接Oracle数据库时，连接池中的连接达到最大数，新的连接就需要等待连接池中的连接释放资源，我编写了一个测试页面，在页面装载的时候，首先打开10个连接，然后等待20秒钟后再关闭这些连接。随后使用测试机打开两个测试线程访问该测试页面，然后在浏览器中打开于这个测试页面使用相同连接字串的另外一个页面，发现后者的确需要等待测试线程访问的页面处理完毕之后才可以连接到数据库。
4 问题的解决
找到问题的症结所在，我们系统的连接数据库的字串，增加了Max Pool Size项，根据需要将其设置为200。同时修改了Oracle服务器的的会话（Sessions）和进程（Progresses）的值以满足连接会话的需要。
5 疑问
如前所述，资料中提及，如果连接池的连接全部占用，会创建新的连接。但是在采用默认连接池大小和设置为20个最大连接数的时候，连接池的所有连接全部占用，新的连接请求并没有开启新的连接会话，而是等待连接池中的连接释放。
但是连接池最大连接数设置为200个的时候，该系统的连接曾经一度超过200个上限，达210多个。由此可以判断超出的连接请求在连接池之外创建了新的连接会话，符合了资料中的论述。对此疑问，烦请知情者阐述一下自己的观点。
6 补充
在连接字串修改之后，原有的连接池会重新构建，这一特性是否可以在何种情况下应用？
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1358594
