今天跟版網(wǎng)為大家分享一下DedeCMS數(shù)據(jù)負(fù)載性能優(yōu)化的方法?？棄?mèng)的模板簡(jiǎn)單易用，標(biāo)簽調(diào)用更是靈活，二次開(kāi)發(fā)也非常方便。可是，站點(diǎn)數(shù)據(jù)龐大起來(lái)的時(shí)候（30多 萬(wàn)條），后臺(tái)就會(huì)變得異常緩慢，生成HTML也很吃力，毫不夸張的說(shuō)，頭發(fā)都等白了。這不禁讓我對(duì)DedeCMS數(shù)據(jù)負(fù)載性能產(chǎn)生了置疑？

DedeCMS數(shù)據(jù)負(fù)載性能優(yōu)化方案

查閱了相關(guān)資料，結(jié)合自身站點(diǎn)實(shí)際，還是總結(jié)出了一套不錯(cuò)的DedeCMS數(shù)據(jù)負(fù)載性能優(yōu)化方案。廢話不說(shuō)，直接進(jìn)入正題。

1）數(shù)據(jù)分表存儲(chǔ) 減輕數(shù)據(jù)單表壓力

自織夢(mèng)V5版本起，DedeCMS開(kāi)始分表存儲(chǔ)以提高系統(tǒng)負(fù)載性能，確實(shí)在一定程度上緩解了數(shù)據(jù)壓力?，F(xiàn)在最新的DedeCMS V5.7版本已經(jīng)出來(lái)了，據(jù)官方介紹，V5.7調(diào)整了緩存處理，應(yīng)付50萬(wàn)以內(nèi)數(shù)據(jù)沒(méi)問(wèn)題，至于真實(shí)性無(wú)從考究。如果官方陳述屬實(shí)的話，對(duì)于中小型站長(zhǎng)來(lái) 說(shuō)確實(shí)是件好事，正常百萬(wàn)級(jí)內(nèi)數(shù)據(jù)也不用過(guò)多擔(dān)心了。

分表存儲(chǔ)如何操作？

如果你只是個(gè)人或企業(yè)等小型站點(diǎn)，數(shù)據(jù)量也就撐死上萬(wàn)，那完全不用考慮分表存儲(chǔ)，DedeCMS完全可以勝任。分表操作很簡(jiǎn)單，你只需要直接進(jìn)入后 臺(tái)，新建模型，然后設(shè)置一個(gè)欄目對(duì)應(yīng)一個(gè)模型。個(gè)人建議一個(gè)大的頻道欄目及子欄目對(duì)應(yīng)一個(gè)模型，這要根據(jù)你的欄目可能存儲(chǔ)的數(shù)據(jù)來(lái)做計(jì)劃，考慮實(shí)際一點(diǎn)的 分表方案。

2）修改系統(tǒng)參數(shù) arclist標(biāo)簽另類優(yōu)化

在DedeCMS V5版本中，官方其實(shí)已經(jīng)做了極力優(yōu)化，引入了緩存機(jī)制。其實(shí)影響HTML生成速度的罪魁禍?zhǔn)走€是模板中的arclist標(biāo)簽，很多站長(zhǎng)喜歡用 arclist標(biāo)簽來(lái)調(diào)用最新、熱門、推薦、頭條等文章列表，但是arclist標(biāo)簽每次都帶著一大堆條件去主表中查詢，可能還會(huì)關(guān)聯(lián)附加表，對(duì)一次性生 成大量文章來(lái)說(shuō)，只是重復(fù)使用arclist標(biāo)簽對(duì)數(shù)據(jù)庫(kù)重復(fù)查詢罷了，自然會(huì)花去大量時(shí)間?，F(xiàn)在DedeCMS新的版本中，生成HTML時(shí)arclist標(biāo)簽會(huì)直接調(diào)用緩存數(shù)據(jù)，省去arclist標(biāo)簽重復(fù)查詢數(shù)據(jù)庫(kù)的時(shí)間，頓時(shí)讓上述工作變得輕松起來(lái)，生成速度得到提升也是必然的。你只用在系統(tǒng)參數(shù)->性能選項(xiàng)中，找到arclist標(biāo)簽調(diào)用緩存（cfg_index_cache）(0 不啟用，大于0值為多少秒)，根據(jù)自身實(shí)際需求調(diào)整緩存調(diào)用時(shí)間。

其實(shí)，還有一種解決辦法，就是麻煩了一些，但是對(duì)性能提升是非常顯著的。arclist 標(biāo)簽調(diào)用緩存雖說(shuō)一定程度上提高了HTML生成速度，但是還是需要對(duì)arclist緩存進(jìn)行判斷，如果能把這部分時(shí)間也省去，那是不是會(huì)更快呢？答案是肯 定確定以及雙重否定。我們可以通過(guò)freelist(自由列表)功能事先生成最新、熱門、推薦、頭條等文章列表頁(yè)面，然后用include標(biāo)簽直接引入到 模板里，標(biāo)簽格式為：{dede:include file=’文章列表頁(yè)面文件名稱’ ismake=’ no’/}。如果你的站長(zhǎng)數(shù)據(jù)很龐大，服務(wù)器硬件配置也一般的話，何不嘗試一下呢？

