DedeCms V5.5 性能怎么優(yōu)化

DedeCms V5.5 性能怎么優(yōu)化？

dedecms V5.5發(fā)布后，相對于以前的版本，各方面都表現(xiàn)得比較完美，不過因為通用性原因，不可能同時滿足所有用戶的需求的，在以往，不少人對DedeCms性能問題表示懷疑，因此在此發(fā)布一篇關(guān)于如何對性能進行優(yōu)化的文章，并提供最終優(yōu)化效果測試結(jié)果。

推薦學(xué)習(xí)：織夢cms

一、修改系統(tǒng)參數(shù)

在 DedeCms V5.5中，涉及生成HTML性能的主要有下面幾個參數(shù)：

1、核心設(shè)置：

關(guān)鍵字替換(是/否)使用本功能會影響HTML生成速度(cfg_keyword_replace)

這個參數(shù)默認是開啟的，建議文章是采集的用戶不要開啟此選項，因為采集的文章必須涉及自動生成關(guān)鍵字問題，這樣不少關(guān)鍵字毫無意義，甚至?xí)衼y碼導(dǎo)致生成中斷，所以建議把這個參數(shù)給關(guān)閉。

2、性能選項：

調(diào)用緩存更新時間(秒,0表示不啟用)： 10000 cfg_index_cache

是否啟用模板緩存： 是 cfg_tplcache

這兩個參數(shù)相當有意義，在 DedeCms 中，最影響性能的標簽是 arclist 這個標簽，此外模板緩存是否開啟也相當重要，這兩個選項就是處理這些問題的。

系統(tǒng)參數(shù)具體推薦修改如下圖：

二、優(yōu)化數(shù)據(jù)庫

1、 dede_archives

這個表有 PRIMARY、sortrank、mainindex、lastpost，四組索引，實際上因為這個表本身也比較小，設(shè)置過多的索引反而沒多大的必要，由于dedecms里的程序默認都是用sortrank這字段排序的，建議保留PRIMARY、sortrank兩個索引，刪除mainindex、 lastpost，具體操作如下圖：

2、dede_arctiny

這個表相當?shù)男。跍y試中，7萬數(shù)據(jù)，這個表才占1.5M左右，實際本身就已經(jīng)相當?shù)男?，因此不必建立索引，所以刪除下面索引：

經(jīng)過上面的優(yōu)化之后，用7萬數(shù)據(jù)左右的教育類文章測試（數(shù)據(jù)庫800M左右），在奔騰E、2G內(nèi)存、普通SATA硬盤環(huán)境中測試，生成速度如下圖：

因為DedeCms生成機制前后速度都差不多的，因此速度穩(wěn)定在每秒 15 篇左右，當然這個數(shù)字和用戶模板標簽調(diào)用數(shù)量有一定的關(guān)系，但按這個速度，每小時可以達到 5萬篇以上，這樣還是相當理想的。

可能很多站長會問，為什么不測試百萬、千萬級的數(shù)據(jù)呢？

實際上，按這個數(shù)據(jù)量，如果達到百萬，數(shù)據(jù)庫將達到10G之巨，千萬級的更上100G，像某些CMS吹的已經(jīng)通過了千萬級測試，就讓他們?nèi)ゴ蛋桑?00G數(shù)據(jù)，再加上圖片，生成的HTML是什么概念，是這些普通硬盤、奔騰E的機子可以做的事情？因此拿10萬級的數(shù)據(jù)測試更有代表性，對于真正做正規(guī)站的人，而且以后確實做得很大了，升級一下硬件應(yīng)該沒什么問題的吧，此外那些在虛擬主機下的用戶當然不可能達到這個速度的了，但這可以作為一個性能優(yōu)化參考性的依據(jù)吧