使用 asp.net 編寫 web 應(yīng)用程序的簡單程度令人不敢相信。正因為如此簡單，所以很多開發(fā)人員就不會花時間來設(shè)計其應(yīng)用程序的結(jié)構(gòu)，以

獲得更好的性能了。在本文中，我將講述 10 個用于編寫高性能 web 應(yīng)用程序的技巧。但是我并不會將這些建議僅局限于 asp.net 應(yīng)用程序

，因為這些應(yīng)用程序只是 web 應(yīng)用程序的一部分。本文不作為對 web 應(yīng)用程序進(jìn)行性能調(diào)整的權(quán)威性指南 — 一整本書恐怕都無法輕松講清

楚這個問題。請將本文視作一個很好的起點。

成為工作狂之前，我原來喜歡攀巖。在進(jìn)行任何大型攀巖活動之前，我都會首先仔細(xì)查看指南中的路線，閱讀以前游客提出的建議。但是，無

論指南怎么好，您都需要真正的攀巖體驗，然后才能嘗試一個特別具有挑戰(zhàn)性的攀登。與之相似，當(dāng)您面臨修復(fù)性能問題或者運(yùn)行一個高吞吐

量站點的問題時，您只能學(xué)習(xí)如何編寫高性能 web 應(yīng)用程序。

我的個人體驗來自在 microsoft 的 asp.net 部門作為基礎(chǔ)架構(gòu)程序經(jīng)理的經(jīng)驗，在此期間我運(yùn)行和管理 www.asp.net，幫助設(shè)計社區(qū)服務(wù)器

的結(jié)構(gòu)，社區(qū)服務(wù)器是幾個著名 asp.net 應(yīng)用程序（組合到一個平臺的 asp.net forums、.text 和 ngallery）。我確信有些曾經(jīng)幫助過我的

技巧對您肯定也會有所幫助。

您應(yīng)該考慮將應(yīng)用程序分為幾個邏輯層。您可能聽說過 3 層（或者 n 層）物理體系結(jié)構(gòu)一詞。這些通常都是規(guī)定好的體系結(jié)構(gòu)方式，將功能

在進(jìn)程和/或硬件之間進(jìn)行了物理分離。當(dāng)系統(tǒng)需要擴(kuò)大時，可以很輕松地添加更多的硬件。但是會出現(xiàn)一個與進(jìn)程和機(jī)器跳躍相關(guān)的性能下降

，因此應(yīng)該避免。所以，如果可能的話，請盡量在同一個應(yīng)用程序中一起運(yùn)行 asp.net 頁及其相關(guān)組件。

因為代碼分離以及層之間的邊界，所以使用 web 服務(wù)或遠(yuǎn)程處理將會使得性能下降 20% 甚至更多。

數(shù)據(jù)層有點與眾不同，因為通常情況下，最好具有專用于數(shù)據(jù)庫的硬件。然而進(jìn)程跳躍到數(shù)據(jù)庫的成本依然很高，因此數(shù)據(jù)層的性能是您在優(yōu)

化代碼時首先要考慮的問題。

在深入應(yīng)用程序的性能修復(fù)問題之前，請首先確保對應(yīng)用程序進(jìn)行剖析，以便找出具體的問題所在。主要性能計數(shù)器（如表示執(zhí)行垃圾回收所

需時間百分比的計數(shù)器）對于找出應(yīng)用程序在哪些位置花費(fèi)了其主要時間也非常有用。然而花費(fèi)時間的位置通常非常不直觀。

本文講述了兩種類型的性能改善：大型優(yōu)化（如使用 asp.net 緩存），和進(jìn)行自身重復(fù)的小型優(yōu)化。這些小型優(yōu)化有時特別有意思。您對代碼

進(jìn)行一點小小的更改，就會獲得很多很多時間。使用大型優(yōu)化，您可能會看到整體性能的較大飛躍。而使用小型優(yōu)化時，對于某個特定請求可

能只會節(jié)省幾毫秒的時間，但是每天所有請求加起來，則可能會產(chǎn)生巨大的改善。

數(shù)據(jù)層性能

