微軟PDC2009直擊：改進ASP.NET 4運行時
對于ASP.NET 4大家還是有很多期待的，本文將為大家講述的是在微軟PDC2009大會上關(guān)于改進ASP.NET 4運行時部分的內(nèi)容，希望對大家有所幫助。
#T#
在近期舉辦的PDC 09大會中，ASP.NET團隊的程序經(jīng)理Stefan Schackow展示了ASP.NET 4在運行時方面的改進。改進主要圍繞“性能”和“可擴展性”兩個方面進行，具體表現(xiàn)三點：新的資源監(jiān)視選項、會話狀態(tài)以及輸出緩存的擴展能力。
對于一個Web服務器來說，CPU和內(nèi)存占用量是兩個較為重要的性能指標，而兩者相比之下，內(nèi)存相對又更容易成為瓶頸。自從IIS 6引入了“應用程序池”的概念開始，多個ASP.NET應用程序便可以工作在單個進程之中。但是在這種情況下，我們就很難通過性能監(jiān)視器來獲得某個特定的Web應用程序所占用的系統(tǒng)資源，這有時會讓問題的定位變得困難重重。由于CLR 4可以獲得某個單獨的應用程序域所占用的CPU，以及堆上托管內(nèi)存的數(shù)量，于是在ASP.NET 4中引入了一個名為“應用程序域資源管理(AppDomain Resource Management，ARM)”的功能，它會檢測并預估單個Web應用程序資源占用的趨勢，并將各種數(shù)據(jù)開放給性能計數(shù)器。
在ASP.NET 4中，ARM功能默認并不會開放。ARM功能無法通過修改單獨應用程序的web.config文件打開，你需要去系統(tǒng)的.NET配置目錄中修改Aspnet.config文件，在
在會話狀態(tài)(Session State)使用方面，ASP.NET 4也作出了有效的改進。Stefan表示，客戶中使用會話狀態(tài)的ASP.NET應用程序數(shù)量之多超過了他的想象，尤其是跨進程(Out of Process)的Session使用方式更是影響Web應用程序性能的主要因素之一。因此，ASP.NET 4利用.NET中的壓縮功能，對跨進程的會話狀態(tài)進行了壓縮，包括SQL Server和會話狀態(tài)服務器——而這一切只需要在web.config中進行配置即可。進行壓縮之后可以節(jié)省1/3到2/3的流量，不過會帶來一些Web服務器的CPU壓力。
目前，ASP.NET運行時會根據(jù)當前請求的Http Handler是否實現(xiàn)IRequireSessionState接口來判斷是否啟用Session。在ASP.NET 4中，開發(fā)人員可以通過編程接口來控制某個請求是否啟用會話狀態(tài)。此外，ASP.NET 4還提供了“部分會話狀態(tài)(Partial Session State)”的功能，即只加載會話狀態(tài)指定key的數(shù)據(jù)，這除了有效減少會話狀態(tài)的通信開銷外，也提供了額外的擴展能力。例如，ASP.NET團隊打算在AppFabric分布式緩存(其前身為Velocity)正式發(fā)布后，基于AppFabric構(gòu)建一個新的Session State Provider。
ASP.NET4在輸出緩存(Output Cache)上也增加了一些擴展點，主要可以讓開發(fā)人員為控件和請求級別的緩存定制存儲機制，例如磁盤，分布式緩存，甚至是云中，而在目前的ASP.NET中，所有數(shù)據(jù)都只能緩存在進程的內(nèi)存中。這個擴展機制支持緩存的絕對過期(Absolute Expiration)時間，文件依賴，和靜態(tài)替換和驗證回調(diào)功能，不過為了保證緩存實現(xiàn)的通用性，它不支持相對過期(Sliding Expiration)時間和其他形式的依賴。與會話狀態(tài)一樣，在AppFabric發(fā)布之后，ASP.NET團隊也會提供相應的Ouput Cache Provider，不過按照計劃這會在ASP.NET 4 RTM之后才會發(fā)布了。Stefan表示，這些額外的Provider擴展都會作為開源項目托管在CodePlex網(wǎng)站上。
***，基于IIS 7.5的“預熱”功能，ASP.NET 4可以讓IIS 7.5自動運行web.config中指定的頁面。Stefan表示，這個功能并不會給程序性能帶來提高，只是讓用戶避免遭遇程序冷啟動所帶來的延遲效果。
