缓存操作代码
定时清理不必要的数据库数据

定时清理不必要的数据库数据，给数据库瘦身

可以設定watchdog只保存几个個小時或几天，用cron固定清空，点开管理 » 报告>> 访问日志设置 ,设定一下几天后删除日志。cron的设置请看这关于drupal的cron（计划任务）

sun的网站用的是drupal6.8，用phpmyadmin观察了一下，accesslog（估计是访问日志了）blocks（看了一下，发现记录了好多以前设置的主题的信息，看来要少实验一些乱七八糟的主题），locales_source ，locales_target，search_index ，search_total ，watchdog ，这几个表数据很多。所以搜索能不要就不要了吧，一般小网站游客也不会在你的网站上搜索。一定要的话就设置一下关键字的大小。

 

清除错误报告日志

Drupal有一个内部的日志系统，位于t Administer ➤ Logs ➤ Recent log entries，如果他没有被定期地清除，那么它将会快速的膨胀。(在d6中应该是 admin/settings/logging/dblog 设置记录的行数 然后运行cron吧). 这一日志存放在watchdog表中。如果你发现watchdog表的大小引起你的站点运行缓慢，你可以通过在Administer ➤ Site configuration ➤ Error reporting里调整相关配置来减小它的大小。注意，对该设置的修改将在cron下次运行时生效。不能定期的运行cron会使得watchdog表越 来越大，从而为系统增加加大的负担。

专门针对Drupal本身优化

缓存操作代码

点管理 » 站点设置 >>性能 ，启用缓存(cache)会显著提高站点性能。
在Drupal中，由于PHP代码执行在处理一个请求中占了一大块，所以我们需要知道采取哪些措施才能加快这一进程，这一点非常重要。对编译后的PHP操作代码（opcodes）进行缓存，和剖析应用层来找出低效算法，能够带来重要的性能提升。

有两种方式可以减少执行PHP 代码所耗费的资源。很明显，一种是减少代码总量，可以通过禁用不必要的Drupal模块和编写高效的代码来达到这一点。另一种方式就是使用一个 opcode缓存。PHP对于每个请求，都会将所有代码解析并编译成一种中间形态，这种形态里包含了一系列的操作代码。添加一个opcode缓存可以让 PHP能够重用前面编译过的代码，这样就会跳过解析和编译。常见的opcode缓存有Alternative PHP Cache (http://pecl.php.net/package/APC), eAccelerator (http://eaccelerator.net), XCache (http://trac.lighttpd.net/xcache/), 和 Zend Platform (http://zend.com)。Zend是一个商业产品，而其它几个则是免费的

web服务器最优化
让Drupal发出过期的HTTP头部，在用户的浏览器中对静态文件缓存两周，或者直到存在一个文件的新版本为止。这是用于所有的图片，CSS和JavaScript文件，和其它静态文件。最终的结果是减少带宽，而服务器需要发送的信息将会更少一些。Drupal对于和mod_expires一同工作预先进行了配置，一旦mod_expires可用，Drupal就会使用它。mod_expires的设置可以在Drupal的.htaccess文件中找到。 # Requires mod_expires to be enabled. # Enable expirations. ExpiresActive On # Cache all files for 2 weeks after access (A). ExpiresDefault A1209600 # Do not cache dynamically generated pages. ExpiresByType text/html A1 我们不能让mod_expires缓存HTML内容，这是由于Drupal输出的HTML内容不总是静态的。这也是Drupal拥有自己的内部缓存系统的原因，内置缓存系统可对它的HTML输出进行缓存（比如，页面缓存）。
启用MySQL的查询语句缓存

MySQL 是Drupal最常用的数据库。它具有在内存中缓存常用查询语句的能力，这样一个给定的查询语句再次被调用时，MySQL将立即从缓存中将其返回。然而，在大多数MySQL中，这一特性默认是被禁用的。为了启用它，向你的MySQL配置选项文件添加下列代码；该文件的名称为my.cnf，它用来声明变量和你的MySQL服务器的行为（参看http://dev.mysql.com/doc/refman/5.1/en/option-files.html）。在这里，我们将查询语句缓存设为64MB：

# The MySQL server

[mysqld]

query_cache_size=64M

页面缓存

有时，一些简单的事情会被忽略掉，这也是为什么需要再提一次它们的原因。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有一个内部的日志系统，位于t Administer ➤ Logs ➤ Recent log entries，如果他没有被定期地清除，那么它将会快速的膨胀。(在d6中应该是 admin/settings/logging/dblog 设置记录的行数 然后运行cron吧).这一日志存放在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 当站点感受到一个大的负载时，它将不展示头部的搜索表单或者左栏中e “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.

}

提示 如果你拥有大量的多媒体文件，这些文件不重要但又必须作为主题的一部份被提供，当你的网站不堪重负时，你可以对这些文件进行节流来减少带宽的总量。