談到應(yīng)用程序的性能調(diào)整，有一個試紙性的測試可用來對工作進(jìn)行優(yōu)先級劃分：代碼是否訪問數(shù)據(jù)庫？如果是，頻率是怎樣的？請注意，這一

相同測試也可應(yīng)用于使用 web 服務(wù)或遠(yuǎn)程處理的代碼，但是本文對這些內(nèi)容未做講述。

如果某個特定的代碼路徑中必需進(jìn)行數(shù)據(jù)庫請求，并且您認(rèn)為要首先優(yōu)化其他領(lǐng)域（如字符串操作），則請停止，然后執(zhí)行這個試紙性測試。

如果您的性能問題不是非常嚴(yán)重的話，最好花一些時間來優(yōu)化一下與數(shù)據(jù)庫、返回的數(shù)據(jù)量、進(jìn)出數(shù)據(jù)庫的往返頻率相關(guān)的花費(fèi)時間。

了解這些常規(guī)信息之后，我們來看一下可能會有助于提高應(yīng)用程序性能的十個技巧。首先，我要講述可能會引起最大改觀的更改。

技巧 1 — 返回多個結(jié)果集

仔細(xì)查看您的數(shù)據(jù)庫代碼，看是否存在多次進(jìn)入數(shù)據(jù)庫的請求路徑。每個這樣的往返都會降低應(yīng)用程序可以提供的每秒請求數(shù)量。通過在一個

數(shù)據(jù)庫請求中返回多個結(jié)果集，可以節(jié)省與數(shù)據(jù)庫進(jìn)行通信所需的總時間長度。同時因為減少了數(shù)據(jù)庫服務(wù)器管理請求的工作，還會使得系統(tǒng)

伸縮性更強(qiáng)。

雖然可以使用動態(tài) sql 返回多個結(jié)果集，但是我首選使用存儲過程。關(guān)于業(yè)務(wù)邏輯是否應(yīng)該駐留于存儲過程的問題還存在一些爭議，但是我認(rèn)

為，如果存儲過程中的邏輯可以約束返回數(shù)據(jù)的話（縮小數(shù)據(jù)集的大小、縮短網(wǎng)絡(luò)上所花費(fèi)時間，不必篩選邏輯層的數(shù)據(jù)），則應(yīng)贊成這樣做

。

使用 sqlcommand 實例及其 executereader 方法填充強(qiáng)類型的業(yè)務(wù)類時，可以通過調(diào)用 nextresult 將結(jié)果集指針向前移動。圖 1 顯示了使

用類型類填充幾個 arraylist 的示例會話。只從數(shù)據(jù)庫返回您需要的數(shù)據(jù)將進(jìn)一步減少服務(wù)器上的內(nèi)存分配。

技巧 2 — 分頁的數(shù)據(jù)訪問

asp.net datagrid 具有一個很好的功能：數(shù)據(jù)分頁支持。在 datagrid 中啟用分頁時，一次會顯示固定數(shù)量的記錄。另外，在 datagrid 的底

部還會顯示分頁 ui，以便在記錄之間進(jìn)行導(dǎo)航。該分頁 ui 使您能夠在所顯示的數(shù)據(jù)之間向前和向后導(dǎo)航，并且一次顯示固定數(shù)量的記錄。

還有一個小小的波折。使用 datagrid 的分頁需要所有數(shù)據(jù)均與網(wǎng)格進(jìn)行綁定。例如，您的數(shù)據(jù)層需要返回所有數(shù)據(jù)，那么 datagrid 就會基

于當(dāng)前頁篩選顯示的所有記錄。如果通過 datagrid 進(jìn)行分頁時返回了 100,000 個記錄，那么針對每個請求會放棄 99,975 個記錄（假設(shè)每頁

大小為 25 個記錄）。當(dāng)記錄的數(shù)量不斷增加時，應(yīng)用程序的性能就會受到影響，因為針對每個請求必須發(fā)送越來越多的數(shù)據(jù)。

要編寫性能更好的分頁代碼，一個極佳的方式是使用存儲過程。圖 2 顯示了針對 northwind 數(shù)據(jù)庫中的 orders 表進(jìn)行分頁的一個示例存儲

過程。簡而言之，您此時要做的只是傳遞頁索引和頁大小。然后就會計算合適的結(jié)果集，并將其返回。

