對帝國cms、dedecms、phpcms等負載測試總結

標籤：discuz   http   ar   使用   sp   strong   on   檔案   資料   

來自：http://www.chinaz.com/web/2013/0729/311360.shtml

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

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

測試程式：

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級資料的網站很少。

 

對帝國cms、dedecms、phpcms等負載測試總結