歡迎來到合肥浪訊網(wǎng)絡(luò)科技有限公司官網(wǎng)
  咨詢服務(wù)熱線:400-099-8848

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

發(fā)布時(shí)間:2020-02-07 文章來源:本站  瀏覽次數(shù):2726

網(wǎng)站優(yōu)化需求考慮的方面

在用ASP.NET開發(fā)網(wǎng)站的時(shí)分,功能是永久需求考慮和重視的問題,功能不僅僅僅僅程序代碼履行時(shí)分的速度,而是涉及到方方面面的東西。

就拿ASP.NET的一個(gè)懇求來講,從瀏覽器向服務(wù)器的ASP.NET網(wǎng)站發(fā)送懇求開始一向到最后整個(gè)頁面出現(xiàn)在咱們面前,其中懇求通過的每一個(gè)進(jìn)程,都是有不同的調(diào)優(yōu)辦法的,而且調(diào)用的辦法也許多,不僅僅僅僅常見的:緩存,多線程,異步等。

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

前臺(tái)調(diào)優(yōu):主要包含怎么盡量的削減http懇求,從http懇求開始,到怎么加載js, css,怎么壓縮傳輸?shù)臄?shù)據(jù)等。

后臺(tái)調(diào)優(yōu):剖析ASP.NET懇求的處理進(jìn)程,并在每一步給出相應(yīng)的調(diào)優(yōu)辦法,而且在代碼組織,架構(gòu)和數(shù)據(jù)庫的操作上面給出調(diào)優(yōu)的辦法。

記得在剛剛開發(fā)網(wǎng)站的時(shí)分,一說到進(jìn)步功能,最簡單也是最快想到的便是緩存,而且在微軟官方的Best Practice的一些文檔中也是主張:層層緩存(在數(shù)據(jù)存儲(chǔ)層,DAL,BLL,UI等都要緩存)。然后在網(wǎng)站中就”緩存遍地開花”,最后的確實(shí)不盡人意。

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

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

而且在項(xiàng)目中咱們規(guī)劃數(shù)據(jù)庫的時(shí)分,特別是表字段的時(shí)分,是需求有些考慮的,許多人主張表字段的長度不要太長,這也是大家常見的主張,可是為什么?其實(shí),這就需求懂得一些數(shù)據(jù)庫的內(nèi)部存儲(chǔ)機(jī)制了:在數(shù)據(jù)庫(SQL SERVER )保存的時(shí)分,數(shù)據(jù)是以”頁”為最小的單位的,每一頁有8K的大小,假如你的一個(gè)表中的數(shù)據(jù)超越8K,那么這個(gè)表的數(shù)據(jù)就要分幾個(gè)頁面保存,這樣在對(duì)數(shù)據(jù)進(jìn)行查詢的時(shí)分,就要跨頁查詢了,跨頁是需求功能消耗的,假如數(shù)據(jù)都在一個(gè)頁面上,那么速度必定快些。

所以,要優(yōu)化網(wǎng)站,就得知道功能消耗在哪里。

當(dāng)優(yōu)化的一個(gè)網(wǎng)站的時(shí)分,不是盲目的一概而論的,一般來說有兩種情況:

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

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

假如是第一種情況,那么首先要找出網(wǎng)站功能的瓶頸,從前臺(tái)的懇求的到后臺(tái)的懇求處理,一向到最后頁面的出現(xiàn),都要一步步的檢查。

假如是第二種情況,可能情況就稍微好一點(diǎn),而且網(wǎng)站現(xiàn)在完全由咱們操控,一切在開發(fā)和規(guī)劃的進(jìn)程中就可以采用許多的優(yōu)化準(zhǔn)則來優(yōu)化。

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

不知道大家是否有過這樣的體會(huì):當(dāng)看著自己開發(fā)出來的體系功能很好的時(shí)分,自己是很自傲的,相反,假如體系很慢,有時(shí)真不想說這個(gè)體系是自己做的

上一條:互聯(lián)網(wǎng)產(chǎn)品規(guī)劃要有勇氣重...

下一條:網(wǎng)站改版或許遇到的幾種狀...