在社區(qū)服務(wù)器中，我們編寫了一個分頁服務(wù)器控件，以完成所有的數(shù)據(jù)分頁。您將會看到，我使用的就是技巧 1 中討論的理念，從一個存儲過

程返回兩個結(jié)果集：記錄的總數(shù)和請求的數(shù)據(jù)。

返回記錄的總數(shù)可能會根據(jù)所執(zhí)行查詢的不同而有所變化。例如，where 子句可用來約束返回的數(shù)據(jù)。為了計算在分頁 ui 中顯示的總頁數(shù)，

必須了解要返回記錄的總數(shù)。例如，如果總共有 1,000,000 條記錄，并且要使用一個 where 子句將其篩選為 1000 條記錄，那么分頁邏輯就

需要了解記錄的總數(shù)才能正確呈現(xiàn)分頁 ui。

技巧 3 — 連接池

在 web 應(yīng)用程序和 sql server™ 之間設(shè)置 tcp 連接可能是一個非常消耗資源的操作。microsoft 的開發(fā)人員到目前為止能夠使用連接池已經(jīng)

有一段時間了，這使得他們能夠重用數(shù)據(jù)庫連接。他們不是針對每個請求都設(shè)置一個新的 tcp 連接，而是只在連接池中沒有任何連接時才設(shè)置

新連接。當(dāng)連接關(guān)閉時，它會返回連接池，在其中它會保持與數(shù)據(jù)庫的連接，而不是完全破壞該 tcp 連接。

當(dāng)然，您需要小心是否會出現(xiàn)泄漏連接。當(dāng)您完成使用連接時，請一定要關(guān)閉這些連接。再重復(fù)一遍：無論任何人對 microsoft?.net

framework 中的垃圾回收有什么評論，請一定要在完成使用連接時針對該連接顯式調(diào)用 close 或 dispose。不要相信公共語言運(yùn)行庫 (clr)

會在預(yù)先確定的時間為您清除和關(guān)閉連接。盡管 clr 最終會破壞該類，并強(qiáng)制連接關(guān)閉，但是當(dāng)針對對象的垃圾回收真正發(fā)生時，并不能保證

。

要以最優(yōu)化的方式使用連接池，需要遵守一些規(guī)則。首先打開連接，執(zhí)行操作，然后關(guān)閉該連接。如果您必須如此的話，可以針對每個請求多

次打開和關(guān)閉連接（最好應(yīng)用技巧 1），但是不要一直將連接保持打開狀態(tài)并使用各種不同的方法對其進(jìn)行進(jìn)出傳遞。第二，使用相同的連接

字符串（如果使用集成身份驗證的話，還要使用相同的線程標(biāo)識）。如果不使用相同的連接字符串，例如根據(jù)登錄的用戶自定義連接字符串，

那么您將無法得到連接池提供的同一個優(yōu)化值。如果您使用集成身份驗證，同時還要模擬大量用戶，連接池的效率也會大大下降。嘗試跟蹤與

連接池相關(guān)的任何性能問題時，.net clr 數(shù)據(jù)性能計數(shù)器可能非常有用。

每當(dāng)應(yīng)用程序連接資源時，如在另一個進(jìn)程中運(yùn)行的數(shù)據(jù)庫，您都應(yīng)該重點考慮連接該資源所花時間、發(fā)送或檢索數(shù)據(jù)所花時間，以及往返的

數(shù)量，從而進(jìn)行優(yōu)化。優(yōu)化應(yīng)用程序中任何種類的進(jìn)程跳躍都是獲得更佳性能的首要一點。

應(yīng)用層包含了連接數(shù)據(jù)層、將數(shù)據(jù)轉(zhuǎn)換為有意義類實例和業(yè)務(wù)流程的邏輯。例如社區(qū)服務(wù)器，您要在其中填充forums 或 threads集合，應(yīng)用業(yè)

務(wù)規(guī)則（如權(quán)限）；最重要的是要在其中執(zhí)行緩存邏輯。

技巧 4 — asp.net 緩存 api

編寫應(yīng)用程序代碼行之前，一個首要完成的操作是設(shè)計應(yīng)用層的結(jié)構(gòu)，以便最大化利用 asp.net 緩存功能。

