還是因為一個表的大數(shù)據(jù)造成性能嚴重下降?難道我們必須通過分多個表來存儲才能解決問題嗎?以下我們通過一個實例來解析和優(yōu)化dedecms的數(shù)據(jù)管理性能,千萬別讓mysql當替罪羊,罪莫大焉。
測試數(shù)據(jù)是無意中得到的企業(yè)黃頁的數(shù)據(jù),數(shù)據(jù)量將近90萬,都是完全真實的數(shù)據(jù),測試使用的程序是dedecms4.0版本,你問為什么不用dedecms5.1?那是因為我們?yōu)榱藘?yōu)化,針對dedecms做了很多修改,如果使用dedecms5.1,我們害怕收到法院傳票……,補充一句,以下的優(yōu)化方法均能在dedecms5.1中使用,請在理解其原理的基礎(chǔ)上自行完成。
未優(yōu)化前我們測試發(fā)現(xiàn)主要有三個經(jīng)常性的操作在dede大數(shù)據(jù)量的情況下影響管理性能,分別是文檔生成、列表頁生成和欄目列出所有文章,我們就針對這三個方面進行優(yōu)化實踐。
以下是測試數(shù)據(jù)的基本信息:
文檔數(shù)量接近90萬
每個欄目包含近3萬數(shù)據(jù)
1.改進文檔生成速度
問題提出
和我們前一次測評結(jié)果相同,dedecms的文檔的生成速度慘不忍睹。使用默認模板(article_article.htm),平均接近30秒才能生成20個頁面(如圖),按照這個速度生成下去,90萬的數(shù)據(jù)全部生成網(wǎng)頁能等到頭發(fā)都白了。那么到底問題在哪里呢?
優(yōu)化前單個欄目文檔生成速度
問題分析
先排除表索引的問題,因為dede的數(shù)據(jù)庫已經(jīng)在數(shù)據(jù)主表(dede_archives)為主要字段都建立了索引。再排除主要內(nèi)容的提取效率問題,因為頁面生成過程中讀取頁面中的文章數(shù)據(jù),每次需要到主表和附表中select取得id值唯一的數(shù)據(jù)內(nèi)容,這個SQL語句的效率我們通過直接在mysql中運行SQL語句測試,執(zhí)行時間非常短,因此這也不是最大的瓶頸。
終于在頁面生成過程中,我們發(fā)現(xiàn)程序執(zhí)行了數(shù)次主表(dede_archives)查詢,并取出符合一組復雜查詢條件數(shù)據(jù)的操作,查詢效率非常低,原來是它在影響效率!通過調(diào)試跟蹤,我們定位了問題的關(guān)鍵,元兇就是模板中arclist標簽。Arclist標簽是很多人很喜歡用的標簽,因為它比較靈活,能從數(shù)據(jù)中取出熱門、最新、相關(guān)等各種類型的文章列表,但是arclist標簽每次都會帶著一大推搜索條件去主表中查詢,實際上對于一次性生成大量文章來說,如果使用相同的模板,arclist對數(shù)據(jù)庫的查詢操作只是簡單機械重復罷了,為此而耗費了大量時間絕對是不值得的。接下來我們給出問題解決的建議。
解決問題
解決方案1:去掉最終頁面模板中的arclist標簽,或者盡可能少用。這個方法雖然能極大提高效率,但是無異于潑水把孩子潑走了,對于企圖增加訪問pv的網(wǎng)站來說,不建議使用。
解決方案2:建立arclist緩存,將每次arclist生成的數(shù)據(jù)放到臨時目錄或者緩存當中,在文檔生成過程中判斷緩存是否有更新,如果無更新,直接使用緩存數(shù)據(jù)。這個方法無需改變模板,對于提高生成效率也有一定的效果,但由于對程序改動較大,酌情考慮使用。
解決方案3:也是小組建議的解決方案,那就是充分挖掘現(xiàn)有dedecms的功能,在盡量不改變程序的基礎(chǔ)上,大幅提高效率。具體的方法就是通過freelist(自由列表生成)功能事先生成熱門文章、最新文章、相關(guān)文章等內(nèi)容的列表頁面,然后使用dedecms提供的include標簽直接引入文檔頁面。標簽格式為:{dede:include file='列表頁面文件名稱' ismake=' no'/}。這個方案優(yōu)點在于僅增加部分操作步驟,沒有改動任何程序,性能提高亦非常明顯。下圖就是我們利用這個方法優(yōu)化后的生成速度,僅用時50秒就完成了1500多頁的文章生成,達成目標優(yōu)化效果。此方案由于增加了操作步驟,懶人慎用。
優(yōu)化后單個欄目文檔生成速度
2.改進列表頁面生成速度
問題提出
接下來我們繼續(xù)測試列表頁面的生成,這次我們學乖了,先把模板(list_article.htm)中的arclist標簽刪除后再測試,但是生成效果依然非常不理想。如下圖,每個列表頁面生成時間接近20秒(我們修改了頁面結(jié)果輸出提示,為了大家更方便看到每個列表頁面生成時間),按照每頁50條數(shù)據(jù)計算,生成單個欄目的3萬數(shù)據(jù)理論上也要花費3個多小時,生成90萬數(shù)據(jù)……無語ing。由于列表內(nèi)容使用的是list標簽,這是一個和arclist有點類似的標簽,因此我們不能延續(xù)上面的做法來解決問題,只能另辟蹊徑。
優(yōu)化前的列表頁面生成速度
問題分析
由于目標鎖定在list標簽,測試的過程就簡單了。我們直接使用dedecms中l(wèi)ist的查詢語句做優(yōu)化分析,很快發(fā)現(xiàn)了問題。我們測試了list中的sql查詢語句,以下代碼就是list用來查詢數(shù)據(jù)庫中對應(yīng)條件的SQL語句,執(zhí)行時間大約為15秒,效率很不理想。
Select arc.ID,arc.title,arc.iscommend,arc.color, arc.typeid,arc.ismake,arc.money,arc.description,arc.shorttitle, arc.memberid,arc.writer,arc.postnum,arc.lastpost, arc.pubdate,arc.senddate,arc.arcrank,arc.click,arc.litpic, tp.typedir,tp.typename,tp.isdefault,tp.defaultname, tp.namerule,tp.namerule2,tp.ispart,tp.moresite,tp.siteurl from dede_archives arc left join dede_arctype tp on arc.typeid=tp.ID left join qiye_addonarticle on arc.ID = qiye_addonarticle.aid where arc.arcrank > -1 And ( ( arc.typeid='1′ ) or arc.typeid2='1′) order by arc.sortrank desc limit 0,50
我們注意到這個SQL語句中的where子句使用了and和or的多種條件判斷,經(jīng)驗告訴我們?nèi)绻樵冏泳渲惺褂昧薸n或者or語句,會導致全表掃描,這樣的話索引的效率就無法體現(xiàn)。我們簡化了where子句的判斷條件進行測試,結(jié)果發(fā)現(xiàn)刪除了or子句之后,查詢效率大幅提升,上面的查詢語句只用時不到1秒就獲得了查詢結(jié)果。這就是問題關(guān)鍵。
12下一頁閱讀全文