優化Drupal

Drupal的核心架構非常簡潔并且非常靈活。然而，這種靈活性是有代價的。當啟用的子產品增 加時，處理一個請求的複雜度也會增加。這意味着将耗費更多的伺服器資源，必須實作一些政策，在一個站點日漸流行同時，來保證Drupal特有的簡明。通過 适當的配置，Drupal可以很容易的滿足使用者的需求。在本章中，我們将讨論性能（performance）和可更新性（scalability）。性能 指的是你的站點響應一個請求所用的時間。可更新性指的是你的系統可以同時處理多少個并發請求，通常用“請求數/秒”來度量。

找出瓶頸

如果你的網站運作性能達不到預期，第一步要做的就是分析問題所在。可能的原因包括web伺服器，作業系統，資料庫，和網絡。

初步追蹤

了解如何估算一個系統的性能和可更新性，即便是在出現大的問題時，它也能使你保持自信，進而 快速的隔離并找到系統的瓶頸。你可以借助于一些簡單的工具，通過詢問一些問題，來發現瓶頸。這裡給出了一種方式，用來分析一個存在嚴重性能問題的伺服器。 首先，我們需要知道性能是有哪些因素決定的，CPU，RAM，I/O，或者帶寬都是影響性能的因素。那麼你需要詢問以下問題：

CPU占用率達到最大了嗎？檢查CPU的使用情況，在Unix上你可以使用top，在 Windows上可以使用任務管理器，如果CPU占用率達到了100%，那麼你的任務就是找出是什麼程式占用了CPU。檢視程序清單，可以讓你了解到，是 不是web伺服器或者資料庫占用了處理器的大部分計算資源。這兩者都是可以解決的。

伺服器的RAM用完了沒有？在Unix上你可以使用top，在Windows上可以使用任務管理器，，來友善的檢查這一點。如果伺服器還有大量的空閑記憶體，那麼繼續下一個問題。如果伺服器用完了記憶體，你必須找出原因。

磁盤空間不足了嗎？檢查磁盤子系統，在Unix使用工具vmstat，在Windows下使 用性能監測器，如果可用磁盤不能滿足需求，同時又有大量空閑記憶體剩餘，那麼這就是一個I/O問題。可能的原因包括，記錄了大量的備援日志，對資料庫不恰當 的配置使得在磁盤上建立了許多臨時表，背景腳本的執行，對于一個需要大量寫操作的系統使用了一個不恰當的RAID級别，等等。

網絡帶寬用完了嗎？如果網絡帶寬用完了，那麼隻有兩種解決方案。一個是增加帶寬。另一個是對發送的資訊進行恰當的壓縮，進而發送更少的資訊。

Web伺服器用完了CPU

如果你的CPU占用率達到了100%，而根據程序清單顯示，是web伺服器消耗了大量的資源而不是資料庫（後面介紹），那麼你應該去減少web伺服器處理一個請求所耗費的資源。通常PHP代碼的執行就是罪魁禍首。

PHP最優化措施

在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是一個商業産品，而其它幾個則是免費的。

由于Drupal是一個需要大量資料庫操作的程式，是以一個opcode緩存不能作為一個單獨的解決方案，但它一個整體方案中的一部份。隻需要最小的努力，他人仍然可以代碼明顯的性能提升。

圖22-1 Alternative PHP Cache (APC)帶有一個接口，它能夠展示記憶體配置設定情況和目前緩存中的檔案。

剖析應用 

通常定制的代碼和子產品對于小規模的站點能夠很好的工作，如果将它放到大一點的站點上那麼就可 能成為站點的瓶頸。耗費CPU的代碼循環，占用記憶體的算法，還有大量的資料庫讀取，這些都可以通過剖析你的代碼來判定PHP在哪裡花費了大量時間，是以， 找到的關鍵點也就是你需要花費功夫進行調試的地方。更多關于PHP調試器和profiler的資訊，參看第21章。

有時候，即便是添加了opcode并且進行了代碼優化以後，你的web伺服器仍然不能處理這麼大的負載，那麼現在你就應該換一個更強大的伺服器，比如帶有更多CPU或者更快的CPU，或者更換應用架構，采用多個web伺服器。

