擔心被罵,本不想寫這篇文章。猶豫良久,最終還是決定寫。希望能夠幫助到一些朋友,認識到資料庫索引正確設計的重要性。
由於我比較懶,就簡單用文字描述一下,就懶得切圖片證明瞭,懂技術的朋友可以自己測試一下,可證實我的測試結果是否真實。不懂技術的朋友信不信也無妨。
測試程式:
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 級資料的網站很少。