由ICE 连接与浏览器“长”连接以至数据库连接池的一些想法

作为JEE Web程序开发人员，特别是使用过那些个SSH,亦或是SSI等这些框架的，早已对数据库数据源配置，以及其中配置常用连接池DBCP或是CP30等最为熟悉了。

也许我们也曾思考过，这个地方为什么要使用数据库连接池，以及不使用的话，有什么样的问题；或是干脆自己写出一个出来。

下面连接池内容来自网络

使用连接池的理由

JDBC是一套通用的Java语言与多种数据库（文件）通讯的标准API。大部分针对数据库服务器（例如Oracle,
MySQL等等）的JDBC实现都是基于TCP/IP连接的客户端-服务器端通讯方式。当我们需要执行一个数据库操作时，有下面三步：
1. 客户端与服务器之间建立一个数据库连接
2. 执行某种数据库操作
3. 断开连接
如果每次处理都要走上面的三步，则应用程序与数据库服务器都要将大量的时间和资源消耗在数据连接的断开与建立上。对于并发较大的系统，建立一次连接然后缓存起来连续使用，直到程序结束等情况下再释放连接，就能够将系统资源集中在对数据库操作的处理上，从而大大提高性能。通常情况下将数据连接的建立和断开委托给一种能够数据库连接池的组件或服务进行管理。而DBCP,
C3p0, Proxool等都是常用的开源的连接池组件。

数据库连接池

数据库连接是一种关键的有限的昂贵的资源，这一点在多用户的网页应用程序中体现得尤为突出。一个数据库连接对象均对应一个物理数据库连接，每次操作都打开一个物理连接，使用完都关闭连接，这样造成系统的 性能低下。 数据库连接池的解决方案是在应用程序启动时建立足够的数据库连接，并讲这些连接组成一个连接池(简单说：在一个“池”里放了好多半成品的数据库联接对象)，由应用程序动态地对池中的连接进行申请、使用和释放。对于多于连接池中连接数的并发请求，应该在请求队列中排队等待。并且应用程序可以根据池中连接的使用率，动态增加或减少池中的连接数。

连接池技术尽可能多地重用了消耗内存地资源，大大节省了内存，提高了服务器地服务效率，能够支持更多的客户服务。通过使用连接池，将大大提高程序运行效率，同时，我们可以通过其自身的管理机制来监视数据库连接的数量、使用情况等。
1) 最小连接数是连接池一直保持的数据库连接，所以如果应用程序对数据库连接的使用量不大，将会有大量的数据库连接资源被浪费；

2) 最大连接数是连接池能申请的最大连接数，如果数据库连接请求超过此数，后面的数据库连接请求将被加入到等待队列中，这会影响之后的数据库操作。

数据库连接池技术带来的优势

1． 资源重用

由于数据库连接得到重用，避免了频繁创建、释放连接引起的大量性能开销。在减少系统消耗的基础上，另一方面也增进了系统运行环境的平稳性（减少内存碎片以及数据库临时进程/线程的数量）。

2． 更快的系统响应速度

数据库连接池在初始化过程中，往往已经创建了若干数据库连接置于池中备用。此时连接的初始化工作均已完成。对于业务请求处理而言，直接利用现有可用连接，避免了数据库连接初始化和释放过程的时间开销，从而缩减了系统整体响应时间。

3． 新的资源分配手段

对于多应用共享同一数据库的系统而言，可在应用层通过数据库连接的配置，实现数据库连接池技术，几年钱也许还是个新鲜话题，对于目前的业务系统而言，如果设计中还没有考虑到连接池的应用，那么…….快在设计文档中加上这部分的内容吧。某一应用最大可用数据库连接数的限制，避免某一应用独占所有数据库资源。

4． 统一的连接管理，避免数据库连接泄漏

在较为完备的数据库连接池实现中，可根据预先的连接占用超时设定，强制收回被占用连接。从而避免了常规数据库连接操作中可能出现的资源泄漏。

连接数知多少

数据库连接池数

上述网络内容已经说的很明白了，理论上讲，服务端连接数应该配置很大，具体与使用的数据库以及操作系统相关。但作为使用的客户端系统，我们更多关注的是，客户端连接池配置多少算是合理的呢？有的人上来就来个800--1000不等，有的人说越大越好。等等。没有一个具体的答案。也有人说，这个需要根据客户端系统本身的情况，比如什么样的业务类型，逻辑处理时间（IO等待与整个处理时间比），系统负载情况。说到底就是在性能测试情况使其性能发挥至最好的情况下，调整出来的一个数值。恩，这个说法很正确，但缺少具体的指导。
我认为客户端系统配置参数，依据你的客户端使用的线程模型，IO模型，内存管理，等这些具体模型下，压力测试出来的场景参数。因为这些看似不相关的因素，其实实际运行情况来看，相互之间的影响很大，整个系统性能不能单单说受某个方面参数设置的影响，是一个整体的，综合的不断调整的过程。
说了这么多，貌似和标题内容跑远了。哈，既然我们这么熟悉连接池了。那我们有想过么，为什么每款浏览器下同一域名情况下，使用的长连接数目是几个或是默认不是太多呢？或是我们压根就还不是很清楚浏览器使用了多个连接来处理我们的请求呢？

浏览器连接数

对于这个问题，我想，应该从两个方面来考虑，一是作为我们这些使用浏览器的客户端来说，一次加载一个页面过程中，里面有多少CSS，JSS，图片等资源呢。也许很多，但现在在网络情况下，其实用不太多连接数，也足以应付我们人眼感知度，等待时间。但更为重要的是，我想应该是在服务端，因为站点一般要求要能处理较大并发用户数。所以如果每个人发一个请求加载一个页面，设置太多连接数，请求完，这些连接就OVER 了，（长连接暂不考虑）。这对服务端要求的并发用户数压力和连接管理等方面来说都是一个不小的挑战。

所以，浏览器默认使用几个连接是有道理的。

ICE连接数

因为项目中，目前是全部是使用默认。默认的就是客户端受到ACM 的管理。服务端ACM默认关闭。看了使用的API 也没发现特别的地方，得出结论就是目前使用中，使用的都是同一个连接(在连接不超时情况下)。（对每个客户端与服务端通信过程）。所以还需要改进才行。才能提高并发量。