Web伺服器用完了RAM

Web伺服器程序處理一個請求時，用到RAM的地方包括，web伺服器加載所有的子產品（比如 Apache的mime_module, rewrite_module,等等），還有PHP解釋器使用的記憶體。啟用的web伺服器和Drupal子產品越 多，處理單個請求耗費的RAM就越多。

因為RAM是個有限的資源，你應該決定對于每個請求配置設定多少記憶體，還有你的web伺服器能夠 同時處理多少個請求。為了知道平均為每個請求使用多少記憶體，可使用一個像Unix中top一樣的程式來檢視你的程序清單。在Apache中，可以使用指令 MaxClients來設定能夠處理的最大并發請求數。一個常見的錯誤認為，解決滿負荷的web伺服器的方案是增加MaxClients的值。這隻會讓問 題變得更加複雜，因為你将同時收到太多的請求。這意味着RAM将被耗盡，而你的伺服器将開始進行磁盤交換并開始不能響應請求。讓我們假定，你的web服務 器擁有2GB的記憶體，而每個Apache請求大約使用20MB（對于Unix，你可以使用top來檢查實際值；對于windows，則可以使用任務管理 器）。通過下面的公式，你可以為MaxClients計算出一個合适的值；你要記住你需要為你的作業系統和其它程序預留一定的記憶體：

2GB RAM / 20MB per process = 100 MaxClients

如果禁用了不需要的web伺服器子產品，并且優化了定制的子產品或者代碼以後，你的伺服器仍然耗 盡記憶體，那麼接下來你要做的是，確定資料庫和作業系統不是産生瓶頸的原因。如果是由它們引起的，那麼就添加更多的記憶體。如果不是，那麼問題就很簡單了，你 收到的請求比你能夠處理的請求要多；解決方案就是添加更多的web伺服器。

提示 由于Apache程序用到的記憶體，随着它的子程序增多，有逐漸增加的趨勢，通過将 MaxRequestsPerChild的值設得小一點比如300（實際的值依賴于你所處的環境）可以收回不少的記憶體。Apache将會更努力的工作來生 成新的子程序，而新的子程序比替換掉的子程序所需的記憶體要少一些，這樣你就可以使用較少的記憶體來處理更多的請求了。 MaxRequestsPerChild的預設值為0，這意味着程序永不過期。（譯者注：我不知道這裡講的什麼意思，沒學過）。

其它web伺服器最優化

為了讓你的web伺服器更有效的運作，這裡有一些其它的措施。

Apache最優化

Apache是Drupal最常用的web伺服器，通過對它進行調整可以獲得更高的性能。下面的部分将給出一些可以一試的方式，供大家參考。

mod_expires

這個Apache子產品将讓Drupal發出ExpiresHTTP頭部，在使用者的浏覽器中對靜态檔案緩存兩周，或者直到一個檔案存在新的版本為止。這适用于所有的圖檔，CSS和JavaScript 檔案，和其它靜态檔案。最終的結果是減少了帶寬，而伺服器需要發送的資訊将會更少一些。Drupal為了使用mod_expires，對其進行了預先配 置，一旦mod_expires可用，Drupal就會使用它。mod_expires的設定可以在Drupal的.htaccess檔案中找到。

# Requires mod_expires to be enabled.

<IfModule mod_expires.c>

# 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

</IfModule>

我們不能讓mod_expires緩存HTML内容，這是由于Drupal生成的HTML内容不全靜态的。這也是Drupal擁有自己的内部緩存系統的原因，内置緩存系統可對它的HTML輸出進行緩存（比如，頁面緩存）。

将.htaccess檔案中的指令遷移到httpd.conf