如果您的組件要在 asp.net 應(yīng)用程序中運(yùn)行，則只需在該應(yīng)用程序項目中包括一個 system.web.dll 引用。當(dāng)您需要訪問該緩存時，請使用

httpruntime.cache 屬性（通過 page.cache 和 httpcontext.cache 也可訪問這個對象）。

對于緩存數(shù)據(jù)，有幾個規(guī)則。首先，如果數(shù)據(jù)可能會多次使用時，則這是使用緩存的一個很好的備選情況。第二，如果數(shù)據(jù)是通用的，而不特

定于某個具體的請求或用戶時，則也是使用緩存的一個很好的備選情況。如果數(shù)據(jù)是特定于用戶或請求的，但是壽命較長的話，仍然可以對其

進(jìn)行緩存，但是這種情況可能并不經(jīng)常使用。第三，一個經(jīng)常被忽略的規(guī)則是，有時可能您緩存得太多。通常在一個 x86 計算機(jī)上，為了減少

內(nèi)存不足錯誤出現(xiàn)的機(jī)會，您會想使用不高于 800mb 的專用字節(jié)運(yùn)行進(jìn)程。因此緩存應(yīng)該有個限度。換句話說，您可能能夠重用某個計算結(jié)果

，但是如果該計算采用 10 個參數(shù)的話，您可能要嘗試緩存 10 個排列，這樣有可能給您帶來麻煩。一個要求 asp.net 的最常見支持是由于過

度緩存引起的內(nèi)存不足錯誤，尤其是對于大型數(shù)據(jù)集。

圖 3 asp.net緩存

緩存有幾個極佳的功能，您需要對它們有所了解。首先，緩存會實現(xiàn)最近最少使用的算法，使得 asp.net 能夠在內(nèi)存運(yùn)行效率較低的情況下強(qiáng)

制緩存清除 － 從緩存自動刪除未使用過的項目。第二，緩存支持可以強(qiáng)制失效的過期依賴項。這些依賴項包括時間、密鑰和文件。時間經(jīng)常

會用到，但是對于 asp.net 2.0，引入了一個功能更強(qiáng)的新失效類型：數(shù)據(jù)庫緩存失效。它指的是當(dāng)數(shù)據(jù)庫中的數(shù)據(jù)發(fā)生變化時自動刪除緩存

中的項。有關(guān)數(shù)據(jù)庫緩存失效的詳細(xì)信息，請參閱 msdn?magazine 2004 年 7 月的 dino esposito cutting edge 專欄。要了解緩存的體系結(jié)

構(gòu)，請參閱圖 3。

技巧 5 — 每請求緩存

在本文前面部分，我提到了經(jīng)常遍歷代碼路徑的一些小改善可能會導(dǎo)致較大的整體性能收益。對于這些小改善，其中有一個絕對是我的最愛，

我將其稱之為“每請求緩存”。

緩存 api 的設(shè)計目的是為了將數(shù)據(jù)緩存較長的一段時間，或者緩存至滿足某些條件時，但每請求緩存則意味著只將數(shù)據(jù)緩存為該請求的持續(xù)時

間。對于每個請求，要經(jīng)常訪問某個特定的代碼路徑，但是數(shù)據(jù)卻只需提取、應(yīng)用、修改或更新一次。這聽起來有些理論化，那么我們來舉一

個具體的示例。

在社區(qū)服務(wù)器的論壇應(yīng)用程序中，頁面上使用的每個服務(wù)器控件都需要個性化的數(shù)據(jù)來確定使用什么外觀、使用什么樣式表，以及其他個性化

數(shù)據(jù)。這些數(shù)據(jù)中有些可以長期緩存，但是有些數(shù)據(jù)卻只針對每個請求提取一次，然后在執(zhí)行該請求期間對其重用多次，如要用于控件的外觀

。

為了達(dá)到每請求緩存，請使用 asp.net httpcontext。對于每個請求，都會創(chuàng)建一個 httpcontext 實例，在該請求期間從

httpcontext.current 屬性的任何位置都可訪問該實例。該 httpcontext 類具有一個特殊的 items 集合屬性；添加到此 items 集合的對象和

