特定于 Drupal 的最优化
大多数针对 Drupal 的最优化措施都在软件堆栈的其它层次中进行，也有一些专门针对 Drupal 本身的最优化措施，这也能使性能得到极大提升。
页面缓存
有时，一些简单的事情会被忽略掉，这也是为什么需要再提一次它们的原因。Drupal 拥有各种内置的方式，它能够通过为匿名用户存储和发送压缩了的缓存页面，来减少数据库的负重。通过启用这一缓存，你可以使用一个单独的数据库查询来高效的 读取页面，而不是使用许多查询来获取页面（在没有缓存可用时就使用这种方式）。Drupal 的缓存默认是禁用的，它可以在 Administer > Site configuration > Performance 中配置。更多信息参看第15章。
带宽最优化
这是 Administer > Site configuration > Performance 页面中的另一个性能优化措施，它能够减少发送给服务器的请求次数。通过启用“Aggregate and compress CSS files（聚合和压缩 CSS 文件）”特性，Drupal 将处理由 modules 创建的 CSS 文件，压缩它们，并将它们合并成一个文件。这将减少每个页面的 HTTP 请求数量，以及下载页面的整体大小。
调优 Sessions 表
Drupal 将用户会话保存到它的数据库中而不是文件中（参看第16章）。这意味着 Drupal 能够很容易的应用到多个服务器上，但是为了管理每个用户的会话信息它也增加了数据库的负担。如果一个站点每天有成千上万个用户，那么很容得就会看到这个表将会极速膨胀。
PHP 允许你控制多长时间清除一次旧的会话记录。Drupal 将这一配置放到了它的 settings.php 文件中：
ini_set(’session.gc_maxlifetime’, 200000); // 55 hours (in seconds)
垃圾收集系统运行周期的默认设置为大约两天多一点。这意味着如果用户两天内没有登录，那么它的会话将被删除。如果你的 sessions 表正在疯长，那么你将想要增加 PHP 的会话垃圾收集系统的运行频率。
ini_set(’session.gc_maxlifetime’, 86400); // 24 hours (in seconds)
ini_set(’session.cache_expire’, 1440); // 24 hours (in minutes)
当调整 session.gc_maxlifetime 时，最好也将 session.cache_expire 设为相同的值，session.cache_expire 用来控制缓存的会话页面的存活周期。注意 session.cache_expire 的值的单位为分钟。
管理已验证用户的访问
由于 Drupal 可以为匿名用户提供缓存了的页面，而匿名用户一般也不需要与 Drupal 进行交互，你可能想要较少用户登录停留的时间，或者更疯狂一点，一旦用户关闭他们的浏览器就将他们退出。通过调整 settings.php 文件中的 cookie 生存周期来做到这一点。在下面这行代码中，我们将它的值改为24小时：
ini_set(’session.cookie_lifetime’, 86400); // 24 hours (in seconds)
而在这里一旦用户关闭浏览我们就将他们登出。
ini_set(’session.cookie_lifetime’, 0); // When they close the browser.
settings.php 中的默认值（2,000,000秒）允许用户保持登录大约3周时间（在此期间会话垃圾收集系统不会将他们的会话记录从 sessions 表中删除）。
清除错误报告日志
Drupal 有一个内部的日志系统，位于 Administer > Logs > Recent log entries，如果他没有被定期地清除，那么它将会快速的膨胀。这一日志存放在 watchdog 表中。如果你发现 watchdog 表的大小引起你的站点运行缓慢，你可以通过在 Administer > Site configuration > Error reporting 里调整相关配置来减小它的大小。注意，对该设置的修改将在 cron 下次运行时生效。不能定期的运行 cron 会使得 watchdog 表越来越大，从而为系统增加加大的负担。
运行 cron
尽管它是 Drupal 安装指令的第5步，设定 cron 常被忽略，而这一疏忽能够给站点带来不小的麻烦。如果在一 Drupal 站点上没有运行 cron，那么数据库就会充满日志信息、过期的缓存数据、以及其它的统计数据，这些都是应该从系统中定期清除的。我们应该把它作为正常安装流程中的一部 份，及早的配置 cron，这是一个很好的实践经验。关于设定 cron 的更多信息，参看 Drupal 的 INSTALL.txt 文件中的步骤5。
提示：如果你处于一个非常特殊的环境下，在一个访问量很大的站点上 cron 却永远没有运行过或者它没有被充分的运行，你可以手工的进行一些属于 cron 管理的操作。你可以随时清空缓存表（TRUNCATE TABLE ‘cache’, TRUNCATE TABLE ‘cache_filter’, and TRUNCATE TABLE ‘cache_page’），而它将会重新构造自己。还有，在情急之时，你可以清空 watchdog 和 sessions 表来重新控制一个失控的 Drupal 站点。删除 watchdog 记录意味着你将丢失所有的错误消息，它们可能指示站点的问题所在。清空 sessions 表会使当前已登录的用户退出系统。如果你想保存这些数据，那么在清空 watchdog 表以前先对它进行备份。
自动节流
Drupal 在内核中包含了一个名为 throttle.module 的模块。这一模块通过对当前在线用户数量进行采样来测量站点的负载，如果采样显示超过了管理员设置的最小值，那么它将关闭一些功能。在你配置一个站点时， 最好启用这一模块，这样当一个页面成为热门话题并带来极大的访问量时，它使你能够应付这种局面。
启用节流阀模块
当你启用了节流阀模块，你将会注意到在模块管理页面多一个额外的一列复选框。也就是，除了选择是否启用一个模块以外，你还可以选择它能否被节流。被 节流意味着当 module_list() 返回了一列启用的模块时，由于访问量过大，启用了节流阀的模块将不被包含在内；被节流的模块此时将被禁用。
很明显，你将需要小心的选择你想对哪些模块进行节流。一般选择功能不重要但是耗费 CPU 时间或者许多数据库查询的模块。核心模块不能被节流（因为它们是 Drupal 正常运行所必需的），但是它们能在站点处于节流时，够理解节流并使用它们自己的措施用来减少处理时间。例如，区块模块不能被节流，但是独立的区块可以被节 流，如图22-2所示。
图22-2 当站点感受到一个大的负载时，它将不展示头部的搜索表单或者左栏中 Who’s new 和 Who’s online 区块，但是头部的以及链接和左栏里的 Navigation 和 User login 区块总被展示。
配置节流阀模块
为了使节流机制能够起作用，你必须为它提供一个阀值和一个采样频率。当启用了节流阀模块时，阀值可以在 Administer > Site configuration > Throttle 中设置。
设置阀值
可以输入两个阀值：匿名用户数和验证用户数。由于匿名用户占用的资源比验证用户小，所以匿名用户的阀值应该更高一些。实际值依赖于你的个人站点。用 户数必须是在一个给定的时间内测量的。这个时间周期在 Who’s online 区块中设置，并作为 Drupal 变量 user_block_seconds_online 存储起来。如果它没有被设置，那它默认为900秒（15分钟）。
设置采样频率
为了决定站点的负载量，从而决定是打开还是关闭节流机制，节流阀模块必须查询数据库。这位数据库服务器增加了额外的负担。使用 Auto-throttle probability limiter 来设置检查的频率（实际中有可能检查发生在一个给定请求上）。例如，选择20%，那么对于每5个请求就会采样一次。
使得模块和主题能够懂得节流（Throttle-Aware）
节流机制可能开着，也可能关闭。当编写你自己的模块和主题时，你可以响应节流阀的状态，例如：
// Get throttle status.
// We use module_invoke() instead of calling throttle_status() directly
// so this will still work when throttle.module is disabled.
$throttle = module_invoke(’throttle’, ’status’);
if (!$throttle) {
// Throttle is off.
// Do nonessential CPU-intensive task here.
}
提示：如果你拥有大量的多媒体文件，这些文件不重要但又必须作为主题的一部份被提供，当你的网站不堪重负时，你可以对这些文件进行节流来减少带宽的总量。
架构
Drupal 可用的架构就是那些其它的 LAMP-stack 软件，以及使得 Drupal 具有可升级性的技术。因此，我们将为你展示不同的架构，并主要讨论针对 Drupal 的技巧。
单个服务器
这是最简单的架构。Web 服务器和数据库运行在同一个服务器上。服务器可能是一个共享主机或者一个专用主机。尽管大多数 Drupal 站点能够在共享主机上很好的运转，如果期望具有一定的升级性的话，就应该把它放到专有主机上。在单主机架构下，配置非常简单，因为所有的东西都已设置好 了。同样的，web 服务器和数据库之间的通信非常快，这是由于不需要使用网络来传播数据所以避免了由此带来的时间延迟。很明显，如果使用多核处理器那就更好了，这样 web 服务器和数据库之间就不需要争抢处理器了。
独立的数据库服务器
如果数据库使你的瓶颈，那么你可能就需要一个独立的并且强大的数据库服务器。由于需要使用网络来发送请求，将会影响性能，但是可升级性将会提高。
注意：无论什么时候你在使用多个服务器，你都需要确保通过一个快速的本地网络将它们连接起来。
独立的数据库属晚期和 web 服务器集群
多个 web 服务器具有更好的容错性，并能处理更多的访问。集群所需的最小计算机数量是2个 web 服务器。还有，你需要一种方式用来在服务器之间切换流量。而当其中的一个机器不能工作室，集群中其余的机器能够处理整个负载。
负载均衡
负载均衡器能够将 web 请求分配到多个 web 服务器上。还有一些其它类型的负载均衡器用来分发其它的资源，比如硬盘和数据库，但我们将在后面讨论这些。在多个 web 服务器的情况下，当一个 web 服务器当掉或者维护时，负载均衡器允许 web 服务继续运行。
负载均衡器可分为两大类。软件负载均衡器非常便宜甚至免费，但是它的维护和管理费用随着时间的增长会逐渐的高于硬件负载均衡器。Linux Virtual Server （http://www.linuxvirtualserver.org/)是一个非常流行的 Linux 负载均衡器。硬件负载均衡器一般很昂贵，因为与基于软件的解决方案相比，它们包含了更高级的服务器切换算法和具有更好的可靠性。
除了负载均衡，多个服务器还带来了多个负面影响，主要是文件上传和保持代码能够跨服务器。
文件上传和同步
当 Drupal 运行在单个 web 服务器上时，上传的文件一般存储在 Drupal 的 files（文件）目录中。它的位置可在 Administer > Site configuration 里配置。对于多个 web 服务器，则需要避免下面的场景：
1. 一个用户在 web 服务器 A 上上传了一个文件；数据库被更新以反映这一情况。
2. 一个用户在 web 服务器 B 上查看一个页面时引用了这个新文件。文件未找到！
很明显，答案就是让文件也出现在 web 服务器 B 上。有多种方式。
使用 rsync
Rsync 程序是一个解决方案，它通过仅仅复制修改了的文件来保持两个目录间的通过。更多信息，参看 http://samba.anu.edu.au/rsync/。这种方式的不足是同步会带来延迟，还有所有上传了的文件都有多个副本（因此增加了存储成本）。
提示：如果你有很多文件并定期的调度 rsyncs，通过检查表 file 和 file_revisions，当文件为不修改时，不同步；文件被修改了，同步。
使用一个共享的固定的文件系统
与其在多个服务器间同步文件系统，你不如部署一个共享的固定的文件系统，它将文件存放在文件服务器上的一个独立的位置。接着，web 服务器可以使用一个协议比如网络文件系统（NFS）来安放文件。这种方式的优点有，能够很容易的添加廉价的 web 服务器，而资源将被集中存放在一个耐用的文件服务器上，它上面可以带有冗余存储系统比如 RAID 5。这个系统的主要缺点是，仅有一个失败点；如果你的服务器或者文件系统出了问题，那么就会影响整个站点，除非你也再创建一个文件服务器集群。
如果需要提供大量的多媒体文件，最好将这些文件存放在一个单独的服务器上，可以使用一个轻量级的服务器比如 LightTPD 或者 Tux，从而减轻你的 web 服务器的负担使得 Drupal 能够处理更多的请求。做到这一点的一个简单的方式是，在你的 web 服务器上使用一个重写（rewrite）规则，将到来的针对特定文件类型的所有请求重定向到静态服务器上。下面是 Apache 的重写（rewrite）规则的一个例子，它重写了所有针对 JPEG 文件的请求：
RewriteCond %{REQUEST_URI} ^/(.*.jpg)$ [NC]
RewriteRule .* http://static.example.com/%1 [R]
这种方式的不足是，web 服务器仍然需要处理额外的工作 — 将请求重定向到文件服务器上。一个改进的方案是，在 Drupal 内部重写所有的文件 URLs，这样 web 服务器就不再参与静态文件请求了。然而，现在，在 Drupal 内核里还没有一个简单的方式来进行修改。
超越单个文件系统
如果存储总量不断增长，以至于超过了单个文件系统能够承受的范围，你可以通过编写定制的代码来实现一个存储抽象层，从而满足需求。另一种选择是使用 一个外部的存储系统比如 Amazon 的 S3 服务。在编写本书时，Drupal 第3方模块库中的 fileapi 和 filesystem 模块正在努力解决这类应用（参看 http://drupal.org/project/fileapi 和 http://drupal.org/project/filesystem）。
多个数据库服务器
多个数据库服务器带来了额外的复杂性，因为数据将被重复插入和更新，或者数据库被分割到多个服务器中。
数据库复制
MySQL 中的数据库复制，一个单独的主数据库收到所有的写操作，然后这些写操作将被复制到一个或多个从数据库上。读操作可以在任何主数据库或者从数据库上进行。在一个多层架构中，从数据库也可以是主数据库。
在一个能够复制的数据库环境下运行 Drupal 的一个当前困难是，Drupal 不能区分读和写操作。然而，由于所有的数据库查询都要穿过数据库层，通过扫描查询中的关键字 ALTER、CREATE、DELETE、FLUSH、INSERT、LOCK、UPDATE 等等，也不难做到这一点，从而将查询发送给合适的数据库。通过在 http://drupal.org 搜索 replication 可以找到这种方式的一些例子。
数据库分割
由于 Drupal 可以处理多个数据库链接，为了增加你的数据库架构的可升级性，另一种策略是将一些表放在一个机子上的一个数据库中，将另一些表放到另一个机子上的不同数据 库中。例如，将所有的 cache 表分离到一个独立的机子上的独立的数据库中，对于所有使用这些表的查询，使用 Drupal 的表前缀机制来应用别名，从而提高你站点的可升级性。
总结
在本章，你学到以下几点：
- 如何发现性能瓶颈
- 如何优化一个 web 服务器
- 如何优化一个数据库
- 特定于 Drupal 的最优化
- 可能的多服务器架构
Loading ...