導(dǎo)讀：作者燕洋天寫了一系列關(guān)于ASP.NET的文章。我有段時(shí)間沒有寫ASP.NET的東西了，心里總是覺得缺少了什么，畢竟自己對(duì)ASP.NET還是情有獨(dú)鐘的。在本系列文章中，準(zhǔn)備比較全面的講述ASP.NET的性能的優(yōu)化，從前臺(tái)到后臺(tái)，以后本列文也看作為大家的一個(gè)手冊(cè)來查詢！以下是文章內(nèi)容：

在用ASP.NET開發(fā)網(wǎng)站的時(shí)候，性能是永遠(yuǎn)需要考慮和關(guān)注的問題，性能不僅僅只是程序代碼執(zhí)行時(shí)候的速度，而是涉及到方方面面的東西。

就拿ASP.NET的一個(gè)請(qǐng)求來講，從瀏覽器向服務(wù)器的ASP.NET網(wǎng)站發(fā)送請(qǐng)求開始一直到最后整個(gè)頁(yè)面呈現(xiàn)在我們面前，其中請(qǐng)求經(jīng)過的每一個(gè)步驟，都是有不同的調(diào)優(yōu)方式的，而且調(diào)用的方法也很多，不僅僅只是常見的：緩存，多線程，異步等。

前臺(tái)調(diào)優(yōu)：主要包含如何盡量的減少http請(qǐng)求，從http請(qǐng)求開始，到如何加載js， css，如何壓縮傳輸?shù)臄?shù)據(jù)等。

后臺(tái)調(diào)優(yōu)：分析ASP.NET請(qǐng)求的處理過程，并在每一步給出相應(yīng)的調(diào)優(yōu)方法，而且在代碼組織，架構(gòu)和數(shù)據(jù)庫(kù)的操作上面給出調(diào)優(yōu)的方法。

記得在剛剛開發(fā)網(wǎng)站的時(shí)候，一提到提高性能，最容易也是最快想到的就是緩存，而且在微軟官方的Best Practice的一些文檔中也是建議：層層緩存（在數(shù)據(jù)存儲(chǔ)層，DAL，BLL，UI等都要緩存）。然后在網(wǎng)站中就緩存遍地開花，最后的確實(shí)不盡人意。

另外的一個(gè)常見的優(yōu)化針對(duì)數(shù)據(jù)庫(kù)的：如盡量減少子查詢，使用join聯(lián)接；在常常需要查詢的字段上面建立索引。確實(shí)，這些是很通用，也不錯(cuò)的一些規(guī)則。

而且還有一個(gè)體會(huì)就是，在優(yōu)化性能的時(shí)候，如果選擇優(yōu)化代碼和數(shù)據(jù)庫(kù)，往往優(yōu)化數(shù)據(jù)庫(kù)的一些操作帶來的效果會(huì)更加的好，很可惜的是：在項(xiàng)目中（至少在我開發(fā)的一些項(xiàng)目中），數(shù)據(jù)庫(kù)僅僅就只是一個(gè)數(shù)據(jù)的存儲(chǔ)設(shè)備而已，僅此而已，沒有發(fā)揮出數(shù)據(jù)庫(kù)的強(qiáng)大作用。所以還是建議對(duì)數(shù)據(jù)庫(kù)的內(nèi)部查詢和存儲(chǔ)的機(jī)制要熟悉，畢竟很多時(shí)候開發(fā)人員也擔(dān)任了DBA的工作（很多公司沒有正式的DBA）。

而且在項(xiàng)目中我們?cè)O(shè)計(jì)數(shù)據(jù)庫(kù)的時(shí)候，特別是表字段的時(shí)候，是需要有些考慮的，很多人建議表字段的長(zhǎng)度不要太長(zhǎng)，這也是大家常見的建議，但是為什么？其實(shí)，這就需要懂得一些數(shù)據(jù)庫(kù)的內(nèi)部存儲(chǔ)機(jī)制了：在數(shù)據(jù)庫(kù)（SQL SERVER ）保存的時(shí)候，數(shù)據(jù)是以頁(yè)為最小的單位的，每一頁(yè)有K的大小，如果你的一個(gè)表中的數(shù)據(jù)超過K，那么這個(gè)表的數(shù)據(jù)就要分幾個(gè)頁(yè)面保存，這樣在對(duì)數(shù)據(jù)進(jìn)行查詢的時(shí)候，就要跨頁(yè)查詢了，跨頁(yè)是需要性能消耗的，如果數(shù)據(jù)都在一個(gè)頁(yè)面上，那么速度肯定快些。

如果是第一種情況，那么首先要找出網(wǎng)站性能的瓶頸，從前臺(tái)的請(qǐng)求的到后臺(tái)的請(qǐng)求處理，一直到最后頁(yè)面的呈現(xiàn)，都要一步步的審查。

如果是第二種情況，可能情況就稍微好一點(diǎn)，并且網(wǎng)站現(xiàn)在完全由我們控制，所有在開發(fā)和設(shè)計(jì)的過程中就可以采用很多的優(yōu)化原則來優(yōu)化。

優(yōu)化不一定就是代碼重寫或者做些很大的改動(dòng)，優(yōu)化時(shí)一點(diǎn)點(diǎn)的累積的，就好比代碼的重構(gòu)一樣，都是一個(gè)積累的效果。比如，是在頁(yè)面一開始的時(shí)候載入js腳本，還是在整個(gè)頁(yè)面的最后載入js腳本，有時(shí)候往往就只是簡(jiǎn)單的調(diào)整一下載入的文件，或者異步的載入腳本，或者通過CDN傳輸腳本等等方法，性能就提升了。性能的提升也不是沒有代價(jià)的，有的代價(jià)很小，例如只是把腳本的載入放在頁(yè)面最后，大的代價(jià)就是，例如買些服務(wù)器設(shè)備，如Content Delivery Network（CDN）來把靜態(tài)的文件（js，css，image）傳送到客戶端。所以說，優(yōu)化需要權(quán)衡策略。

不知道大家是否有過這樣的體會(huì)：當(dāng)看著自己開發(fā)出來的系統(tǒng)性能很好的時(shí)候，自己是很自信的，相反，如果系統(tǒng)很慢，有時(shí)真不想說這個(gè)系統(tǒng)是自己做的。