擔心被罵,本不想寫這篇文章。猶豫良久,最終還是決定寫。希望能夠幫助到一些朋友,認識到數據庫索引正確設計的重要性。

由於我比較懶,就簡單用文字描述一下,就懶得切圖片證明瞭,懂技術的朋友可以自己測試一下,可證實我的測試結果是否真實。不懂技術的朋友信不信也無妨。

測試程序:

CMS 程序:帝國 cms dedecms phpcms

論壇程序:discuz phpwind xiuno

負載測試結果:

xiuno > discuz > phpwind > phpcms > ( 帝國 cms ? dedecms)

從數據庫設計來看 (個人觀點):

xiuno > (discuz 、 phpwind 、 phpcms) > (帝國 cms 、 dedecms)

dedecms 和帝國 cms 都是老牌的 CMS 了,從的數據庫設計來看,不知是數據庫設計者完全沒有理解 mysql 索引的真諦,還是留一手以對高負載需求的用户收費改進?(希望不懂技術的朋友不要噴我,真正懂 mysql 索引的朋友可以自己看一下他們對索引的設計,雖然對於 dedecms 和帝國 cms 的作者來説,我只是一個晚輩,像您們這樣有 10 多年開發經驗的人,我比較尊敬,但我建議當前的 dedecms 和帝國 cms 數據庫設計者還是再研究一下 mysql 索引吧,可以不相信我,但可以花點時間看看 discuz 、 phpwind 的數據庫設計吧,確實是比您們的好) 。

如果有幸帝國 cms 作者能看到此文,希望您再重新設計帝國 cms 架構吧,畢竟這些年您一直在改進帝國 cms 的負載能力,光是通過分表技術提升,沒有真正用到索引來優化,真的不行的,如果用對了索引,性能還會有更大的提升。

dedecms 的創始人我算是和他認識,但現在 dedecms 卻不是他的,比較遺憾,現在的 dedecms 這幾年確實沒多大變化,一直在打補丁,這樣下去真是比較悲劇。

我的測試環境:

i3CPU 4G 內存 1T 硬盤 win7 系統   apache 2.2 + mysql 5.0(普通環境沒有優化過)

測試方法:

導入 100 萬至 1 億 不等數據,進行簡單的訪問測試

我的導入方法:

根據各個程序的數據結構寫出導入程序,

1. 先寫一個 PHP 程序,將數據寫入 e:/insert1.sql 這個文件,

2. 然後再通過 LOAD DATA local INFILE 'e:/insert1.sql' INTO TABLE `數據表名` character set 編碼; 這種方式導入的,導入千 W 數據也就幾分鐘。

1 、帝國 cms

測試版本:EmpireCMS_7.0_SC_GBK(當前官方最新版)

先説説帝國 cms,官方有一篇大數據測試貼 (2 千萬數據、 17.3GB 數據庫下帝國 CMS 超強生成速度 ),當年我看到這篇測試貼時,也覺得負載非常強大,但我測試後,令我失望了。

安裝默認測試數據 (共 33 篇新聞測試數據),首頁改為動態首頁 第一次訪問 0.670127010345459 第二次訪問 0.07926607131958

我導入 100W 數據時,數據庫大小 3.6G,首頁第一次訪問 182 秒,第二次訪問 155 秒,我不知道當時帝國 cms 作者測試時,是否有測試過動態訪問首頁的時間。包括從 6.0 版起,每次更新都有説提升性能,但為何會這樣?

帝國 CMS 官方的測試帖,就是誤導人,忽悠人。

問題 1. 測試數據並沒有提到動態訪問首頁或是生成首頁。也沒有提到動態訪問列表頁,和生成列表頁。

問題 2. 測試統計的時間,也只統計了連接數據庫之後的執行時間,並沒有加上連接數據庫的時間,這樣很容易誤導很多人,拿這個時間和別人統計了連接數據庫的時間比。這樣就差別大了。

問題 3. 每篇新聞的內容很少也就幾行字。同時內容頁模板,也非常簡單,生成出來的文件也非常小,只有 3K 。正常的文章,都是上 10K 至幾十 K 。

問題 4. 同時因為 phome_ecms_news 表 id 為主鍵,讀取內容時,都是走的索引,所以動態訪問內容頁,編輯內容,生成內容頁很快,都是理所當然的。

問題 5. 測試時都是通過分表來測試的,在真實站長做網站,不可能一開始就把網站內容分表。所以這和真實做站情況完全不一樣。