Drupal帶有兩個.htaccess檔案：一個位于Drupal根路徑，而另一個将被自 動建立，在你建立了用于存儲上傳檔案的目錄以後，通路Administer ? File system來設定目錄的位置，此時系統将為你自動建立一 個.htaccess檔案。在處理每個請求時，所有的.htaccess檔案都将被搜尋，讀取，和解析。相反，httpd.conf隻在Apache啟動 時才被讀取。Apache指令可以放在這兩種檔案中。如果你能夠控制你自己的伺服器，你應該将.htaccess檔案中的内容轉移到Apache主配置文 件（httpd.conf）中，并通過将AllowOverride設定為None來禁用在你的web伺服器根路徑下查找.htaccess檔案：

<Directory />

AllowOverride None

...

</Directory>

對于每個請求，這将阻止Apache通過周遊目錄樹來查找要執行的.htaccess檔案。這樣對于每個請求，Apache要做的工作就會有所減少，這樣它就能夠處理更多請求了。

其它的Web伺服器

還有另外一種選項，那就是使用其它伺服器來代替Apache。Benchmarks已經說明了這一點，例如，一般情況下，LightTPD web伺服器每秒能夠為Drupal處理更多的請求。更多詳細比較，參看http://buytaert.net/drupal-webserver-configurations-compared。

資料庫瓶頸

Drupal需要進行大量的資料庫操作，特别是對于登入的使用者和定制的子產品。資料庫常常會成為産生瓶頸的原因。這裡有一些基本的政策用于優化Drupal中資料庫的使用。

啟用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

目前查詢語句緩存的大小，可以通過MySQL的SHOW VARIABLES指令來檢視：

mysql>SHOW VARIABLES;

...

| query_cache_size               | 67108864

| query_cache_type               | ON

...

不斷的試驗查詢語句緩存的大小通常是有用的。緩存太小就意味着緩存了的查詢語句很快就會過 期。緩存太大就意味着搜尋一個緩存可能需要花費相對較長的時間；還有就是使用記憶體進行緩存比使用其它一些方式要好，就像有更多的web伺服器處 理，memcache或者作業系統的檔案緩存一樣。

提示 在Drupal中，通路“管理?報告?狀态報告”，點選MySQL版本号，來快速的檢視一些重要的MySQL變量值。你還可以在這一頁面檢視，查詢語句緩存是否被啟用了。

識别耗費資源的查詢

如果你想了解在生成一個給定頁面時都發生了什麼，那麼devel.module就會非常有 用。它擁有一個選項，用來顯示生成頁面所用到的所有查詢語句，以及每個查詢所用的時間。關于如何使用devel.module，以及通過EXPLAIN語 法來識别和優化資料庫查詢的更詳細的讨論，參看第21章。

找出執行時間過長的查詢的另一種方式是，在MySQL中啟用緩慢查詢日志。為了啟用它，需要在MySQL的配置選項檔案(my.cnf)中這樣設定：

# The MySQL server

[mysqld]

log-slow-queries

這會将超過10秒的查詢記錄到MySQL資料目錄中的日志檔案example.com-slow.log中去。你可以修改秒數以及日志的位置，如下面的代碼所示，這裡我們将緩慢查詢的最小值設為5秒：

# The MySQL server

[mysqld]

long_query_time = 5

log-slow-queries = /var/log/mysql/example-slow.log

識别耗費資源的頁面

為了找出哪些頁面是最耗費資源的，需要啟用Drupal自帶的統計子產品。盡管統計子產品增加了 你的伺服器的負擔（由于它将你的站點的通路統計記錄到了資料庫中），但它能夠幫助我們找出哪些頁面的通路量最大，對于這些頁面我們要進行更多的優化。它也 可以用來追蹤一個時期内生成頁面的總時間，你可以在“管理?報告?通路日志設定”中進行聲明。這可以用于識别耗費系統資源不能控制的網絡爬蟲，通過通路 “管理?報告?浏覽者排行”并點選 “禁止”來禁止該網絡爬蟲的通路。你還需要小心一點----有時候會很容易的禁用掉一個好的網絡爬蟲，就是能夠給你的 站點帶來通路量的爬蟲。在禁止網絡爬蟲以前，你一定要先檢查一下它的出處。

識别耗費資源的代碼

看一下下面耗費資源的代碼：

// Very expensive, silly way to get node titles. First we get the node IDs

// of all published nodes.

