关于“持久的数据库连接”

　　

　　关于数据库连接的分配，多进程模型（如 Apache ）还存在一个问题。这个问题与我以前讲过的 PHP 脚本的不持久特性是相伴相生的。请先看看下图。

　　你所见的这幅图从一个由数据库驱动的动态 web 应用的角度说明了 Apache/PHP 解决方案是怎样工作并处理访问请求的。你可能注意到了，正如上文提到的一样，每一个 Apache 子进程一次处理一个单独的客户端连接。由于 PHP 脚本是单独由处理访问 PHP 生成文档的请求的每一个子进程来解释的，每一个进程均必须建立其独立的查询数据库的连接。

　　由于 PHP 脚本没有持久性，数据库连接在每次脚本运行时都必须打开和关闭。尤其对于那些被频繁访问的站点来说，在连接上浪费的时间可能会导致巨大的性能损失

　　为了避免这种情况， PHP 开发商也许会采用持久的数据库连接方式，使访问请求处理完毕和 PHP 脚本执行结束之后仍保持打开状态。

　　但是，在 PHP 环境中采用持久的连接方式和传统意义上的连接 “ 池 ” 方式并不相同。在 PHP 环境中，当一个持久的连接被子进程打开后，不需要再耗费额外的连接时间，就能够重用该连接。但是要指出的是，只有通过同一个子进程才能重用它。由于该连接是由特定的进程打开的，因此，即使打开它的子进程处于空闲状态，不用处理任何的请求，此连接也保持着对其的附着状态。事实上，即便是该子进程又继续处理另一个非 PHP 请求，该数据库连接也不会关闭。

　　在持久的数据库连接的情况下，我们观察到的实际上还是与前面所讲相同的子进程与 HTTP keepalive 请求的 1 ： 1 映射比率。但是，在当前情况下，数据库连接将会一直维持打开状态，并贯穿在打开它的子进程的整个生命期中。

　　这种情形会导致打开的数据库连接过剩，从而使得占用的内存空间大小超过实际负载的需要。在某些环境里，这种数据库连接过剩在高负载情况下会使数据库达到连接数量的极限。这时，服务器将不再对更多的请求作出响应。用户可以把这种情况看作是应用服务器或 HTTP 服务器对数据库执行了一次拒绝服务攻击，从而使自己当机。