跑快一點吧, Movable Type

不久前有提過, 因為我們家的部落格是架在 Movable Type 上, 而 Movable Type 又是 Perl 寫成的, 所以速度實在是快不到哪裡去. 每次貼完文章在等它重建的時候, 都會無聊到得開另一個視窗上上別的網站才等得下去.

Movable Type 的管理介面嚴格來說做得算相當不錯的, 但是反應速度太慢真的會影響到寫作的意願, Guava 也跟我抱怨過很多次, 說網站的速度慢到她不想寫寶寶日記.

顯然上次把後台資料庫換成 MySQL 這帖藥並沒有奏效, 我得想其它的方法.

我決定先試試把整個 VMWare 上的 Linux 虛擬機器搬到快一點的機器上. 現在用的機器只有 P3 1.1G 就算了, 記憶體只有 768MB, 我只能切 256MB 給 VMWare. 很少看到 Linux 的機器會真的動用到 swap partition 的, 但是這台機器只要 MT 一啟動 rebuild, 就會動到 swap.

老婆的新機器很不錯, 雖然不是 Core 2 Duo 的, 好歹也是 Pentium 4 3G, 最棒的是我那時候很豪氣地幫她裝了 2GB 的 RAM. 這麼大的記憶體, 不拿來跑 VMWare 真是太可惜了. 所以我就把 Linux server 的虛擬機器搬到老婆的新機器上來跑.

用 VMWare 的好處就是, 虛擬機器真的就只是一個很大的檔案, 所謂把機器搬過來, 其實只是 copy 一個很大的檔案過來, 用這台機器的 VMWare 去開它而已, 完全沒有任何其它的設定要改. 我把原來的虛擬機器 shutdown, 把機器的檔案 copy 過來, 再調整虛擬機器的 RAM 為 1GB, 最後把 VMWare 開起來, 總共不到 10 分鐘.

我原本預期這樣做了之後, 整個 MT 的速度應該會飛起來, 結果沒有.

整個 Linux server 的速度是有快那麼一點點啦, 至少 boot 的時間變短了, 但是網站的反應速度一點都沒變快, 而且在 Movable Type 管理後台的反應也差不多.

到底是什麼原因讓我們網站的速度這麼慢呢 ?

***

我突然想到, Movable Type 產生出來的網夜是靜態的 HTML, 也就是說讀者在看阿爽日記的時候, Movable Type 其實是不介入的, Perl 也沒有在執行, 真正在忙碌的只有 Apache 而已. 如果連看網站都跟進 MT 管理後台一樣慢的話, 搞不好人並不是 Perl 殺的, 而元兇可能是 Apache.

我在網路上找各種關於 "Apache performance tuning", "Apache speed up", "Apache response time" 的資訊, 發現大家都有提到一個問題: Linux kernel 的 TCP write buffer. 在 Linux 的 kernal 中有一個 buffer 是用來堆 TCP write 吐出來的資料, 而 kernal 裡的 TCP/IP stack 會從這個 buffer 拿資料去處理. 如果這個 buffer 滿了, Apache 在寫資料的時候就會被 block 住, 一直要等到 kernal 把 buffer 空出來後才能繼續處理 TCP write. 在等待的時候, Apache 吐網頁的動作會被停下來, 而且它會用 polling 的方式等這個 buffer, 不會先做其它事情.

這顯然是一個 pipelined I/O 的老課題, 解法應該是要讓 output buffer 大到足以容納絕大部份的一次性吞吐量. 我再查了一下, 這個 kernal buffer 有 /proc 變數可以改, 所以我下了兩行指令:

echo 262144 > /proc/sys/net/core/wmem_max

          echo 262144 > /proc/sys/net/core/wmem_default

然後再把 httpd service 重新開起來. 進 MT管理後台.

哇塞, MT 的反應速度真的飛起來了, 原來我們家的 FTTB 上傳 2Mbps 的速度有這麼快, 所有的管理畫面在 refresh 的時候幾乎沒有 lag, 讓人懷疑它到底是不是用 Ajax 寫的網頁… 當然不是啦, MT 是百分之百的純 Perl CGI.

這兩個數字的單位是 byte, 意思是 kernal 分配給每一個 socket 的 write buffer. 我隨便選了 256K bytes 這個數字, 我想除了有照片的網頁以外, 256K bytes 應該都夠把一整頁吐完吧.