ASP.NET網站功能優化需求考慮的方面

網站優化需求考慮的方面

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

就拿ASP.NET的一個懇求來講，從瀏覽器向服務器的ASP.NET網站發送懇求開始一向到最后整個頁面出現在咱們面前，其中懇求通過的每一個進程，都是有不同的調優辦法的，而且調用的辦法也許多，不僅僅僅僅常見的：緩存，多線程，異步等。

本系列的文章決定從兩個大的方面來講述調優：

前臺調優：主要包含怎么盡量的削減http懇求，從http懇求開始，到怎么加載js， css，怎么壓縮傳輸的數據等。

后臺調優：剖析ASP.NET懇求的處理進程，并在每一步給出相應的調優辦法，而且在代碼組織，架構和數據庫的操作上面給出調優的辦法。

記得在剛剛開發網站的時分，一說到進步功能，最簡單也是最快想到的便是緩存，而且在微軟官方的Best Practice的一些文檔中也是主張：層層緩存（在數據存儲層，DAL，BLL，UI等都要緩存）。然后在網站中就”緩存遍地開花”，最后的確實不盡人意。

另外的一個常見的優化針對數據庫的：如盡量削減子查詢，使用join聯接；在常常需求查詢的字段上面樹立索引。確實，這些是很通用，也不錯的一些規矩。

而且還有一個體會便是，在優化功能的時分，假如選擇優化代碼和數據庫，往往優化數據庫的一些操作帶來的作用會更加的好，很可惜的是：在項目中（至少在我開發的一些項目中），數據庫僅僅就僅僅一個數據的存儲設備罷了，僅此罷了，沒有發揮出數據庫的強大作用。所以還是主張對數據庫的內部查詢和存儲的機制要熟悉，畢竟許多時分開發人員也擔任了DBA的工作（許多公司沒有正式的DBA）。

而且在項目中咱們規劃數據庫的時分，特別是表字段的時分，是需求有些考慮的，許多人主張表字段的長度不要太長，這也是大家常見的主張，可是為什么？其實，這就需求懂得一些數據庫的內部存儲機制了：在數據庫（SQL SERVER ）保存的時分，數據是以”頁”為最小的單位的，每一頁有8K的大小，假如你的一個表中的數據超越8K，那么這個表的數據就要分幾個頁面保存，這樣在對數據進行查詢的時分，就要跨頁查詢了，跨頁是需求功能消耗的，假如數據都在一個頁面上，那么速度必定快些。

所以，要優化網站，就得知道功能消耗在哪里。

當優化的一個網站的時分，不是盲目的一概而論的，一般來說有兩種情況：

1、網站已經存在了，而且運行了，現在要優化。

2、正在從頭開發一個新的網站。

假如是第一種情況，那么首先要找出網站功能的瓶頸，從前臺的懇求的到后臺的懇求處理，一向到最后頁面的出現，都要一步步的檢查。

假如是第二種情況，可能情況就稍微好一點，而且網站現在完全由咱們操控，一切在開發和規劃的進程中就可以采用許多的優化準則來優化。

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

不知道大家是否有過這樣的體會：當看著自己開發出來的體系功能很好的時分，自己是很自傲的，相反，假如體系很慢，有時真不想說這個體系是自己做的