網(wǎng)站優(yōu)化需要考慮的方面(asp.net構(gòu)建高性能站點)!
發(fā)布時間:2011/06/17
字體:大中小
摘要:網(wǎng)站優(yōu)化需要考慮的方面(asp.net構(gòu)建高性能站點)!,如何用asp.net構(gòu)建高性能站點 如何優(yōu)化asp.net構(gòu)建的站點,如何用asp.net構(gòu)建高性能站點 如何優(yōu)化asp.net構(gòu)建的高性能?在用ASP.NET開發(fā)網(wǎng)站的時候,性能是永遠(yuǎn)需要考慮和關(guān)注的問題!
如何用asp.net構(gòu)建高性能站點 如何優(yōu)化asp.net構(gòu)建的高性能站點?在用ASP.NET開發(fā)網(wǎng)站的時候,性能是永遠(yuǎn)需要考慮和關(guān)注的問題,性能不僅僅只是程序代碼執(zhí)行時候的速度,而是涉及到方方面面的東西。
合肥網(wǎng)絡(luò)公司就此總結(jié)如下:
就拿ASP.NET的一個請求來講,從瀏覽器向服務(wù)器的ASP.NET網(wǎng)站發(fā)送請求開始一直到最后整個頁面呈現(xiàn)在我們面前,其中請求經(jīng)過的每一個步驟,都是有不同的調(diào)優(yōu)方式的,而且調(diào)用的方法也很多,不僅僅只是常見的:緩存,多線程,異步等。
本系列的文章決定從兩個大的方面來講述調(diào)優(yōu):
前臺調(diào)優(yōu):主要包含如何盡量的減少http請求,從http請求開始,到如何加載js, css,如何壓縮傳輸?shù)臄?shù)據(jù)等。
后臺調(diào)優(yōu):分析ASP.NET請求的處理過程,并在每一步給出相應(yīng)的調(diào)優(yōu)方法,而且在代碼組織,架構(gòu)和數(shù)據(jù)庫的操作上面給出調(diào)優(yōu)的方法。
記得在剛剛開發(fā)網(wǎng)站的時候,一提到提高性能,最容易也是最快想到的就是緩存,而且在微軟官方的Best Practice的一些文檔中也是建議:層層緩存(在數(shù)據(jù)存儲層,DAL,BLL,UI等都要緩存)。然后在網(wǎng)站中就”緩存遍地開花”,最后的確實不盡人意。
另外的一個常見的優(yōu)化針對數(shù)據(jù)庫的:如盡量減少子查詢,使用join聯(lián)接;在常常需要查詢的字段上面建立索引。確實,這些是很通用,也不錯的一些規(guī)則。
而且還有一個體會就是,在優(yōu)化性能的時候,如果選擇優(yōu)化代碼和數(shù)據(jù)庫,往往優(yōu)化數(shù)據(jù)庫的一些操作帶來的效果會更加的好,很可惜的是:在項目中(至少在我開發(fā)的一些項目中),數(shù)據(jù)庫僅僅就只是一個數(shù)據(jù)的存儲設(shè)備而已,僅此而已,沒有發(fā)揮出數(shù)據(jù)庫的強大作用。所以還是建議對數(shù)據(jù)庫的內(nèi)部查詢和存儲的機制要熟悉,畢竟很多時候開發(fā)人員也擔(dān)任了DBA的工作(很多公司沒有正式的DBA)。
而且在項目中我們設(shè)計數(shù)據(jù)庫的時候,特別是表字段的時候,是需要有些考慮的,很多人建議表字段的長度不要太長,這也是大家常見的建議,但是為什么?其實,這就需要懂得一些數(shù)據(jù)庫的內(nèi)部存儲機制了:在數(shù)據(jù)庫(SQL SERVER )保存的時候,數(shù)據(jù)是以”頁”為最小的單位的,每一頁有8K的大小,如果你的一個表中的數(shù)據(jù)超過8K,那么這個表的數(shù)據(jù)就要分幾個頁面保存,這樣在對數(shù)據(jù)進行查詢的時候,就要跨頁查詢了,跨頁是需要性能消耗的,如果數(shù)據(jù)都在一個頁面上,那么速度肯定快些。
所以,要優(yōu)化網(wǎng)站,就得知道性能消耗在哪里。
當(dāng)優(yōu)化的一個網(wǎng)站的時候,不是盲目的一概而論的,一般來說有兩種情況:
1、網(wǎng)站已經(jīng)存在了,并且運行了,現(xiàn)在要優(yōu)化。
2、正在從頭開發(fā)一個新的網(wǎng)站。
如果是第一種情況,那么首先要找出網(wǎng)站性能的瓶頸,從前臺的請求的到后臺的請求處理,一直到最后頁面的呈現(xiàn),都要一步步的審查。
如果是第二種情況,可能情況就稍微好一點,并且網(wǎng)站現(xiàn)在完全由我們控制,所有在開發(fā)和設(shè)計的過程中就可以采用很多的優(yōu)化原則來優(yōu)化。
優(yōu)化不一定就是代碼重寫或者做些很大的改動,優(yōu)化時一點點的累積的,就好比代碼的重構(gòu)一樣,都是一個積累的效果。
比如,是在頁面一開始的時候載入js腳本,還是在整個頁面的最后載入js腳本,有時候往往就只是簡單的調(diào)整一下載入的文件,或者異步的載入腳本,或者通過CDN傳輸腳本等等方法,性能就提升了。性能的提升也不是沒有代價的,有的代價很小,例如只是把腳本的載入放在頁面最后,大的代價就是,例如買些服務(wù)器設(shè)備,如Content Delivery Network(CDN)來把靜態(tài)的文件(js,css,image)傳送到客戶端。所以說,優(yōu)化需要權(quán)衡策略。
不知道大家是否有過這樣的體會:當(dāng)看著自己開發(fā)出來的系統(tǒng)性能很好的時候,自己是很自信的,相反,如果系統(tǒng)很慢,有時真不想說這個系統(tǒng)是自己做的。