網站維修完畢！終於找出導致Drupal後台(管理介面)存取變慢的原因。

不知為何？前些日子覺得吶喊‧網的反應速度變慢了，尤其是在後台管理介面作網站調整時，簡直慢到令人無法忍受。

習慣性地在網上搜尋了一下，發現似乎不少Drupal的使用者都遇到類似的問題：進入後台的模組管理介面時頁面出現的反應變慢甚至出現HTTP 500錯誤或沒有回應。

原因眾說紛紜，大致歸類為兩種：

一種說法是硬體設備的問題

• CPU不夠力或是執行php的記憶體不足 - Drupal 內容管理框架因為功能龐大，且後台持續在運行著 Cron，所以幾乎比 Gallery2 這類網路相簿管理程式還耗電腦資源，若是CPU負荷超載或是php運行環境把記憶體耗盡了，回應速度就會變得很慢甚至終止。

另一種說法是軟體設定的問題(這類說法就多了！)

• 預設安裝的數據庫類型 - Drupal 原先是設計使用 MyISAM 的，後來為了加強寫入效能，更改了其中幾筆為 InnoDB 類型，但是全新安裝 Drupal 時將會使用數據庫預設的類型，若是使用了 InnoDB，網站在存取的時候會比 MyISAM 慢一些。
• 在Drupal上安裝的某些模組出了問題，也會拖慢整體速度。
• 伺服器及作業系統的影響，據說以單機設定來說，在Linux作業系統上運行lighttpd網頁伺服器會比Windows+IIS快。
• 伺服器設定(譬如rewrite規則)錯誤。
• 所使用Drupal版本存在的臭蟲。

找到這麼多種"傳說"，卻都不是造成吶喊‧網變慢的原因。我很清楚這台機器的效能，硬體絕對不會是問題的所在；因為存放本站的這台伺服器現在就在我的腳邊，裡裡外外都是自己組裝、自己管理，乃正港的私服器(實體單機不對外開放)，如果最近我不曾作過啥更動而家裡又沒遭小偷，硬體方面就不應該有任何變數。

於是就從軟體設定方面著手，先檢查了數據庫資料的完整性，確定沒問題之後，嘗試關閉一些模組並且把它們從目錄移除(因為 Drupal 在每次進入模組管理介面時會自動掃描模組目錄，無論該模組是否被啟動，都會被載入模組列表)，只留下 Drupal 的核心模組，結果不見好轉；沒轍！只好走下下策，把整個資料轉換成 MyISAM，也沒有效果；重新另裝了一個 Drupal，全新基本安裝居然還是一樣緩慢，那麼問題應該不在 Drupal 本身了！

昨晚特別冷，外面氣溫攝氏-13度，也許因為中央暖氣開得較大，所以空氣乾燥，晚上有些睡不著，爬起來泡杯薑茶喝喝，靜夜之中隱隱約約聽到運行資料庫的那顆猛禽傳出只有在頻繁讀寫資料時才會發出的噪音，一看時間，正好是零點十五分，那是我設定的 Cron 正在執行，可是這以往只會發出幾秒鐘都不到的噪音居然持續了一盞茶的時間，這著實有些古怪！馬上進入伺服器檢視，發現原來是防火牆作祟，把每一筆 php 執行請求都過濾一次，那難怪 Cron 會拖這麼久了，重設規則，把這筆過濾取消，手動再執行 Cron 一次，這回果然順暢了！打開工作站，試著登入 Drupal 後台，哇！終於回到從前的速度，瞬間開啟！

導致這次事件的元兇竟然是出在防火牆的規則！記得不久前曾更新過防火牆，並更新的規則，大約從那時開始，背景動作頻繁的 Drupal 就一直被阻擋，所以整個網站速度才會變慢。這真是冤枉啊，拉著手剎車，就算是保時捷也開不快啊！

最後用"聽"的找出問題的所在，更是令人意想不到！