由于我比較懶，就簡單用文字描述一下，就懶得切圖片證明了，懂技術(shù)的朋友可以自己測試一下，可證實我的測試結(jié)果是否真實。不懂技術(shù)的朋友信不信也無妨。

　　測試程序：

　　CMS程序：帝國cms dedecms phpcms
　　論壇程序：discuz phpwind xiuno
　　負載測試結(jié)果：
　　xiuno>discuz>phpwind>phpcms>(帝國cms??dedecms)
　　從數(shù)據(jù)庫設(shè)計來看（個人觀點）：
　　xiuno>（discuz、phpwind、phpcms）>(帝國cms、dedecms)

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

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

　　dedecms的創(chuàng)始人我算是和他認識，但現(xiàn)在dedecms卻不是他的，比較遺憾，現(xiàn)在的dedecms這幾年確實沒多大變化，一直在打補丁，這樣下去真是比較悲劇。
　　我的測試環(huán)境：
　　i3CPU 4G內(nèi)存1T硬盤win7系統(tǒng)apache 2.2+mysql 5.0(普通環(huán)境沒有優(yōu)化過)
　　測試方法：
　　導入100萬至1億不等數(shù)據(jù)，進行簡單的訪問測試
　　我的導入方法：
　　根據(jù)各個程序的數(shù)據(jù)結(jié)構(gòu)寫出導入程序，
　　1.先寫一個PHP程序，將數(shù)據(jù)寫入e:/insert1.sql這個文件，
　　2.然后再通過LOAD DATA local INFILE‘e:/insert1.sql’INTO TABLE`數(shù)據(jù)表名`character set編碼;這種方式導入的，導入千W數(shù)據(jù)也就幾分鐘。

　　1、帝國cms

　　測試版本：EmpireCMS_7.0_SC_GBK（當前官方最新版）
　　先說說帝國cms，官方有一篇大數(shù)據(jù)測試貼（2千萬數(shù)據(jù)、17.3GB數(shù)據(jù)庫下帝國CMS超強生成速度），當年我看到這篇測試貼時，也覺得負載非常強大，但我測試后，令我失望了。
　　安裝默認測試數(shù)據(jù)（共33篇新聞測試數(shù)據(jù)），首頁改為動態(tài)首頁第一次訪問0.670127010345459第二次訪問0.07926607131958
　　我導入100W數(shù)據(jù)時，數(shù)據(jù)庫大小3.6G，首頁第一次訪問182秒，第二次訪問155秒，我不知道當時帝國cms作者測試時，是否有測試過動態(tài)訪問首頁的時間。包括從6.0版起，每次更新都有說提升性能，但為何會這樣？
　　帝國CMS官方的測試帖，就是誤導人，忽悠人。
　　問題1.測試數(shù)據(jù)并沒有提到動態(tài)訪問首頁或是生成首頁。也沒有提到動態(tài)訪問列表頁，和生成列表頁。
　　問題2.測試統(tǒng)計的時間，也只統(tǒng)計了連接數(shù)據(jù)庫之后的執(zhí)行時間，并沒有加上連接數(shù)據(jù)庫的時間，這樣很容易誤導很多人，拿這個時間和別人統(tǒng)計了連接數(shù)據(jù)庫的時間比。這樣就差別大了。
　　問題3.每篇新聞的內(nèi)容很少也就幾行字。同時內(nèi)容頁模板，也非常簡單，生成出來的文件也非常小，只有3K。正常的文章，都是上10K至幾十K。
　　問題4.同時因為phome_ecms_news表id為主鍵，讀取內(nèi)容時，都是走的索引，所以動態(tài)訪問內(nèi)容頁，編輯內(nèi)容，生成內(nèi)容頁很快，都是理所當然的。
　　問題5.測試時都是通過分表來測試的，在真實站長做網(wǎng)站，不可能一開始就把網(wǎng)站內(nèi)容分表。所以這和真實做站情況完全不一樣。
　　像官方這種測試貼，真是誤導人，而且還掛了幾年。對于不懂技術(shù)的人，就是一種誤導，讓普通用戶盲目的崇拜。


　　2、dedecms
　　測試版本：DedeCMS V5.7 SP1_GBK正式版（當前官方最新版）
　　織夢CMS在知度CMS中一直公認的負載性能最差的CMS，確實很差。
　　我導入100W數(shù)據(jù)時，數(shù)據(jù)庫大小只有330M，首頁訪問已經(jīng)需要70幾秒-80幾秒才能訪問。


