來自:http://www.chinaz.com/web/2013/0729/311360.shtmlphp
擔憂被罵,本不想寫這篇文章。猶豫良久,最終仍是決定寫。但願可以幫助到一些朋友,認識到數據庫索引正確設計的重要性。html
因爲我比較懶,就簡單用文字描述一下,就懶得切圖片證實了,懂技術的朋友能夠本身測試一下,可證明個人測試結果是否真實。不懂技術的朋友信不信也無妨。mysql
測試程序:web
CMS程序:帝國cms dedecms phpcmssql
論壇程序:discuz phpwind xiuno數據庫
負載測試結果:apache
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數據也就幾分鐘。
一、帝國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.測試時都是經過分表來測試的,在真實站長作網站,不可能一開始就把網站內容分表。因此這和真實作站狀況徹底不同。
像官方這種測試貼,真是誤導人,並且還掛了幾年。對於不懂技術的人,就是一種誤導,讓普通用戶盲目的崇拜。
二、dedecms
測試版本:DedeCMS V5.7 SP1_GBK正式版 (當前官方最新版)
織夢CMS在知度CMS中一直公認的負載性能最差的CMS,確實不好。
我導入100W數據時,數據庫大小隻有330M,首頁訪問已經須要70幾秒-80幾秒才能訪問。
三、phpcms
測試版本:PHPCMS V9_GBK 正式版 (當前官方最新版)
PHPCMS如今是由新的團隊從新開發,也是號稱高負載。
我導入100W數據時,數據庫大小3G,首頁訪問須要20幾秒。
四、phpwind
測試版本:phpwind v9.0 UTF-8 正式版(當前官方最新版)
phpwind之前和discuz比,速度上有優點,如今聽說是全新開發,新版確實作了很大的改變(之前一直是discuz追隨者,和discuz設計差異不是很大),如今這一變化,應該值的讚賞,但如今速度上不如discuz了,之前網頁底部顯示執行時間都去掉了。
我導入1000W數據時,數據庫大小13G,
首頁第一次訪問8秒,第二次訪問0.70477390289307秒
帖子列表頁(默認排序)0.2x-0.5x秒 但我採用按「最新發貼」排序時,花了182秒才顯示出來(我看了數據庫設計,由於只作了按「最後回覆」的索引,「發帖時間」的排序都沒作索引,因此才很慢)
帖子內容頁,沒填充多少回帖也沒具體測試
五、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秒才顯示出來(我看了數據庫設計,由於只作了按「最後回覆」的索引,「發帖時間」的排序都沒作索引,因此才很慢)
帖子內容頁,(沒填充多少回帖也沒具體測試)
六、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級數據的網站不多。