數(shù)據(jù)只在該請求持續(xù)期間內(nèi)進(jìn)行緩存。正如您可以使用緩存來存儲經(jīng)常訪問的數(shù)據(jù)一樣，您也可以使用 httpcontext.items 來存儲只基于每個

請求使用的數(shù)據(jù)。它背后的邏輯非常簡單：數(shù)據(jù)在它不存在的時候添加到 httpcontext.items 集合，在后來的查找中，只是返回

httpcontext.items 中的數(shù)據(jù)。

技巧 6 — 后臺處理

通往代碼的路徑應(yīng)該盡可能快速，是嗎？可能有時您會覺得針對每個請求執(zhí)行的或者每 n 個請求執(zhí)行一次的任務(wù)所需資源非常多。發(fā)送電子郵

件或者分析和驗證傳入數(shù)據(jù)就是這樣的一些例子。

剖析 asp.net forums 1.0 并重新構(gòu)建組成社區(qū)服務(wù)器的內(nèi)容時，我們發(fā)現(xiàn)添加新張貼的代碼路徑非常慢。每次添加新張貼時，應(yīng)用程序首先

需要確保沒有重復(fù)的張貼，然后必須使用“壞詞”篩選器分析該張貼，分析張貼的字符圖釋，對張貼添加標(biāo)記并進(jìn)行索引，請求時將張貼添加

到合適的隊列，驗證附件，最終張貼之后，立即向所有訂閱者發(fā)出電子郵件通知。很清楚，這涉及很多操作。

經(jīng)研究發(fā)現(xiàn)，大多數(shù)時間都花在了索引邏輯和發(fā)送電子郵件上。對張貼進(jìn)行索引是一個非常耗時的操作，人們發(fā)現(xiàn)內(nèi)置的 system.web.mail 功

能要連接 smyp 服務(wù)器，然后連續(xù)發(fā)送電子郵件。當(dāng)某個特定張貼或主題領(lǐng)域的訂閱者數(shù)量增加時，執(zhí)行 addpost 功能所需的時間也越來越長

。

并不需要針對每個請求都進(jìn)行電子郵件索引。理想情況下，我們想要將此操作進(jìn)行批處理，一次索引 25 個張貼或者每五分鐘發(fā)送一次所有電

子郵件。我們決定使用以前用于對數(shù)據(jù)緩存失效進(jìn)行原型設(shè)計的代碼，這個失效是用于最終進(jìn)入 visual studio® 2005 的內(nèi)容的。

system.threading 命名空間中的 timer 類非常有用，但是在 .net framework 中不是很有名，至少對于 web 開發(fā)人員來說是這樣。創(chuàng)建之后

，這個 timer 類將以一個可配置的間隔針對 threadpool 中的某個線程調(diào)用指定的回調(diào)。這就表示，您可以對代碼進(jìn)行設(shè)置，使其能夠在沒有

對 asp.net 應(yīng)用程序進(jìn)行傳入請求的情況下得以執(zhí)行，這是后臺處理的理想情況。您還可以在此后臺進(jìn)程中執(zhí)行如索引或發(fā)送電子郵件之類的

操作。

但是，這一技術(shù)有幾個問題。如果應(yīng)用程序域卸載，該計時器實例將停止觸發(fā)其事件。另外，因為 clr 對于每個進(jìn)程的線程數(shù)量具有一個硬性

標(biāo)準(zhǔn)，所以可能會出現(xiàn)這樣的情形：服務(wù)器負(fù)載很重，其中計時器可能沒有可在其基礎(chǔ)上得以完成的線程，在某種程度上可能會造成延遲。asp

.net 通過在進(jìn)程中保留一定數(shù)量的可用線程，并且僅使用總線程的一部分用于請求處理，試圖將上述情況發(fā)生的機(jī)會降到最低。但是，如果您

具有很多異步操作時，這可能就是一個問題了。

這里沒有足夠的空間來放置該代碼，但是您可以下載一個可以看懂的示例，網(wǎng)址是 www.rob-howard.net。請了解一下 blackbelt teched 2004

演示中的幻燈片和演示。

技巧 7 — 頁輸出緩存和代理服務(wù)器