$sql = "SELECT n.nid FROM {node} n WHERE n.status = 1";

// We wrap our node query in db_rewrite_sql() so that node access is respected.

$result = db_rewrite_sql(db_query($sql));

// Now we do a node_load() on each individual node.

while ($data = db_fetch_object($result)) {

$node = node_load($data->nid);

// And save the titles.

$titles[$node->nid] = check_plain($node->title);

}

完全加載一個節點是一個耗費資源的操作：運作鈎子函數，通過子產品處理資料庫查詢來添加或者修 改節點，使用記憶體來在node_load()内部中緩存節點。如果你不依賴于其它子產品對節點的修改，直接對節點表進行你自己的查詢，速度将會更快一些。當 然這僅僅是一個例子，但是常常會遇到同樣的情景，也就是，許多時候資料是通過多個查詢來取回的，而實際上可以将多個查詢合并成一個簡單的查詢，或者不需要 加載整個節點，就可以完成所要的操作。

提示 Drupal擁有一個内部的緩存機制（使用了一個靜态變量），當在一個請求中多次加載 同一節點時就會使用這一機制。例如，如果調用了node_load(1)。節點1将被完全加載并被緩存。當在同一個web請求中再次調用 node_load(1)時，Drupal将會傳回前面使用相同節點ID加載節點的緩存結果。

優化表結構

另外，SQL的緩慢可能是由于，第3方子產品中SQL表的不良實作引起的。例如，列沒有索引的 話就會引起查詢緩慢。一個快速檢視MySQL如何執行查詢的方式是，從你的緩慢查詢日志中取出一個查詢，在其前面加上單詞EXPLAIN，然後将這個查詢 發給MySQL。那麼結果就是得到了一個顯示使用了哪些索引的表。更多資訊可參看MySQL的相關書籍。

手工緩存查詢語句

如果你必須要進行一些非常昂貴的查詢，那麼你可以在你的子產品中手工的将結果緩存起來。關于Drupal緩存API的更多詳細資訊，參看第15章。

将表類型從MyISAM改為InnoDB

MySQL有兩種常見的存儲引擎，通常也稱為表類型，它們是MyISAM 和InnoDB。Drupal預設使用的是MyISAM。

MyISAM使用表級别的鎖機制，而InnoDB使用行級别的鎖機制。鎖對于資料庫的完整性 非常重要；它可以避免兩個資料庫程序同時對同一資料進行更新操作。在實際中，鎖機制政策的不同意味着當你對MyISAM表進行寫操作時，整個表将被鎖住。 是以，在一個繁忙的Drupal站點上，當正在添加多個評論時，在插入一個新評論的同時所有的評論都不能被讀取。而在InnoDB上，這就不是一個問題， 因為隻有正被插入的那一行被鎖住了，進而允許其它的伺服器線程對其它各行繼續進行操作。然而，在MyISAM中，表的讀取更快，而資料維護和恢複工具更加 完善。MySQL表的存儲架構的更多資訊，參看http://dev.mysql.com/tech-resources/articles/storage-engine/part_1.html或者http://dev.mysql.com/doc/refman/5.1/en/storage-engines.html。

為了測試表級鎖是不是引起性能緩慢的原因，你可以通過在MySQL中檢查狀态變量Table_locks_immediate和Table_locks_waited的值來分析鎖的競争程度。

mysql> SHOW STATUS LIKE 'Table%';

+-----------------------+---------+

| Variable_name  | Value  |

+-----------------------+---------+

| Table_locks_immediate | 1151552  |

| Table_locks_waited  | 15324  |

+-----------------------+---------+

Table_locks_immediate指的是能夠立即獲得表級鎖的次數，而 Table_locks_waited指的是不能立即擷取表級鎖而需要等待的次數。如果Table_locks_waited的值比較大的話，并且你遇到 了性能問題，你可能希望将大表切分成小表；例如，你可以為一個定制子產品建立一個專有的緩存（cache）表，或者通過其它方式來減小表的大小， 或者降低 表級鎖指令調用的頻率。對于一些表，比如cache_*，Watchdog， 和 accesslog表，減少表的大小的一種方式是減少資料的生命周期。 使用Drupal的背景管理接口可以設定資料的生命周期。還有，確定每小時能夠運作一次cron，進而能夠不斷的清理這些表中的過期資料。

