Dedecms生成速度慢的解決方案


最近修改了部分模板,因此有相當一部分頁面需要重新生成,在生成時發現Dedecms生成速度慢的受不了,CPU達到100%,小編專門找了另一台閑置的電腦用來生成,一晚上沒有關機,三萬多數據,竟然用了一晚上還沒有完成。在DEDE官方論壇看到這樣的解決方法,試了一下,還不錯。

打開include/inc/inc_fun_SpGetArcList.php,找到以下代碼:

 
for($i=0;$i<$ridnum;$i++){ 
if($tpsql=="") $tpsql .= " And ( (".TypeGetSunID($reids[$i],$dsql,'arc')." Or arc.typeid2='".$reids[$i]."') "; 
else $tpsql .= " Or (".TypeGetSunID($reids[$i],$dsql,'arc')." Or arc.typeid2='".$reids[$i]."') "; 

將以上代碼注釋掉,並替換為下邊的代碼:

 
for($i=0;$i<$ridnum;$i++){ 
if($tpsql=="") $tpsql .= " And (".TypeGetSunID($reids[$i],$dsql,'arc'); 
else $tpsql .= " Or ".TypeGetSunID($reids[$i],$dsql,'arc'); 
}
 

查找:

$orwhere .= " And ( arc.typeid in ($sonids) Or arc.typeid2 in ($sonids) ) "

替換為:

$orwhere .= " And arc.typeid in ($sonids) "; 

 

這時你再生成靜態時,會發現快了很多,原文中提到這是由於不再考慮副欄目,因此就快了。

Dedecms生成速度慢的解決方法(2014年2月補充):

其實很多dedecms生成HTML慢的問題,都已經不能通過上述辦法解決了,最火軟件小編專門從某技術博客轉載了新的優化辦法,經測試在10萬文檔下速度改善了許多(需要說明的是:如果您有上萬數據,而用的虛擬主機或VPS就不用優化了,因為那是web服務器性能差。)。

主要從以下幾個方面優化(如果不想動模板,建議大家直接搞數據庫):

數據庫    索引的優化   和   分表的處理
模板    重復讀取數據的標簽太多

服務器  這些一般大家都會,虛擬主機的不用,個人獨立主機的可以看看關於服務器的優化教程

\


   這是優化完的效果截圖

我先給大家從模板的地方入手處理

/---------------------模板處理優化-------------------------/

優化模板的話,主要看你自己的欄目設計到用不用二級,如果是二級的話
大家可以建立一個主數據的調取東西例如    {圖片,css,/plus/} 這些東西可以用一個獨立的域名做

例如:
http://code.yousite.com/css/網站ccs
http://code.yousite.com/img/網站皮膚圖片
http://code.yousite.com/plus/search.php
 {等等許多能固定的內容方便以后做成大網站好升級的規划}

然后再做模板的時候盡量不要用
{dede:global.cfg_templeturl/}
{dede:field name='phpurl'/}
這些還有關於  有{dede:field 的文件, 可以直接寫成實際地址,如果是有二級域名的站,寫在一個主調取的域名站上

可以不用上下片文章標簽,畢竟文章有針對性, 很少人點擊上下文章那個,除非是圖片站

相關內容可以取舍這個根據使用者選擇

至於  推薦  熱點的  可以由自由列表處理
例如做一個整站固定的樣式然后 用自由列表做出來

圖例子:
\

再文章模板里面寫  

圖例子:
\

{dede:include filename="自由列表生成的文件地址 ismake='no'/}   這里的ismake簡單的說就是只里面的東西是否還需要處理  兩個選擇 yes  no          no就是直接顯示里面的內容

{dede:include file="/temp/liuxingfushi.html" ismake='no'/}     我自己在模板的文件夾下又建立了一個temp文件,用來儲存每天需要更新的文件
  如果直接在模板文件夾下面的話 不用寫/    直接寫成{dede:include file="liuxingfushi.html" ismake='no'/} 即可

每天生成一次那個 自由列表的對應文件就可以了
還有dedecms里面提供了一個廣告的管理插件,我總覺得也是雞肋,生成時候肯定也受到多多少少的影響
所以我的廣告都是直接自己建立好的放在一個文件夾里面{為了防止以后忘記那個文件是那個頁面的廣告可以建立一個記事本對應廣告文件的說明}
這樣下來 模板的優化就算是做完了  注意的就是: {盡量少用{dede:field}標簽處理數據,和一些如果能用自由列表完成的全部用自由列表完成了}

/--------------------數據庫處理優化(有效)------------------------------/

可能是因為官方有所保留吧,官方的默認索引不是最優化的,需要大家手動修改下
如果是有自己獨立服務器的話建議用Navicat for MySQL 的客戶端軟件連接到MySQL Server數據上進行管理操作。

轉載一個人的數據庫優化教程

個人認為:凡是要排序的字段(比如文檔主表的 sortrank、senddate、pubdate、click、goodpost、badpost)和查詢條件的字段(比如:typeid,ismake)以及文檔ID都要建立索引,如果有一個沒有建立,將嚴重影響MySQL運行效率,導致生成HTML時速度慢。
當系統啟用了審核機制以后,標識文檔審核屬性的字段ismake必須建立索引。
注意:click這個字段,記錄文檔點擊量,此字段值更新頻繁,建立索引后對系統維護索引帶來一定的負荷,我已經試驗了不只是慢,很慢,所以大家不要給這個加索引,大家自己權衡。有人說頻繁更新的字段建立索引會容易導致數據庫損壞,這個我還沒有遇到過,需要考證。
下面是主表索引建立的截圖

\

可能有些人看到那個有個教程是刪除typeid的字段這個大家自己研究看看刪除了索引好點還是留着好點,我自己留着

 

這樣優化的話,最低生成速度差不多1分鍾能上7到8百片文章速度
如果其他人還有什么優化高招可以自己補上大家一起學習進步


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM