第13章 池化与高速缓存
在任何一个数据库产品当中都会有些会遗憾的限制,其中之一就是即使是十分简单的查询也要付出足够的开销,这在PostgreSQL当中尤其明显。如果碰到一个复杂的连接查询,可能会觉得付出如此昂贵的开销代价是值得的。反之,仅仅从一个简单的表当中读取数据,那么打开一个数据库的连接以及等待查询的执行结果返回的开销与预先所估计的相差甚远了。
实际上减少这种类型开销的两种常见方法就是池化以及高速缓存,二者都会在本章中进行介绍。这种类型的软件通常都是数据库的外部应用程序,其安装设置相对复杂,并且其使用也较多依靠应用程序。因此,本章所讨论的重点是该技术的一般理论原理,而不是尝试去演示一个实际的例子。这当中的任何一个例子转化到实际的工作环境中不一定能够很好地被贯彻执行。
13.1 连接池
PostgreSQL并没有将数据库连接操作作为快速响应的高优先级的操作。每个连接都需要启动一个新的进程来处理与客户端之间的会话以及类似于pg_hba.conf
文件的认证实施即使是在牺牲速度的时候也要进行安全性及灵活性的优化,这是个开销巨大的操作。在这里假设是将用户运行一个耗时的操作与其连接所耗费的时间进行比较。
连接池是减少这种开销的解决方法之一。它位于数据库与应用程序的中间,其值通常被设置为100以下,作用是保证这些连接在任何时候都是处于打开状态。每当有新的请求被传入时,在连接池内的连接将被重新利用以响应请求。在PostgreSQL会话当中使用DISCARD ALL
命令去强制要求使用新的连接。而当客户端断开连接时,连接池管理器将会重置会话而不需要断开与数据库的连接,使其准备用于相应一个新的连接请求。
13.1.1 连接池计数
对连接池大小进行设置的基本思路是要有足够的连接以使用所有可用的资源,但事实上远远不止这些。能够使服务器连接饱和的合适大小在很多时候是依赖于CPU核心的数量、数据库有多大程度被缓存于内存当中以及基本磁盘的存取速度。一旦对服务器一直处于忙碌的状态视而不见,那么一味增加更多的连接数量只会造成服务器执行效率的降低。另外在其较好的服务于为数不多的连接时可能会造成强迫其在多个任务之间来回交换的状态。 ...
Get PostgreSQL 9.0性能调校 now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.