文檔數(shù)量接近90萬

每個欄目包含近3萬數(shù)據(jù)

        和我們前一次測評結(jié)果相同，dedecms的文檔的生成速度慘不忍睹。使用默認(rèn)模板（article_article.htm），平均接近30秒才能生成20個頁面（如圖），按照這個速度生成下去，90萬的數(shù)據(jù)全部生成網(wǎng)頁能等到頭發(fā)都白了。那么到底問題在哪里呢？

優(yōu)化前單個欄目文檔生成速度

        先排除表索引的問題，因?yàn)閐ede的數(shù)據(jù)庫已經(jīng)在數(shù)據(jù)主表（dede_archives）為主要字段都建立了索引。再排除主要內(nèi)容的提取效率問題，因?yàn)轫撁嫔蛇^程中讀取頁面中的文章數(shù)據(jù)，每次需要到主表和附表中select取得id值唯一的數(shù)據(jù)內(nèi)容，這個SQL語句的效率我們通過直接在mysql中運(yùn)行SQL語句測試，執(zhí)行時間非常短，因此這也不是最大的瓶頸。

        終于在頁面生成過程中，我們發(fā)現(xiàn)程序執(zhí)行了數(shù)次主表（dede_archives）查詢，并取出符合一組復(fù)雜查詢條件數(shù)據(jù)的操作，查詢效率非常低，原來是它在影響效率！通過調(diào)試跟蹤，我們定位了問題的關(guān)鍵，元兇就是模板中arclist標(biāo)簽。Arclist標(biāo)簽是很多人很喜歡用的標(biāo)簽，因?yàn)樗容^靈活，能從數(shù)據(jù)中取出熱門、最新、相關(guān)等各種類型的文章列表，但是arclist標(biāo)簽每次都會帶著一大推搜索條件去主表中查詢，實(shí)際上對于一次性生成大量文章來說，如果使用相同的模板，arclist對數(shù)據(jù)庫的查詢操作只是簡單機(jī)械重復(fù)罷了，為此而耗費(fèi)了大量時間絕對是不值得的。接下來我們給出問題解決的建議。

解決方案1：去掉最終頁面模板中的arclist標(biāo)簽，或者盡可能少用。這個方法雖然能極大提高效率，但是無異于潑水把孩子潑走了，對于企圖增加訪問pv的網(wǎng)站來說，不建議使用。

解決方案2：建立arclist緩存，將每次arclist生成的數(shù)據(jù)放到臨時目錄或者緩存當(dāng)中，在文檔生成過程中判斷緩存是否有更新，如果無更新，直接使用緩存數(shù)據(jù)。這個方法無需改變模板，對于提高生成效率也有一定的效果，但由于對程序改動較大，酌情考慮使用。

解決方案3：也是小組建議的解決方案，那就是充分挖掘現(xiàn)有dedecms的功能，在盡量不改變程序的基礎(chǔ)上，大幅提高效率。具體的方法就是通過freelist（自由列表生成）功能事先生成熱門文章、最新文章、相關(guān)文章等內(nèi)容的列表頁面，然后使用dedecms提供的include標(biāo)簽直接引入文檔頁面。標(biāo)簽格式為：{dede:include file='列表頁面文件名稱' ismake=' no'/}。這個方案優(yōu)點(diǎn)在于僅增加部分操作步驟，沒有改動任何程序，性能提高亦非常明顯。下圖就是我們利用這個方法優(yōu)化后的生成速度，僅用時50秒就完成了1500多頁的文章生成，達(dá)成目標(biāo)優(yōu)化效果。此方案由于增加了操作步驟，懶人慎用。