像官方這種測試貼,真是誤導人,而且還掛了幾年。對於不懂技術的人,就是一種誤導,讓普通用户盲目的崇拜。

2 、 dedecms

測試版本:DedeCMS V5.7 SP1_GBK 正式版 (當前官方最新版)

織夢 CMS 在知度 CMS 中一直公認的負載性能最差的 CMS,確實很差。

我導入 100W 數據時,數據庫大小隻有 330M,首頁訪問已經需要 70 幾秒-80 幾秒才能訪問。

§

3 、 phpcms

測試版本:PHPCMS V9_GBK 正式版 (當前官方最新版)

PHPCMS 現在是由新的團隊重新開發,也是號稱高負載。

我導入 100W 數據時,數據庫大小 3G,首頁訪問需要 20 幾秒。

4 、 phpwind

測試版本:phpwind v9.0 UTF-8 正式版 (當前官方最新版)

phpwind 以前和 discuz 比,速度上有優勢,現在據説是全新開發,新版確實做了很大的改變 (以前一直是 discuz 追隨者,和 discuz 設計差別不是很大),現在這一變化,應該值的讚揚,但現在速度上不如 discuz 了,以前網頁底部顯示執行時間都去掉了。

我導入 1000W 數據時,數據庫大小 13G,

首頁第一次訪問 8 秒,第二次訪問 0.70477390289307 秒

帖子列表頁 (默認排序)0.2x-0.5x 秒  但我採用按 「最新發貼」 排序時,花了 182 秒才顯示出來 (我看了數據庫設計,因為只做了按 「最後回覆」 的索引,「發帖時間」 的排序都沒做索引,所以才很慢) 

帖子內容頁,沒填充多少回帖也沒具體測試

5 、 discuz

測試版本:Discuz_X2.5_SC_UTF8  Discuz_X3.0_SC_UTF8

dx3 看來是 dx2.5 的加強版,從後台、前台設計看,都變化不大。數據庫架構變化也不大。

我導入 1000W 數據時,數據庫大小 18G,

首頁 0.05-0.06 秒,(也沒太大測試價值, 因為都沒讀到 thread 表)

帖子列表頁 (默認排序)0.07-0.09 秒 但我採用按 「發帖時間」 排序時,花了 181 秒才顯示出來 (我看了數據庫設計,因為只做了按 「最後回覆」 的索引,「發帖時間」 的排序都沒做索引,所以才很慢) 

帖子內容頁,(沒填充多少回帖也沒具體測試)

6 、 xiuno

測試版本:xiuno bbs 2.02 UTF8

我導入 1000W 數據時,數據庫大小 15G

首頁 0.03-0.05 秒

帖子列表頁 0.03-0.05 秒 (回貼排序)    0.01-0.03 秒 (發帖排序)

帖子內容頁 0.03-0.05 秒 (沒填充多少回帖也沒具體測試翻頁)

我導入 1 億數據時,數據庫填充到 215G

首頁 0.05-0.08 秒

帖子列表頁 0.05-0.08 秒 (回貼排序)     0.03-0.05 秒 (發帖排序)

帖子內容頁 0.05-0.08 秒 (沒填充多少回帖也沒具體測試翻頁)

總結:

xiuno 雖然負載很高,但是功能上有很大的控制,去掉了很多可能影響到性能的功能,功能方面我覺得要是能有一個像 WordPress 這樣的一個平台來彌補,那將會有非常大的優勢。

discuz 雖然沒做深入測試,不過已經可見負載上面還是有缺陷的,同時 thread 表設計為 tid mediumint(8) UNSIGNED 所以最大數值也就 16777215,所以他的設計也並沒有往更高考慮。

phpwind 這次的新版本的改變,證明瞭他們的決心,要和 discuz 走不同的路,也能看出來他們更注重用户體驗方面。程序性能已經次之。

phpcms 性能是比以前提升了,但是用户
體驗我是感覺不太好。不過能夠説明 CMS 性能方面不如 BBS 程序。因為排序方式多,而且同一個頁面列表也比論壇的多,所以讓 CMS 性能不如 BBS 。

帝國 cms 雖然程序官方一直強調負載,但真還不如 phpcms,光是通過分表提高負載,真不是一個好辦法。我個人愚見,程序負載高不高,第一步應該是正確設計索引,索引都沒設計對,就用分表來解決,而且還要站長手動設置,完全增加使用難度。

dedecms 雖然用户量非常大,但數據庫設計真不好,不但索引沒設計對,而且還沒分表,而且也能看出 dedecms 並沒有考慮做高負載,畢竟上百 W 級數據的網站很少。