asp.net 是您的表示層（或者說應(yīng)該是您的表示層）；它由頁、用戶控件、服務(wù)器控件（httphandlers 和 httpmodules）以及它們生成的內(nèi)容

組成。如果您具有一個 asp.net 頁，它會生成輸出（html、xml、圖像或任何其他數(shù)據(jù)），并且您針對每個請求運(yùn)行此代碼時，它都會生成相

同的輸出，那么您就擁有一個可用于頁輸出緩存的絕佳備選內(nèi)容。

將此行內(nèi)容添加頁的最上端

<%@ page outputcache varybyparams="none" duration="60" %>

就可以高效地為此頁生成一次輸出，然后對它進(jìn)行多次重用，時間最長為 60 秒，此時該頁將重新執(zhí)行，輸出也將再一次添加到 asp.net 緩存

。通過使用一些低級程序化 api 也可以完成此行為。對于輸出緩存有幾個可配置的設(shè)置，如剛剛講到的 varybyparams 屬性。varybyparams

剛好被請求到，但還允許您指定 http get 或 http post 參數(shù)來更改緩存項。例如，只需設(shè)置 varybyparam="report" 即可對

default.aspx?report=1 或 default.aspx?report=2 進(jìn)行輸出緩存。通過指定一個以分號分隔的列表，還可以指定其他參數(shù)。

很多人都不知道何時使用輸出緩存，asp.net 頁還會生成一些位于緩存服務(wù)器下游的 http 標(biāo)頭，如 microsoft internet security and

acceleration server 或 akamai 使用的標(biāo)頭。設(shè)置了 http 緩存標(biāo)頭之后，可以在這些網(wǎng)絡(luò)資源上對文檔進(jìn)行緩存，客戶端請求也可在不必

返回原始服務(wù)器的情況下得以滿足。

因此，使用頁輸出緩存不會使得您的應(yīng)用程序效率更高，但是它可能會減少服務(wù)器上的負(fù)載，因為下游緩存技術(shù)會緩存文檔。當(dāng)然，這可能只

是匿名內(nèi)容；一旦它成為下游之后，您就再也不會看到這些請求，并且再也無法執(zhí)行身份驗證以阻止對它的訪問了。

技巧 8 — 運(yùn)行 iis 6.0（只要用于內(nèi)核緩存）

如果您未運(yùn)行 iis 6.0 (windows server? 2003)，那么您就錯過了 microsoft web 服務(wù)器中的一些很好的性能增強(qiáng)。在技巧 7 中，我討論了

輸出緩存。在 iis 5.0 中，請求是通過 iis 然后進(jìn)入 asp.net 的。涉及到緩存時，asp.net 中的 httpmodule 會接收該請求，并返回緩存中

的內(nèi)容。

如果您正在使用 iis 6.0，就會發(fā)現(xiàn)一個很好的小功能，稱為內(nèi)核緩存，它不需要對 asp.net 進(jìn)行任何代碼更改。當(dāng)請求由 asp.net 進(jìn)行輸

出緩存時，iis 內(nèi)核緩存會接收緩存數(shù)據(jù)的一個副本。當(dāng)請求來自網(wǎng)絡(luò)驅(qū)動程序時，內(nèi)核級別的驅(qū)動程序（無上下文切換到用戶模式）就會接

收該請求，如果經(jīng)過了緩存，則會將緩存的數(shù)據(jù)刷新到響應(yīng)，然后完成執(zhí)行。這就表示，當(dāng)您將內(nèi)核模式緩存與 iis 和 asp.net 輸出緩存一

起使用時，就會看到令人不敢相信的性能結(jié)果。在 asp.net 的 visual studio 2005 開發(fā)過程中，我一度是負(fù)責(zé) asp.net 性能的程序經(jīng)理。

開發(fā)人員完成具體工作，但是我要看到每天進(jìn)行的所有報告。內(nèi)核模式緩存結(jié)果總是最有意思的。最常見的特征是網(wǎng)絡(luò)充滿了請求/響應(yīng)，而

iis 運(yùn)行時的 cpu 使用率只有大約 5%。這太令人震驚了！當(dāng)然使用 iis 6.0 還有一些其他原因，但是內(nèi)核模式緩存是其中最明顯的一個。

