問題：拿10萬文章的動(dòng)易系統(tǒng)和10萬主題的動(dòng)網(wǎng)論壇相比，都是采用動(dòng)態(tài)頁面，單就資源占用來說，相同的服務(wù)器動(dòng)網(wǎng)可以迅速訪問，而用動(dòng)易的服務(wù)器早就死機(jī)了。假如動(dòng)易不重視這個(gè)問題會(huì)很危險(xiǎn)的。后果會(huì)很嚴(yán)重。

解答：讓我們來分析一下同樣的數(shù)據(jù)量時(shí)，動(dòng)網(wǎng)論壇為什么快，而動(dòng)易相當(dāng)占資源。

　　1、10萬主題的論壇的數(shù)據(jù)量，看起來很大，但因?yàn)?0%的貼子可能只有幾個(gè)字，查詢時(shí)與10萬篇平均1000字的文章比起來，所占用內(nèi)存等會(huì)相差多大？另外，動(dòng)網(wǎng)的前臺(tái)顯示基本上是沒有顯示內(nèi)容的，而動(dòng)易的顯示是可以自定義顯示內(nèi)容，許多網(wǎng)站也正使用了這一點(diǎn)，這一項(xiàng)功能比起來，動(dòng)易就根本不可能達(dá)到動(dòng)網(wǎng)的“快”，因?yàn)橥耆�是不同的�?yīng)用，不同的數(shù)據(jù)模式，不同的設(shè)計(jì)思想。

　　2、再來看每個(gè)頁面。動(dòng)易比動(dòng)網(wǎng)慢的頁面只有兩種頁面：首頁和大類欄目頁。

　　先看首頁，動(dòng)網(wǎng)的首頁主體部分只顯示了一級(jí)欄目的信息，這只需要一次查詢即可，只相當(dāng)于動(dòng)易首頁的欄目導(dǎo)航或頂部欄目菜單中的一級(jí)欄目部分，動(dòng)易相比較而言，在首頁不僅顯示了一級(jí)欄目，所有的欄目都顯示了。另外最重要的是，動(dòng)易首頁的每個(gè)欄目都還要查詢數(shù)據(jù)庫，以顯示每個(gè)欄目的文章列表。假如是在網(wǎng)站首頁，這些欄目還可能跨頻道，這樣為了得到正確的路徑，還要查詢相應(yīng)的頻道設(shè)置等。這樣多的功能，還要求達(dá)到論壇首頁一樣的速度？同樣在首頁，公告、友情鏈接、調(diào)查、統(tǒng)計(jì)等其他功能，動(dòng)易一項(xiàng)不少，這些都需要查詢數(shù)據(jù)庫，當(dāng)然也要消耗一些資源。首頁是大家訪問最多的頁面，就算是同樣的數(shù)據(jù)，因?yàn)閯?dòng)易相對(duì)來說，因?yàn)橐�顯示每個(gè)欄目的文章列表，這樣每個(gè)欄目要多一次查詢，20個(gè)欄目就要多20次查詢，當(dāng)然會(huì)比論壇首頁慢多了。假如把動(dòng)易首頁的顯示樣式改為論壇一樣，動(dòng)易至少可以提速幾十倍。但改成論壇的首頁樣式，還是網(wǎng)站的首頁嗎？

　　再看大類欄目頁，動(dòng)網(wǎng)論壇仍是只顯示子欄目的信息，只需一個(gè)查詢即可，只相當(dāng)于動(dòng)易大類欄目頁的子欄目導(dǎo)航功能。動(dòng)易在大類欄目頁是采用分類顯示的，所以同樣需要對(duì)每個(gè)子欄目查詢，以顯示每個(gè)子欄目的文章列表。這樣，當(dāng)大類下有20個(gè)子欄目時(shí)，除了一次查詢子欄目外，還要20次查詢每個(gè)子欄目的文章列表。這樣，當(dāng)然又要比論壇慢上幾十倍了。

　　然后看子欄目頁面，這里動(dòng)易和動(dòng)網(wǎng)的速度基本上是一樣的。因?yàn)槎贾挥幸淮尾樵儯�采用的都是�?lián)合查詢，采用了同樣的分頁算法。但論壇是不顯示貼子內(nèi)容的，而有些使用動(dòng)易的網(wǎng)站的列表是“每篇文章的標(biāo)題下面再顯示文章的內(nèi)容簡介”，這樣肯定要比論壇多占用許多資源了。

　　再看搜索結(jié)果頁，論壇默認(rèn)的是在某個(gè)欄目中進(jìn)行搜索，而動(dòng)易默認(rèn)是全站搜索，這里可想而知，速度方面又不在一個(gè)檔次上。

　　最后，我想和大家說的是，動(dòng)易在這三年的發(fā)展過程，在程序代碼和速度算法上，從未停止過優(yōu)化的進(jìn)程。我們已經(jīng)盡我們所能，把代碼和算法優(yōu)化到最好的程序。舉一些例子吧：

　　1、1.0版和2.0版是兩級(jí)分類，3.0版以后是無限級(jí)分類，功能加強(qiáng)了，但也帶來一個(gè)速度方面的大影響。懂點(diǎn)程序的人應(yīng)該都知道，在兩級(jí)分類時(shí)，我要查詢屬于某個(gè)大類的文章時(shí)，只需簡單的一句查詢代碼（select * from PE_Article where BigClassID=2)即可。到了無限級(jí)欄目，則要針對(duì)某個(gè)大類，先查詢出他下面的所有小類(select ClassID from PE_Class where ParentID=2)，這樣得到一個(gè)欄目ID數(shù)組（如2,6,8,11,35,87)，然后必須這樣查詢(select * from PE_Article where ClassID in (2,6,8,11,35,87)，才能得到這個(gè)大類的所有文章，這樣在性能上就下降了不止10倍。這兩個(gè)查詢也可以用一個(gè)查詢來實(shí)現(xiàn)(select * from PE_Article where ClassID in (select ClassID from PE_Class where ClassID=2 or ParentID=2)，但性能是差不多的。其實(shí)這里還簡化了邏輯，因?yàn)椴�沒有考慮三級(jí)或四級(jí)以上的欄目結(jié)構(gòu)，沒有考慮這個(gè)大類欄目下有三四級(jí)子欄目的情況。所以性能方面還要下降。在2005版中，我們通過事先把屬于此欄目的所有子欄目的ID放到一個(gè)字段中，這樣就解決了了這個(gè)問題，使得無限級(jí)欄目的性能與兩級(jí)欄目的性能相差不是太大。從而使得首頁的執(zhí)行速度提升了10倍不止，欄目結(jié)構(gòu)越復(fù)雜，性能提升越明顯。

查看更多 動(dòng)易Cms教程  動(dòng)易Cms模板