ASP.NET網(wǎng)站性能優(yōu)化需要考慮的方面

網(wǎng)站優(yōu)化需要思量的方面

在用ASP.NET開(kāi)發(fā)網(wǎng)站的時(shí)間，性能是永遠(yuǎn)需要思量和關(guān)注的問(wèn)題，性能不僅僅只是法式代碼執(zhí)行時(shí)間的速率，而是涉及到方方面面的工具。

就拿ASP.NET的一個(gè)請(qǐng)求來(lái)講，從瀏覽器向服務(wù)器的ASP.NET網(wǎng)站發(fā)送請(qǐng)求*****一直到最后整個(gè)頁(yè)面泛起在我們眼前，其中請(qǐng)求經(jīng)由的每一個(gè)步驟，都是有差異的調(diào)優(yōu)方式的，而且挪用的要領(lǐng)也許多，不僅僅只是常見(jiàn)的：緩存，多線程，異步等。

本系列的文章決議從兩個(gè)大的方面來(lái)講述調(diào)優(yōu)：

前臺(tái)調(diào)優(yōu)：主要包羅若何只管的鐫汰h(huán)ttp請(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)要領(lǐng)，而且在代碼組織，架構(gòu)和數(shù)據(jù)庫(kù)的操作上面給出調(diào)優(yōu)的要領(lǐng)。

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

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

而且尚有一個(gè)體會(huì)就是，在優(yōu)化性能的時(shí)間，若是選擇優(yōu)化代碼和數(shù)據(jù)庫(kù)，往往優(yōu)化數(shù)據(jù)庫(kù)的一些操作帶來(lái)的效果會(huì)越發(fā)的好，很惋惜的是：在項(xiàng)目中（至少在我開(kāi)發(fā)的一些項(xiàng)目中），數(shù)據(jù)庫(kù)僅僅就只是一個(gè)數(shù)據(jù)的存儲(chǔ)裝備而已，僅此而已，沒(méi)有施展出數(shù)據(jù)庫(kù)的強(qiáng)盛作用。以是照舊建議對(duì)數(shù)據(jù)庫(kù)的內(nèi)部查詢和存儲(chǔ)的機(jī)制要熟悉，事實(shí)許多時(shí)間開(kāi)發(fā)職員也擔(dān)任了DBA的事情（許多公司沒(méi)有正式的DBA）。

而且在項(xiàng)目中我們?cè)O(shè)計(jì)數(shù)據(jù)庫(kù)的時(shí)間，稀奇是表字段的時(shí)間，是需要有些思量的，許多人建議表字段的長(zhǎng)度不要太長(zhǎng)，這也是各人常見(jiàn)的建議，可是為什么？著實(shí)，這就需要明確一些數(shù)據(jù)庫(kù)的內(nèi)部存儲(chǔ)機(jī)制了：在數(shù)據(jù)庫(kù)（SQL SERVER ）生計(jì)的時(shí)間，數(shù)據(jù)是以”頁(yè)”為最小的單元的，每一頁(yè)有8K的巨細(xì)，若是你的一個(gè)表中的數(shù)據(jù)凌駕8K，那么這個(gè)表的數(shù)據(jù)就要分幾個(gè)頁(yè)面生計(jì)，這樣在對(duì)數(shù)據(jù)舉行查詢的時(shí)間，就要跨頁(yè)查詢了，跨頁(yè)是需要性能消耗的，若是數(shù)據(jù)都在一個(gè)頁(yè)面上，那么速率一定快些。

以是，要優(yōu)化網(wǎng)站，就得知道性能消耗在那里。

當(dāng)優(yōu)化的一個(gè)網(wǎng)站的時(shí)間，不是盲目的一概而論的，一樣尋常來(lái)說(shuō)有兩種情形：

1、網(wǎng)站已經(jīng)存在了，而且運(yùn)行了，現(xiàn)在要優(yōu)化。

2、正在重新開(kāi)發(fā)一個(gè)新的網(wǎng)站。

若是是*****種情形，那么首先要找出網(wǎng)站性能的瓶頸，以前臺(tái)的請(qǐng)求的到后臺(tái)的請(qǐng)求處置賞罰，一直到最后頁(yè)面的泛起，都要一步步的審查。

若是是第二種情形，可能情形就稍微好一點(diǎn)，而且網(wǎng)站現(xiàn)在完全由我們控制，所有在開(kāi)發(fā)和設(shè)計(jì)的歷程中就可以接納許多的優(yōu)化原則來(lái)優(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)整一下載入的文件，或者異步的載入劇本，或者通過(guò)CDN傳輸劇本等等要領(lǐng)，性能就提升了。性能的提升也不是沒(méi)有價(jià)錢的，有的價(jià)錢很小，例如只是把劇本的載入放在頁(yè)面最后，大的價(jià)錢就是，例如買些服務(wù)器裝備，如Content Delivery Network（CDN）來(lái)把靜態(tài)的文件（js，css，image）傳送到客戶端。以是說(shuō)，優(yōu)化需要權(quán)衡戰(zhàn)略。

不知道各人是否有過(guò)這樣的體會(huì)：當(dāng)看著自己開(kāi)發(fā)出來(lái)的系統(tǒng)性能很好的時(shí)間，自己是很自信的，相反，若是系統(tǒng)很慢，有時(shí)真不想說(shuō)這個(gè)系統(tǒng)是自己做的。