編寫高性能Web應(yīng)用程序的10個技巧
linux寶庫 收集整理　 作者：linux寶庫　 時間：2007-09-30　 收藏本站

來自：linux寶庫 聯(lián)系：linuxmine#gmail.com 分類：[ASP.NET] 　　用 ASP.NET 編寫 Web 應(yīng)用程序其輕松程度令人難以置信。它是如此的容易，以至于許多開發(fā)人員不用花費多少時間來構(gòu)筑其應(yīng)用便能獲得非常好的性能。在本文中，我將給出10個編寫高性能 Web 應(yīng)用的技巧。我的評論不僅僅局限與 ASP.NET 應(yīng)用，因為它們只是 Web 應(yīng)用的一個子集。本文也不是 Web 應(yīng)用性能調(diào)整的權(quán)威指南――這方面的內(nèi)容可以寫成一本書。相反，本文可以被視作一個好的起點。 　　在廢寢忘食地工作之前，我常常要去攀巖。在攀巖之前，我總是要看一下指南手冊中的線路并閱讀以前來此一游的人留下的建議和忠告。但是，不管指南手冊有多磨好，在嘗試一次特定的具有挑戰(zhàn)性的攀爬之前，你都必須付諸實際的行動。同樣，在你面臨解決的性能問題或者營運一個高吞吐量的站點之前，你只能想方設(shè)法編寫高性能 Web 應(yīng)用程序。 　　我們個人經(jīng)驗來自在微軟 ASP.NET 團(tuán)隊從事底層架構(gòu)程序經(jīng)理，運行和管理 www.asp.net ,并協(xié)助架構(gòu) Community Server 過程中的經(jīng)歷，Community Server 是幾個有名的 ASP.NET 應(yīng)用程序的下一個版本（它將 ASP.NET Forums，.Text 和 nGallery 整合到一個平臺）。我確信這些幫助過我的技巧也會對你有所裨益。 　　你應(yīng)該考慮將應(yīng)用程序分離成幾個邏輯層。你可能聽說過術(shù)語3-層（或n-層）物理體系結(jié)構(gòu)。它們通常是跨進(jìn)程和/或硬件對功能進(jìn)行物理劃分的規(guī)定的體系結(jié)構(gòu)模式。當(dāng)系統(tǒng)需要伸縮時，更多的硬件能被添加。然而，總是應(yīng)該避免與進(jìn)程和機(jī)器忙碌程度相關(guān)的性能問題。所以，不管什么時候，只要可能，都要在相同的應(yīng)用中一起運行 ASP.NET 頁面及其相關(guān)的組件。 　　由于代碼和層之間的邊界分離，使用 Web 服務(wù)或遠(yuǎn)程調(diào)用將降低20%以上的性能。 　　數(shù)據(jù)層則稍微有些不同，因為數(shù)據(jù)庫通常都用專門的硬件。但是，數(shù)據(jù)庫的處理成本仍然很高，因此最優(yōu)化代碼時，數(shù)據(jù)層的性能應(yīng)該是首當(dāng)其充要關(guān)注的地方。 　　在著手解決你的應(yīng)用程序的性能問題之前，一定要剖析應(yīng)用程序，確定問題之所在。獲取關(guān)鍵的性能計數(shù)器值（如實現(xiàn)垃圾收集所花時間之百分比的性能計數(shù)器的值）對于查找應(yīng)用程序在何處最耗時也是非常重要的。憑借直覺常常也能找到耗時所在。 　　本文所描述的性能改進(jìn)有兩種類型：大型優(yōu)化，如使用 ASP.NET Cache，以及不斷重復(fù)進(jìn)行的微型優(yōu)化。這些微型優(yōu)化有時很有意思。對代碼的小小改動便會引起很大的動靜，產(chǎn)生成千次的調(diào)用。對于大型優(yōu)化，你可能會看到整體性能的大跳躍。而對微型優(yōu)化，給定請求可能只是毫秒級的調(diào)整，但按每天的請求總數(shù)計算，其結(jié)果的改進(jìn)可能是巨大的。 　　數(shù)據(jù)層的性能 　　當(dāng)調(diào)整某個應(yīng)用程序的性能時，有一個簡單的試金石，你可以用它按先后次序：檢查代碼是否存取數(shù)據(jù)庫？如果是，多長時間存取一次？注意相同的測試也可以被應(yīng)用于使用 Web 服務(wù)或遠(yuǎn)程調(diào)用的代碼，但我們本文中不涉及這方面內(nèi)容。 　　如果在特定的代碼流程中必須具有對數(shù)據(jù)庫的請求以及要考察其它方面，如：想對字符串處理進(jìn)行優(yōu)先優(yōu)化，那么暫且把它放一放，先按照上面定好的優(yōu)先次序來做。除非你有異乎尋常的性能問題，否則你的時間應(yīng)該用在嘗試最優(yōu)化與數(shù)據(jù)庫的連接所花的時間，返回的數(shù)據(jù)量以及多長時間往返一次和數(shù)據(jù)庫的通訊上。 　　有了這些概括信息，下面就讓我們來看看能幫助你改善應(yīng)用程序性能的十個技巧。我將從能獲得最顯著效果的改變開始。 　　技巧 1 ―― 返回多個結(jié)果集 　　復(fù)審你的數(shù)據(jù)庫代碼，看看是否有多于一次的對數(shù)據(jù)庫的訪問請求。這樣每次往返數(shù)據(jù)庫都降低你的應(yīng)用程序能處理的每秒請求數(shù)。通過在單個數(shù)據(jù)庫請求中返回多結(jié)果集，你能降低與數(shù)據(jù)庫通信的總體時間。同時你也將使系統(tǒng)更具伸縮性，因為你減少了數(shù)據(jù)庫服務(wù)器處理請求的負(fù)擔(dān)。 　　雖然你可以用動態(tài) SQL 返回多結(jié)果集，我更喜歡使用存儲過過程。是否將業(yè)務(wù)邏輯駐留在存儲過程當(dāng)中是個有待爭論的問題，但我認(rèn)為，如果存儲過程中的邏輯能約束返回的數(shù)據(jù)（降低數(shù)據(jù)集的尺寸，在網(wǎng)絡(luò)上傳輸?shù)臅r間以及邏輯層不必過慮數(shù)據(jù)），這是一件好事情。 　　使用 SqlCommand 命令實例及其 ExecuteReader 方法來處理強(qiáng)類型的各個業(yè)務(wù)類，你通過調(diào)用 NextResult 可以向前移動結(jié)果集指針。Figure 1 示范了處理幾個帶類型的 ArrayLists 例子會話。從數(shù)據(jù)庫只返回你需要的數(shù)據(jù)還會降低服務(wù)器上內(nèi)存的分配。 　　技巧 2 ―― 分頁數(shù)據(jù)存取 　　ASP.NET DataGrid 提供了非常好的能力：數(shù)據(jù)分頁支持。當(dāng)啟用 DataGrid 中的分頁功能，則每次只顯示固定數(shù)量的記錄。此外，分頁用戶界面也會顯示在 DataGrid 底部用于導(dǎo)航記錄。分頁用戶界面允許你向前向后導(dǎo)航所顯示的記錄，一次顯示固定數(shù)量的記錄。 　　有一個美中不足的是用 DataGrid 分頁需要將所有數(shù)據(jù)邦定到此柵格控件（gird）。例如，你的數(shù)據(jù)層必須返回所有數(shù)據(jù)，然后 DataGrid 將根據(jù)當(dāng)前頁過濾掉所有顯示的記錄。當(dāng)你通過 DataGrid 進(jìn)行分頁時，如果有 100,000 條記錄被返回，那么每個請求有 99,975 條記錄將被廢棄掉（假設(shè)頁尺寸為 25）。當(dāng)記錄數(shù)不斷增加，此應(yīng)用程序的性能便會遭受痛苦，因為每次請求所要發(fā)送的數(shù)據(jù)會越來越多。 　　編寫較好的分頁代碼的一個好的方法是用存儲過程。Figure 2 示范了一個用 Northwind 數(shù)據(jù)庫中 Orders 表通過存儲過程分頁的例子。很簡單，只要你在頁面中傳遞索引以及頁尺寸即可。相應(yīng)的結(jié)果集先被計算然后被返回。 　　在 Community Server 中，我們編寫了幾個分頁控件來完成數(shù)據(jù)分頁。你將會看到，我使用了技巧 1 中討論的思路，從一個存儲過程中返回連個結(jié)果集：總記錄數(shù)和請求的數(shù)據(jù)。 　　返回的總記錄數(shù)依賴于所執(zhí)行的查詢不同而不同。例如，某個 WHERE 子句可被用于約束返回的數(shù)據(jù)。為了計算在分頁用戶界面顯示的總頁數(shù)，返回的總記錄數(shù)必須是已知的。例如，如果有 1,000,000 條記錄，用一個 WHERE 子句對之過濾后為 1,000 條記錄，則分頁邏輯必須要知道總記錄數(shù)以便在分頁用戶界面中正確呈現(xiàn)。 　　技巧 3 ―― 連接池 　　建立 Web 應(yīng)用程序與 SQL Server 之間的 TCP 連接是一項昂貴的操作。微軟的開發(fā)人員利用連接池技術(shù)已經(jīng)有好長一段時間了，這個技術(shù)使他們能重用到數(shù)據(jù)庫的連接。而不是每次請求都建立新的 TCP 連接，新連接僅在連接池中得不到連接時才建立。當(dāng)連接被關(guān)閉時，它被返回到連接池中，在那里它仍然保持與數(shù)據(jù)庫的連接，與完全斷開 TCP 連接相反。 　　當(dāng)然，你需要提防泄漏的連接。當(dāng)你處理完畢，一定要關(guān)閉連接。重申一次：不管人們怎么吹噓微軟 .NET 框架中的垃圾收集特性，每當(dāng)你處理完畢，一定要顯式地調(diào)用連接對象的 Close 或 Dispose 方法。不要指望公共語言運行時（CLR）來為你定時清除和關(guān)閉連接。CLR 最終將銷毀類并強(qiáng)行關(guān)閉連接，但你無法保證該對象的垃圾收集屆時會起作用。 　　為了充分用好連接池，有幾條規(guī)則必須了然于心。首先，打開連接，進(jìn)行處理，然后關(guān)閉連接。寧愿每個請求的連接打開和關(guān)閉多次，也不要保持連接打開狀態(tài)以及在不同的方法間將它傳來傳去。其次，使用相同的連接串（如果你使用集成身份檢查，那么也要用相同的線程身份）。如果你不用相同的連接串，例如，根據(jù)登錄用戶來定制連接串，你將無法得到連接池所提供的相同的最優(yōu)化值。當(dāng)模擬大用戶量情形時，如果你使用集成身份檢查，那么你的連接池將效力大減。.NET CLR 數(shù)據(jù)性能計數(shù)器在試圖跟蹤任何與連接池有關(guān)的性能問題時是非常有用的。 　　不管什么時候，只要你的應(yīng)用程序連接到運行在其它進(jìn)程中的資源，比如某個數(shù)據(jù)庫，你都應(yīng)該針對連接到資源所耗時間，發(fā)送和接收數(shù)據(jù)所耗時間以及往返次數(shù)進(jìn)行優(yōu)化。為了實現(xiàn)較好的性能，應(yīng)該首當(dāng)其充優(yōu)化應(yīng)用程序中任何種類的忙碌進(jìn)程。 　　應(yīng)用層包含到數(shù)據(jù)層的連接以及將數(shù)據(jù)轉(zhuǎn)換成有意義的類實例和業(yè)務(wù)處理的邏輯。以 Community Server 為例，你要在其中處理 Forums 和 Threads 集合；以及應(yīng)用許可這樣的業(yè)務(wù)規(guī)則；尤其重要的是緩沖（Caching）邏輯也實現(xiàn)其中。 　　技巧 4 ―― ASP.NET Cache API 　　在編寫代碼之前要做的頭等大事之一是最大限度地構(gòu)建應(yīng)用層并發(fā)掘 ASP.NET 的 Cache 特性。 　　如果你的組件在 ASP.NET 應(yīng)用程序內(nèi)運行，那么你只需要在應(yīng)用程序工程中引用 System.Web.dll 即可。當(dāng)你需要訪問 Cache 時，用 HttpRuntime.Cache 屬性（相同的對象也可以通過 Page.Cache 和 HttpContext.Cache 訪問）。 　　緩沖數(shù)據(jù)有幾個準(zhǔn)則。首先，如果數(shù)據(jù)能被使用多次，緩沖是個好的后選方案。其次，如果數(shù)據(jù)對給定請求或用戶是一般的數(shù)據(jù)而非專用數(shù)據(jù)，那么最好是選擇緩沖。如果數(shù)據(jù)用戶或請求專用，如果需要保存期很長但可能不被經(jīng)常使用，那么仍然要用緩沖。第三，常常被忽略的一個準(zhǔn)則是有時緩沖太多的東西。一般來說，在x86機(jī)器上，為了降低內(nèi)存不足錯誤的幾率，運行某個進(jìn)程不要超過800MB私有字節(jié)。因此，緩沖應(yīng)該有個上限。換句話說，你也許能重用某個計算的結(jié)果，但如果該計算有10個參數(shù)，你可能試圖針對10個置換進(jìn)行緩沖，這樣做可能會給你帶來麻煩。ASP.NET 提供的最常見的容錯是由覆蓋緩沖導(dǎo)致的內(nèi)存不足錯誤，尤其是大型數(shù)據(jù)集。 　　Cache 有幾個重要特性是必須要了解的。第一個是 Cache 實現(xiàn)了最近最少使用（least-recently-used）算法，允許 ASP.NET 強(qiáng)制 Cache 清除操作 ―― 如果可用內(nèi)存下降到低水平 ―― 則自動從 Cache 中刪除不使用的項目。第二個是 Cache 支持依賴性到期特性，它能強(qiáng)制包括時間，鍵值，文件失效。時間常常被使用，但 ASP.NET 2.0 引入了具有更強(qiáng)大的失效類型：數(shù)據(jù)庫緩沖失效。也就是當(dāng)數(shù)據(jù)庫中的數(shù)據(jù)改變時，緩沖中的條目會自動刪除。有關(guān) 本文來自：http://www.linuxpk.com/48002.html

轉(zhuǎn)載于:https://www.cnblogs.com/38809972/articles/988882.html

與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的编写高性能Web应用程序的10个技巧的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。