為什么要寫篇文章
談到ASP.NET應(yīng)用的開發(fā)，使我不禁想起之前有朋友對(duì)我說過的一句話：做網(wǎng)站沒有任何的技術(shù)含量。后來他告訴我，做網(wǎng)站，在.NET平臺(tái)上面很簡(jiǎn)單，不就是拖幾個(gè)控件，搞點(diǎn)布局，寫點(diǎn)js，然后敲上幾個(gè)數(shù)據(jù)的增刪查改就完了，系統(tǒng)大了，就多敲幾個(gè)。當(dāng)時(shí)，朋友之所以說這樣的話，是與他的公司與項(xiàng)目背景相關(guān)的。
在很多的外包公司里面，常常用ASP.NET來快速的搭建一個(gè)Web應(yīng)用，例如OA系統(tǒng)，企業(yè)門戶，管理系統(tǒng)，而這些系統(tǒng)往往都注重在業(yè)務(wù)流程上面，不會(huì)在其他方面關(guān)注過多，例如，性能，使用這些系統(tǒng)的用戶也不多，頂多幾千個(gè)，所以對(duì)于很多真正觸及到Web應(yīng)用的要考慮的問題，例如，高并發(fā)，高性能，穩(wěn)定，安全等，沒有接觸到。后來，我去了其他的公司，接觸到那種承受百萬，千萬級(jí)訪問量的應(yīng)用的時(shí)候，越發(fā)覺得自己有很多的知識(shí)需要學(xué)習(xí)。
在與朋友共事的一些項(xiàng)目中，很多項(xiàng)目的性能都很差，我們大家都想解決這個(gè)問題，但是都沒有辦法，僅僅只是知道一些基本的措施，很多都是從網(wǎng)絡(luò)上面“道聽途說”，例如用stringbuilder來拼接字符串，盡量用for而不是foreach。其實(shí)說到底，還是我們對(duì).NET不夠深入，雖然說，我們?cè)?/span>.NET平臺(tái)上面做了很多的項(xiàng)目，其實(shí)很多的應(yīng)用只是在.NET平臺(tái)的表層開發(fā)。（由此可見，“題海戰(zhàn)術(shù)”不一定能夠練就解題高手，也不一定能夠練就解決問題的思維。）
其實(shí)性能優(yōu)化問題，不僅僅只是Web應(yīng)用獨(dú)有的，而是說，在Web應(yīng)用中，可能關(guān)注的多一點(diǎn)。本篇文章談的是ASP.NET應(yīng)用的性能優(yōu)化，其實(shí)，從本質(zhì)上面，還是談的.NET應(yīng)用的優(yōu)化。對(duì)于其他平臺(tái)的朋友，也是非常有參考價(jià)值的。
在本篇文章中，不會(huì)談及很多的調(diào)優(yōu)的方法理論（其實(shí)這些方法論是很有作用的），我會(huì)從談及一些實(shí)際，可操作性的知識(shí)，讓朋友們學(xué)而即用，同時(shí)也讓朋友對(duì)開始對(duì).NET加深認(rèn)識(shí)。
本篇的內(nèi)容從以下幾個(gè)方面進(jìn)行展開：內(nèi)存瓶頸分析，CPU瓶頸分析，緩存分析，資源等待分析，數(shù)據(jù)庫(kù)瓶頸分析，HTTP優(yōu)化。
首先來看看內(nèi)存瓶頸分析。雖然，我在之前的一篇稿子《.NET企業(yè)級(jí)開發(fā)》中談 這個(gè)問題，但是，為了本篇文章的完整性，我還是提一下，同時(shí)也將這個(gè)問題講更全面一些。
內(nèi)存瓶頸分析
內(nèi)存性能問題可以分為兩個(gè)部分：內(nèi)部?jī)?nèi)存壓力，外部?jī)?nèi)存壓力。其中內(nèi)部?jī)?nèi)存壓力主要是站點(diǎn)本身在運(yùn)行的過程中消耗過多的內(nèi)存，基本是可以從托管資源，非托管資源兩方面分析；而外部?jī)?nèi)存壓力指代站點(diǎn)所在的服務(wù)器上面的其他應(yīng)用于站點(diǎn)本身之間進(jìn)行資源的爭(zhēng)奪，從而使得站點(diǎn)可以使用的內(nèi)存太少。那么在ASP.NET企業(yè)級(jí)應(yīng)用中，我們技術(shù)人員關(guān)注點(diǎn)可以放在內(nèi)部?jī)?nèi)存壓力。
首先看看托管資源的問題。
為什么要討論托管資源？因?yàn)橥泄苜Y源（就是分配中在托管堆上面的對(duì)象），分配在托管堆上，而托管堆在內(nèi)存中，所有托管資源的合理的分配和回收，會(huì)對(duì)內(nèi)存產(chǎn)生影響。
ASP.NET應(yīng)用的功能就是由很多的對(duì)象組合完成的，所以討論托管資源很有必要。
在.NET中，托管堆分為兩類：大對(duì)象托管堆，小對(duì)象托管堆。一般而言，如果對(duì)象所占的空間小于85K，就分配在小堆上面，反之，分配在大堆上面。如圖的小堆圖：
在對(duì)上面，對(duì)象被劃分為三代：0,1,2代?！按睌?shù)越大，被回收的可能性就越小。基于這個(gè)理論，就要避免原本只要是低代的對(duì)象變?yōu)楦叽膶?duì)象，例如某個(gè)對(duì)象用完之后就銷毀的，原本是0代的，現(xiàn)在存活到了2代，那么它所占的內(nèi)存就浪費(fèi)了。雖然，垃圾回收機(jī)制沒有在一定程度上回收，但是如果我們總是“霸占”著對(duì)象，垃圾回收也沒有辦法。
下面，舉個(gè)例子，形象的說明一下。對(duì)于一個(gè)大型的ASP.NET應(yīng)用而言，里面會(huì)包含很多的對(duì)象，假設(shè)10000個(gè)，其中每次請(qǐng)求都要產(chǎn)生的100個(gè)臨時(shí)對(duì)象。如果這些臨時(shí)對(duì)象，被不合理的分配，成為了大代的對(duì)象，我們來算一算。
如果這個(gè)100個(gè)對(duì)象每個(gè)占1k的空間，那么100個(gè)，我們約等于0.1M，如果站點(diǎn)訪問量是10w，那么如果這些0.1乘以10w，如果訪問量是100w，1000w，結(jié)果如何？大家已經(jīng)清楚了。很多，需要將問題放大來看，結(jié)果就很清晰了。
對(duì)于對(duì)象的使用，有一點(diǎn)要記?。罕M可能遲的分配，盡可能早的釋放。
下面，我們可以談?wù)?，如何找出?nèi)存問題。
可以采用工具加分析的方式?？梢圆捎?/span>System Counter，CLR Profiler，ANTS Memory Profiler(Red Gate)等。其中System Counter，CLR Profiler分析的比較的粗糙，ANTS Memory Profiler(Red Gate)可以指出是哪段代碼有問題，方便解決問題。如圖
本篇由于篇幅的限制，先到這里，下一篇，我們可以看看一些常見的性能問題，例如字符串相關(guān)問題，Session，緩存，對(duì)象池。