因為Drupal可以運作在不同的應用下，是以不可能一刀切的具體到某個表就應該使用某個表 引擎。然而，一般情況下，适合轉變為InnoDB的表有cache， watchdog， sessions， 和 accesslog 表。幸運的是， 轉變到InnoDB上非常簡單：

ALTER TABLE accesslog TYPE='InnoDB';

當然，這一轉變應該在站點下線并且已經為你的資料做好備份時進行，而且你也應該首先了解InnoDB表的不同特性。

注意 盡管資料庫API提供了db_lock_table() 和db_unlock_tables()函數供第3方子產品使用，但是Drupal6中，核心代碼并沒有使用LOCK TABLES指令。

關于MySQL的性能調優，參看http://www.day32.com/MySQL/的性能調優腳本，這裡提供了調整MySQL伺服器變量的建議。

Memcached（記憶體緩存）

當資料必須使用緩慢的裝置比如一個硬碟進行互動時，系統通常會遇到一個性能問題。如果你能夠 為資料繞過這一操作，而且你能夠承受得起資料的丢失（比如session資料），那會怎麼樣呢？此時我們可以使用memcached，這個系統将讀寫操作 都放到記憶體中進行。與本章中介紹了其它解決方案相比，Memcached更加複雜，而且更難設定。，但是當你的系統需要在可更新性方面有所提高時還是值得 考慮這一方案的。