技巧 9 — 使用 gzip 壓縮

雖然使用 gzip 并不一定是服務(wù)器性能技巧（因為您可能會看到 cpu 使用率的提高），但是使用 gzip 壓縮可以減少服務(wù)器發(fā)送的字節(jié)數(shù)量。

這就使人們覺得頁速度加快了，并且還減少了帶寬的用量。根據(jù)所發(fā)送數(shù)據(jù)、可以壓縮的程度以及客戶端瀏覽器是否支持（iis 只會向支持

gzip 壓縮的客戶端發(fā)送經(jīng)過 gzip 壓縮的內(nèi)容，如 internet explorer 6.0 和 firefox），您的服務(wù)器每秒可以服務(wù)于更多的請求。實際上

，幾乎每當(dāng)您減少所返回數(shù)據(jù)的數(shù)量時，都會增加每秒請求數(shù)。

gzip 壓縮已經(jīng)內(nèi)置到 iis 6.0 中，并且其性能比 iis 5.0 中使用的 gzip 壓縮要好的多，這是好消息。但不幸的是，當(dāng)嘗試在 iis 6.0 中

打開 gzip 壓縮時，您可能無法在 iis 的屬性對話中找到該設(shè)置。iis 小組在該服務(wù)器中置入了卓越的 gzip 功能，但是忘了包括一個用于啟

用該功能的管理 ui。要啟用 gzip 壓縮，您必須深入到 iis 6.0 的 xml 配置設(shè)置內(nèi)部（這樣不會引起心臟虛弱）。順便提一句，這歸功于

orcsweb 的 scott forsyth，他幫助我提出了在 orcsweb 上宿主的 www.asp.net 服務(wù)器的這個問題。

本文就不講述步驟了，請閱讀 brad wilson 的文章，網(wǎng)址是 iis6 compression。還有一篇有關(guān)為 aspx 啟用壓縮的知識庫文章，網(wǎng)址是

enable aspx compression in iis。但是您應(yīng)該注意，由于一些實施細(xì)節(jié)，iis 6.0 中不能同時存在動態(tài)壓縮和內(nèi)核緩存。

技巧 10 — 服務(wù)器控件視圖狀態(tài)

視圖狀態(tài)是一個有趣的名稱，用于表示在所生成頁的隱藏輸出字段中存儲一些狀態(tài)數(shù)據(jù)的 asp.net。當(dāng)該頁張貼回服務(wù)器時，服務(wù)器可以分析

、驗證、并將此視圖狀態(tài)數(shù)據(jù)應(yīng)用回該頁的控件樹。視圖狀態(tài)是一個非常強(qiáng)大的功能，因為它允許狀態(tài)與客戶端一起保持，并且它不需要

cookie 或服務(wù)器內(nèi)存即可保存此狀態(tài)。很多 asp.net 服務(wù)器控件都使用視圖狀態(tài)來保持在與頁元素進(jìn)行交互期間創(chuàng)建的設(shè)置，例如保存對數(shù)

據(jù)進(jìn)行分頁時顯示的當(dāng)前頁。

然而使用視圖狀態(tài)也有一些缺點。首先，服務(wù)或請求頁時，它都會增加頁的總負(fù)載。對張貼回服務(wù)器的視圖狀態(tài)數(shù)據(jù)進(jìn)行序列化或取消序列化

時，也會發(fā)生額外的開銷。最后，視圖狀態(tài)會增加服務(wù)器上的內(nèi)存分配。

幾個服務(wù)器控件有著過度使用視圖狀態(tài)的趨勢，即使在并不需要的情況下也要使用它，其中最著名的是 datagrid。viewstate 屬性的默認(rèn)行為

是啟用，但是如果您不需要，則可以在控件或頁級別關(guān)閉。在控件內(nèi)，只需將 enableviewstate 屬性設(shè)置為 false，或者在頁中使用下列設(shè)置

即可對其進(jìn)行全局設(shè)置：

<%@ page enableviewstate="false" %>

如果您不回發(fā)頁，或者總是針對每個請求重新生成頁上的控件，則應(yīng)該在頁級別禁用視圖狀態(tài)。