看完『談成長中 CMS 的 Scaling 之道』的兩篇文章，分享心得。

一、目的？

每篇文章的都有撰寫目的。該篇文章的目的應該是想要讓大家了解 Wordpress 方案的選擇及演進，我個人不覺得對 Wordpress 有太多的批評之意。而這篇的目的是想要分享一些想法，並期待討論。

二、技術人不能只談 PV

不管從系統或架構上，技術人直接以 PV 談效能 (或機器撐不撐的住) 都是很神奇的。

對於一個技術人，談效能最基本的參考指標之一就是 QPS (每秒機器處理的訪問量)。但兩篇文章從頭到尾都沒有出現 QPS 或類似的評估值。如果一開始的分析就沒有基準點，最後的可能就是怪罪機器不夠力，或是套件拖累。

『不先問 QPS，不深入分析，談 PV 也惘然』，尤其是技術人。

從 PV 談效能不是不能談，有公式可以算，但最終還是要回歸到 QPS 才會正確。

以 Daily PV 30,000 為例，若平均分布，則單台機器每秒只要能夠處理 0.34 個連線就撐得住 ( 30000 / 86400 = 0.347222)。

但現實生活不會是平均分布，所以若改用八二法則，則單台機器每秒也只要處理 1.39 個連線 (( 30000 * 0.8 / ( 86400 * 0.2) = 1.38889 ) 。

可是對技術人來說，推估始終只是推估。以這個案例來說，直接問蔡醫生 QPS 是多少，短時間內就大概略知一二，根本不需要推估。

每秒 0.34 或 1.39 QPS 很高嗎？一點也不，AWS EC2 Small 方案最高每秒可達 11 QPS。若再加上 WP Super Cache 外掛則提升為 123 QPS。( http://blog.celingest.com/en/2013/02/25/nginx-vs-apache-in-aws/ )

QPS 123 很少嗎？用同樣的公式反估回 PV (八二法則)，可達到 Daily PV 2,656,800 。

這個推估即使打一折，還是打趴『談成長中 CMS 的 Scaling 之道』文中提到的 Pageview 130,000+ 及 Daily PV 30000+ 兩個案例。

三、問題？

所以問題出在哪裡？我不知道，但應該不會是 Wordpress 的問題。

因為沒有分析值，我也不知道該怎麼評估。例如，機器等級？作業系統？網頁伺服器？PHP？資料庫？這些都會影響到效能表現。

畢竟 Wordpress 是架構在 PHP 上，PHP 又架構在網頁伺服器上，網頁伺服器又架構在作業系統上，作業系統又架構在機器上，然後相關的還有資料庫。每個環節及層次都要考量。總不能在 286⁄386 機器上跑得慢就說是 Wordpress 的問題吧。

因此，機器等級如何？是不是有調校作業系統？是不是有調校 Apache/Nginx 網頁伺服器？是不是有調校 PHP？是不是有調校資料庫？是不是有加上 Cache (如 WP Super Cache)？而且我還沒提到加購服務 (例如升級 VPS 或採用 CDN)，很多是免費就可以做到的。

四、疑問？

『談成長中 CMS 的 Scaling 之道』的引言：「四年前曾經某媒體網站的 Case 就是 Daily PV 30000+。是 Dedicated Hosting 卻始終無法 Scale 上去，是因為每天早上十點，下午三點，晚上十點各會倒站 30 分鐘」。

四年前大神應該早就使用 Rails 方案，所以這裡的 Case 指的是 Wordpress 還是 Rails？再者，即使是 Wordpress，如前所述， PV 30000 是每秒 1.39 QPS 就可以解決的，而 EC2 Small 方案就可以達到，我很難相信 Dedicated Hosting 的機器等級會比這個差。

而且倒站 30 分鐘？最差的情況就是重開機，但重開機不用 30 分鐘吧？如果要 30 分鐘的話，那我認為問題在『人』的可能性比較大。

五、讓數據說話

分享網路牛人在 EC2 上以每個月 15 美金，讓 Wordpress 達到每日 PV 一千萬的案例。

六、我的經驗

我過去也是 Wordpress 的愛用者，即使 EC2 Micro 方案，QPS 上百也不是問題，以八二法換算可以承受每日 PV 2,160,000+ 的量。所以重點在於有沒有分析是哪個環節出問題，以及有沒有能力解決這個問題罷了。

七、補充

最後需要補充的是，上述提到的 QPS 與 PV 互轉公式，只適用一些簡單的網站。CMS 算是合適的，但若是購票網站就不能這麼估算了。