Drupal有一個内置的資料庫緩存，用來緩存頁面，菜單，和其它Drupal資料，而 MySQL資料庫也能夠緩存常用查詢，但是當你的資料庫不堪重負時那會怎樣？你可以再買一台資料庫伺服器，或者你也可以直接将資料存放在記憶體中而不是存在 資料庫中，進而完全減輕資料庫的重負。Memcached庫(see http://www.danga.com/memcached/)和PECL Memcache PHP 擴充 (see http://pecl.php.net/package/memcache)都是專門為你實作這一點的工具。

Memcached系統将任意資料都儲存在随機存取的記憶體中，而且能夠迅速的從中讀取資料。 使用這種方式比任何使用磁盤的方式在性能上都要好一些。Memcached存儲對象并使用唯一的鍵來引用對象。哪些對象應該被放到memcached中， 這由程式員決定。對放到Memcached中的對象，Memcached不知對象的類型和本質；在它眼中，一切都是一堆等待取回的帶有鍵的比特資料。

系統的簡單性是它的優點。當為Drupal編寫支援memcached的代碼時，開發者可以 決定對引起瓶頸的主要因素進行緩存。這可能是，頻繁出現的資料庫查詢的查詢結果，比如路徑查找，或者是更複雜的構造比如完整加載的節點和分類詞彙，這些都 需要許多資料庫查詢和大量的PHP處理才能得到。

Drupal的memcache子產品和使用PECL Memcache接口的Drupal專有API可在Drupal的Memcache項目中找到(參看 http://drupal.org/project/memcache)。

特定于Drupal的最優化

大多數針對Drupal的最優化措施，都在軟體堆棧的其它層次中進行，也有一些專門針對Drupal本身的最優化措施，這也能使性能得到極大提升。

頁面緩存

有時，一些簡單的事情會被忽略掉，這也是為什麼需要再次提到它們的原因。Drupal擁有各 種内置的方式，它能夠通過為匿名使用者存儲和發送壓縮了的緩存頁面，來減少資料庫的負重。通過啟用這一緩存，你可以使用一個單獨的資料庫查詢來高效的讀取頁 面，而不是使用許多查詢來擷取頁面（在沒有緩存可用時就使用這種方式）。Drupal的緩存預設是禁用的，它可以在“管理?站點配置?性能”中配置。更多 資訊參看第15章。

帶寬最優化

這是“管理?站點配置?性能”頁面中的另一個性能優化措施，它能夠減少發送給伺服器的請求次 數。通過啟用 “優化CSS檔案”特性，Drupal将處理由modules建立的CSS檔案，壓縮它們，并将它們合并成一個檔案，放到你的“檔案系統路 徑”下的css目錄中。而 “優化JavaScript檔案”特性可以将多個JavaScript檔案合并成一個，放到你的“檔案系統路徑”下的js目錄中。這将減少每個頁面的HTTP請求數量，以及下載下傳頁面的整體大小。

當将一個頁面存儲在頁面緩存中時，Drupal将會檢查是否啟用了頁面壓縮。這個特性預設是 啟用的，你可以在“管理?站點配置?性能”将其禁用。如果啟用了的話，在頁面存儲到緩存中以前，Drupal将會檢查PHP的zlib擴充（如果存在的 話），并使用gzencode($data, 9, FORCE_GZIP)對頁面進行壓縮。當頁面從資料庫中取出時，Drupal判定目前浏 覽器是否支援gzip編碼，如果支援的話，它就簡單的将緩存資料傳回。否則，緩存資料在傳回以前，将會使用gzinflate()進行解壓處理。詳情請參 看includes/bootstrap.inc中的drupal_page_cache_header()。

調優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為子產品開發者提供了watchdog()函數，使用它可以将資訊寫入到日志中。Drupal内置了兩種方式，一種是記錄到資料庫中，另一種是記錄到syslog中。

嚴重性級别

調用watchdog()時，PHP代碼所使用的嚴重性級别符合RFC 3164，如表22-1所示。

表 22-1. Drupal看門狗系統的常量和嚴重性級别

Drupal 常量      整數     嚴重性級别

WATCHDOG_EMERG     0  緊急: 系統不可用

WATCHDOG_ALERT     1  警報: 需立即采取行動

WATCHDOG_CRITICAL  2  關鍵: 關鍵條件

WATCHDOG_ERROR     3  錯誤:錯誤條件

WATCHDOG_WARNING   4  警告: 警告條件

WATCHDOG_NOTICE    5  通知: 一般的，但是重要的消息

WATCHDOG_INFO      6  資訊: 一般消息

WATCHDOG_DEBUG     7  調試: 調試級别消息

記錄到資料庫中

Drupal内置的資料庫日志子產品預設是啟用的，可以在“管理?報告?最近的日志條目”檢視 日志條目。資料庫中的watchdog表，用來存儲日志資訊，如果不對其進行定期地清理的話，那麼它就會快速的膨脹。如果你發現watchdog表的大小 導緻了你的站點運作緩慢，你可以通過在“管理?站點配置?日志與報警 ?資料庫日志”裡來調整相關配置以減小它的大小。注意，對該設定的修改将在cron 下次運作時生效。不能定期的運作cron會使得watchdog表越來越大，進而為系統增加極大的負擔。

記錄到Syslog

Drupal核心自帶的syslog子產品，預設是禁用的，它使用PHP的syslog()函數将watchdog()的調用寫入到作業系統中。這一方式就繞開了資料庫日志子產品所需要的資料庫插入操作。

運作cron

盡管設定cron是Drupal安裝指令的第5步，但是它常被忽視，而這一忽視能夠給站點帶 來不小的麻煩。如果在一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 記錄意味着你将丢失所有的錯誤消息，它們可能訓示站點的問題所在。如果你想儲存這些資料，那麼在清空表watchdog以前，先對它進行備份。清空 sessions表會使目前已登入的使用者退出系統。

自動節流

Drupal在核心中包含了一個名為throttle.module的子產品。這一子產品通過對 目前線上使用者數量進行采樣來測量站點的負載，如果采樣顯示超過了管理者設定的極值，那麼它将關閉一些功能。在你配置一個站點時，最好啟用這一子產品，這樣當 一個頁面成為熱門話題并帶來極大的通路量時，它使你能夠應付這種局面。然而，節流閥子產品不是一個萬能藥。為了進行節流，該子產品本身會帶來不小的負擔。

轉自:http://hi.baidu.com/zf1315/item/3b75f8cd1394607189ad9ebd