解決問題

        對于list查詢來說，arc.typeid2='1′這個條件目的是查找某個文章所屬的第二分類，而事實上這個功能在大部分情況下很少使用，因為我們大可使用標(biāo)簽（tag）來完成一篇文章的多個不同分類的歸屬，因此我們修改文件inc_arclist_view.php，在查詢語句中直接刪除了typeid2的條件判斷，并在pub_db_mysql.php中改進了查詢執(zhí)行函數(shù)（主要用于提高sql語句執(zhí)行的效率，對最終結(jié)果影響不大），得到的最終測試結(jié)果如下，平均每個列表頁面的生成時間下講到不到1秒，3萬數(shù)據(jù)600個列表頁面生成只需要花費不到10分鐘，優(yōu)化目標(biāo)達成。

優(yōu)化后的列表頁面生成速度

3.改進文檔管理效率

問題提出

        在90萬這個數(shù)據(jù)量的情況下，dedecms打開欄目文章列表，尤其是打開所有檔案列表企圖進行文章管理的時候，速度簡直無法讓人忍受。我們點擊所有文檔列表，耐著性子等了將近2分鐘，文章列表頁面才姍姍來遲。到底什么在制約著文章列表速度呢？

優(yōu)化前使用所有檔案列表數(shù)據(jù)加載完成時間

分析問題

        控制顯示文檔列表的程序是dede/content_list.php和include/pub_datalist_dm.php，其中content_list.php是主控制程序，完成列表的參數(shù)傳遞和模板顯示，而pub_datalist_dm.php用于完成數(shù)據(jù)查詢和分頁等操作。通過程序調(diào)試，我們找到了問題的結(jié)癥在于pub_datalist_dm.php程序中對于全部數(shù)據(jù)的統(tǒng)計花費了大量的時間，而使用limit的列表數(shù)據(jù)的查詢并不是性能的瓶頸。影響效率的關(guān)鍵代碼為：

$this->dsql->Query();
$this->totalResult = $this->dsql->GetTotalRow();

        這里所用的數(shù)據(jù)總數(shù)統(tǒng)計的方式居然是通過content_list.php傳遞過來一個復(fù)雜的查詢語句，然后執(zhí)行這個查詢并將結(jié)果保存到數(shù)據(jù)集中，最后通過mysql_num_rows函數(shù)統(tǒng)計結(jié)果集中行的數(shù)目，完全沒有想到dedecms居然走了一個最遠的路途完成一個最簡單的操作，難怪效率低得可怕。因此只要我們改用最常見的count方法來統(tǒng)計數(shù)據(jù)，執(zhí)行效率就能大幅提高。

解決問題

        首先我們修改了程序content_list.php，構(gòu)造了$conutquery參數(shù)用來保存統(tǒng)計使用的SQL語句，代碼如下：

……
$conutquery=”
select count(*) as totalResult
from #@__archives
left join #@__arctype on #@__arctype.ID=#@__archives.typeid
left join #@__channeltype on #@__channeltype.ID=#@__archives.channel
left join #@__admin on #@__admin.ID=#@__archives.adminID
$whereSql
order by #@__archives.{$orderby} desc”;
……

        然后將這個參數(shù)和查詢$query參數(shù)一起傳遞給pub_datalist_dm.php進行處理。

$dlist->SetSource($query,$conutquery);

        隨后將pub_datalist_dm.php中獲得數(shù)據(jù)總數(shù)統(tǒng)計的代碼替換為使用$conutquery參數(shù)：

……
//統(tǒng)計優(yōu)化
$row = $this->dsql->GetOneSimple($this->countSql);
$this->totalResult = $row['totalResult'];
……

        其中GetOneSimple是新構(gòu)造的一個用來執(zhí)行SQL語句的函數(shù)，我把它放在了pub_db_mysql.php類里面，主要的用途就是返回SQL語句執(zhí)行結(jié)果, $this->countSql是上一個程序傳遞過來的統(tǒng)計使用的SQL代碼，$this->totalResult用來記錄數(shù)據(jù)統(tǒng)計結(jié)果。程序修改之后，獲得了滿意的效果。

優(yōu)化后使用所有檔案列表數(shù)據(jù)加載完成時間

總結(jié)

        通過對以上幾步優(yōu)化操作，現(xiàn)在我們的程序后臺已經(jīng)能夠非常輕松的應(yīng)付90萬數(shù)據(jù)的管理和維護了，事實證明dedecms的負載性能的瓶頸并不是mysql、服務(wù)器或者操作系統(tǒng)平臺等，如果把未經(jīng)優(yōu)化的程序放到oracle的數(shù)據(jù)庫上，使用更高級別的服務(wù)器，使用freebsd的操作系統(tǒng)，表現(xiàn)一樣會不盡如人意。細節(jié)決定成敗，看起來dedecms必須要在程序調(diào)優(yōu)、性能優(yōu)化上好好下功夫了。想了解更詳細的解決方案，請加入我們交流。

下面是其他網(wǎng)友的補充

前文介紹了DedeCMS欄目列表頁實現(xiàn)完美分頁的方法，避免了大部分重復(fù)欄目標(biāo)題對搜索引擎的影響，對SEO更有利。今天，分享一下DedeCMS數(shù)據(jù)負載性能優(yōu)化的方法。

接觸織夢也有三年多時間了，對它可謂是又愛又恨。它的模板簡單易用，標(biāo)簽調(diào)用更是靈活，二次開發(fā)也非常方便?？墒?，站點數(shù)據(jù)龐大起來的時候（30多 萬條），后臺就會變得異常緩慢，生成HTML也很吃力，毫不夸張的說，頭發(fā)都等白了。這不禁讓我對DedeCMS數(shù)據(jù)負載性能產(chǎn)生了置疑？

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

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

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

分表存儲如何操作？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最新評論