　　3、phpcms
　　測試版本：PHPCMS V9_GBK正式版（當前官方最新版）
　　PHPCMS現(xiàn)在是由新的團隊重新開發(fā)，也是號稱高負載。
　　我導入100W數(shù)據(jù)時，數(shù)據(jù)庫大小3G，首頁訪問需要20幾秒。


　　4、phpwind
　　測試版本：phpwind v9.0 UTF-8正式版（當前官方最新版）
　　phpwind以前和discuz比，速度上有優(yōu)勢，現(xiàn)在據(jù)說是全新開發(fā)，新版確實做了很大的改變（以前一直是discuz追隨者，和discuz設(shè)計差別不是很大），現(xiàn)在這一變化，應該值的贊揚，但現(xiàn)在速度上不如discuz了，以前網(wǎng)頁底部顯示執(zhí)行時間都去掉了。
　　我導入1000W數(shù)據(jù)時，數(shù)據(jù)庫大小13G，
　　首頁第一次訪問8秒，第二次訪問0.70477390289307秒
　　帖子列表頁（默認排序）0.2x-0.5x秒但我采用按“最新發(fā)貼”排序時，花了182秒才顯示出來（我看了數(shù)據(jù)庫設(shè)計，因為只做了按“最后回復”的索引，“發(fā)帖時間”的排序都沒做索引，所以才很慢）
　　帖子內(nèi)容頁，沒填充多少回帖也沒具體測試


　　5、discuz
　　測試版本：Discuz_X2.5_SC_UTF8 Discuz_X3.0_SC_UTF8
　　dx3看來是dx2.5的加強版，從后臺、前臺設(shè)計看，都變化不大。數(shù)據(jù)庫架構(gòu)變化也不大。
　　我導入1000W數(shù)據(jù)時，數(shù)據(jù)庫大小18G，
　　首頁0.05-0.06秒，（也沒太大測試價值,因為都沒讀到thread表）
　　帖子列表頁（默認排序）0.07-0.09秒但我采用按“發(fā)帖時間”排序時，花了181秒才顯示出來（我看了數(shù)據(jù)庫設(shè)計，因為只做了按“最后回復”的索引，“發(fā)帖時間”的排序都沒做索引，所以才很慢）
　　帖子內(nèi)容頁，(沒填充多少回帖也沒具體測試)


　　6、xiuno
　　測試版本：xiuno bbs 2.02 UTF8
　　我導入1000W數(shù)據(jù)時，數(shù)據(jù)庫大小15G
　　首頁0.03-0.05秒
　　帖子列表頁0.03-0.05秒（回貼排序）0.01-0.03秒（發(fā)帖排序）
　　帖子內(nèi)容頁0.03-0.05秒(沒填充多少回帖也沒具體測試翻頁)
　　我導入1億數(shù)據(jù)時，數(shù)據(jù)庫填充到215G
　　首頁0.05-0.08秒
　　帖子列表頁0.05-0.08秒（回貼排序）0.03-0.05秒（發(fā)帖排序）
　　帖子內(nèi)容頁0.05-0.08秒(沒填充多少回帖也沒具體測試翻頁)


　　總結(jié)：

　　xiuno雖然負載很高，但是功能上有很大的控制，去掉了很多可能影響到性能的功能，功能方面我覺得要是能有一個像wordpress這樣的一個平臺來彌補，那將會有非常大的優(yōu)勢。
　　discuz雖然沒做深入測試，不過已經(jīng)可見負載上面還是有缺陷的，同時thread表設(shè)計為tid mediumint(8)UNSIGNED所以最大數(shù)值也就16777215，所以他的設(shè)計也并沒有往更高考慮。
　　phpwind這次的新版本的改變，證明了他們的決心，要和discuz走不同的路，也能看出來他們更注重用戶體驗方面。程序性能已經(jīng)次之。
　　phpcms性能是比以前提升了，但是用戶體驗我是感覺不太好。不過能夠說明CMS性能方面不如BBS程序。因為排序方式多，而且同一個頁面列表也比論壇的多，所以讓CMS性能不如BBS。
　　帝國cms雖然程序官方一直強調(diào)負載，但真還不如phpcms，光是通過分表提高負載，真不是一個好辦法。我個人愚見，程序負載高不高，第一步應該是正確設(shè)計索引，索引都沒設(shè)計對，就用分表來解決，而且還要站長手動設(shè)置，完全增加使用難度。

　　dedecms雖然用戶量非常大，但數(shù)據(jù)庫設(shè)計真不好，不但索引沒設(shè)計對，而且還沒分表，而且也能看出dedecms并沒有考慮做高負載，畢竟上百W級數(shù)據(jù)的網(wǎng)站很少。

最新評論