另外，系統(tǒng)參數(shù)-核心設(shè)置里默認(rèn)的關(guān)鍵字替換功能（cfg_keyword_replace）是開(kāi)啟的，如果文章是采集過(guò)來(lái)的，還是關(guān)閉的好，有很多關(guān)鍵字都毫無(wú)意義，甚至?xí)衼y碼導(dǎo)致生成出錯(cuò)，關(guān)掉此功能對(duì)提高系統(tǒng)性能是有一定幫助的。

3）數(shù)據(jù)庫(kù)表索引優(yōu)化 性能大幅提升

為什么要對(duì)DedeCMS數(shù)據(jù)庫(kù)表索引進(jìn)行優(yōu)化呢？很簡(jiǎn)單，在Mysql中，索引無(wú)疑是最有效的加快查詢的工具了，一個(gè)合理的索引組合會(huì)極大地提升 你的查詢效率和系統(tǒng)性能。言歸正傳，你可以通過(guò)phpmyadmin或是一個(gè)叫Navicat for MySQL的軟件（推薦）來(lái)管理你的數(shù)據(jù)庫(kù)。

分析DEDECMS數(shù)據(jù)表信息，不難發(fā)現(xiàn)，所有的文章數(shù)據(jù)是存儲(chǔ)在dede_archives和dede_arctiny，以及對(duì)應(yīng)的 dede_addonarticle附加表中的。生成HTML時(shí)，sql查詢主要圍繞這三張表來(lái)的。個(gè)人認(rèn)為，凡是要排序的字段和查詢條件的字段及文檔 ID都要建立索引，如果一個(gè)沒(méi)有建立，將會(huì)嚴(yán)重影響MySQL的查詢效率，最終導(dǎo)致生成速度變慢。DEDECMS數(shù)據(jù)表索引建立方法如下：

a）dede_archives，是文章的主表，存儲(chǔ)文章標(biāo)題、關(guān)鍵 字、描述、發(fā)布時(shí)間等信息，10萬(wàn)數(shù)據(jù)的表大小可能在30MB左右，也是我們優(yōu)化的重點(diǎn)。你需要建立的索引字段有，id、channel、 pubdate、sortrank、ismake、typeid、mainindex、lastpost；其中，像系統(tǒng)默認(rèn)的mainindex和 lastpost這兩個(gè)組合索引，個(gè)人認(rèn)為存在意義不大，可以刪除，自己掂量。需要注意的是，click字段，是文檔的點(diǎn)擊數(shù)，此字段更新頻率，建立索引 后會(huì)對(duì)系統(tǒng)維護(hù)帶來(lái)一定壓力，另外也有人說(shuō)頻繁更新的建立索引會(huì)容易導(dǎo)致數(shù)據(jù)庫(kù)損壞，也無(wú)從查證。個(gè)人建議click字段保留，不建立索引。

為DedeCMS數(shù)據(jù)表建立索引

b）dede_arctiny，這個(gè)表比較小，10萬(wàn)數(shù)據(jù)的表大小不到5MB，建議不建立索引，可以將自帶的刪除掉，或者只保留sortrank索引。

c）dede_addonarticle，是文章附加表，主要是用來(lái)存儲(chǔ)文章內(nèi)容的，不作索引考慮。

以上索引成功建立后，再測(cè)試下你的HTML生成速度，是不是讓你精神一振呢？

4）搭建勝過(guò)Apache十倍的高并發(fā)Web服務(wù)器 Nginx + PHP（FastCGI）

Web服務(wù)器的重要性不需多言，對(duì)提升網(wǎng)站性能有著直接影響。在PHP開(kāi)發(fā)中，最常用的環(huán)境莫過(guò)于在 LAMP:Linux+apache+mysql+php了，在windows下有 WAMP:Windows+apache/iis+mysql+php，我的WEB站點(diǎn)也是在這種環(huán)境下開(kāi)發(fā)的。Nginx + PHP（FastCGI）無(wú)疑是你最好的選擇，在Windows和Linux下都可以安裝，只是Windows下的Nginx表現(xiàn)要遠(yuǎn)遠(yuǎn)遜色于Linux。

DedeCMS系統(tǒng)運(yùn)行是依賴PHP+MYSQL環(huán)境的，所以說(shuō)一個(gè)運(yùn)行快、資源消耗小的Web服務(wù)器對(duì)提升系統(tǒng)性能有多重要。如果條件允許的條件，還是推薦下Nginx + PHP（FastCGI）這種WEB服務(wù)器環(huán)境。

以上就是DedeCMS數(shù)據(jù)負(fù)載性能的優(yōu)化方案，針對(duì)的是有獨(dú)立WEB服務(wù)器或控制權(quán)限的站長(zhǎng)，至于虛擬主機(jī)想 達(dá)到這個(gè)速度還是很費(fèi)勁的，但是也可以作為DedeCMS性能優(yōu)化的一個(gè)參考依據(jù)，自己琢磨琢磨了。當(dāng)然，如果有更好的提高DedeCMS數(shù)據(jù)負(fù)載性能的 辦法，還希望分享下。其實(shí)，正常情況下（不包括采集），一般站點(diǎn)數(shù)據(jù)量也都有限，20萬(wàn)就很了不起了吧？我想，以上的DedeCMS優(yōu)化方案足以解決了。 真到了百萬(wàn)級(jí)、千萬(wàn)級(jí)數(shù)據(jù)的時(shí)候，也不是一般站長(zhǎng)需要考慮的事了。