編寫 Web 應(yīng)用程序其輕松程度令人難以置信。它是如此的容易，以至于許多開發(fā)人員不用花費(fèi)多少時(shí)間來構(gòu)筑其應(yīng)用便能獲得非常好的性能。在本文中，我將給出10個(gè)編寫高性能 Web 應(yīng)用的技巧。我的評(píng)論不僅僅局限與 ASP.NET 應(yīng)用，因?yàn)樗鼈冎皇?Web 應(yīng)用的一個(gè)子集。本文也不是 Web 應(yīng)用性能調(diào)整的權(quán)威指南——這方面的內(nèi)容可以寫成一本書。相反，本文可以被視作一個(gè)好的起點(diǎn)。
在廢寢忘食地工作之前，我常常要去攀巖。在攀巖之前，我總是要看一下指南手冊(cè)中的線路并閱讀以前來此一游的人留下的建議和忠告。但是，不管指南手冊(cè)有多磨好，在嘗試一次特定的具有挑戰(zhàn)性的攀爬之前，你都必須付諸實(shí)際的行動(dòng)。同樣，在你面臨解決的性能問題或者營運(yùn)一個(gè)高吞吐量的站點(diǎn)之前，你只能想方設(shè)法編寫高性能 Web 應(yīng)用程序。
我們個(gè)人經(jīng)驗(yàn)來自在微軟 ASP.NET 團(tuán)隊(duì)從事底層架構(gòu)程序經(jīng)理，運(yùn)行和管理 www.asp.net ,并協(xié)助架構(gòu) Community Server 過程中的經(jīng)歷，Community Server 是幾個(gè)有名的 ASP.NET 應(yīng)用程序的下一個(gè)版本（它將 ASP.NET Forums，.Text 和 nGallery 整合到一個(gè)平臺(tái)）。我確信這些幫助過我的技巧也會(huì)對(duì)你有所裨益。
你應(yīng)該考慮將應(yīng)用程序分離成幾個(gè)邏輯層。你可能聽說過術(shù)語3-層（或n-層）物理體系結(jié)構(gòu)。它們通常是跨進(jìn)程和/或硬件對(duì)功能進(jìn)行物理劃分的規(guī)定的體系結(jié)構(gòu)模式。當(dāng)系統(tǒng)需要伸縮時(shí)，更多的硬件能被添加。然而，總是應(yīng)該避免與進(jìn)程和機(jī)器忙碌程度相關(guān)的性能問題。所以，不管什么時(shí)候，只要可能，都要在相同的應(yīng)用中一起運(yùn)行 ASP.NET 頁面及其相關(guān)的組件。
由于代碼和層之間的邊界分離，使用 Web 服務(wù)或遠(yuǎn)程調(diào)用將降低20%以上的性能。
數(shù)據(jù)層則稍微有些不同，因?yàn)閿?shù)據(jù)庫通常都用專門的硬件。但是，數(shù)據(jù)庫的處理成本仍然很高，因此最優(yōu)化代碼時(shí)，數(shù)據(jù)層的性能應(yīng)該是首當(dāng)其充要關(guān)注的地方。
在著手解決你的應(yīng)用程序的性能問題之前，一定要剖析應(yīng)用程序，確定問題之所在。獲取關(guān)鍵的性能計(jì)數(shù)器值（如實(shí)現(xiàn)垃圾收集所花時(shí)間之百分比的性能計(jì)數(shù)器的值）對(duì)于查找應(yīng)用程序在何處最耗時(shí)也是非常重要的。憑借直覺常常也能找到耗時(shí)所在。
本文所描述的性能改進(jìn)有兩種類型：大型優(yōu)化，如使用 ASP.NET Cache，以及不斷重復(fù)進(jìn)行的微型優(yōu)化。這些微型優(yōu)化有時(shí)很有意思。對(duì)代碼的小小改動(dòng)便會(huì)引起很大的動(dòng)靜，產(chǎn)生成千次的調(diào)用。對(duì)于大型優(yōu)化，你可能會(huì)看到整體性能的大跳躍。而對(duì)微型優(yōu)化，給定請(qǐng)求可能只是毫秒級(jí)的調(diào)整，但按每天的請(qǐng)求總數(shù)計(jì)算，其結(jié)果的改進(jìn)可能是巨大的。
Rob Howard

Writing a Web application with ASP.NET is unbelievably easy. So easy, many developers don't take the time to structure their applications for great performance. In this article, I'm going to present 10 tips for writing high-performance Web apps. I'm not limiting my comments to ASP.NET applications because they are just one subset of Web applications. This article won't be the definitive guide for performance-tuning Web applications—an entire book could easily be devoted to that. Instead, think of this as a good place to start.
Before becoming a workaholic, I used to do a lot of rock climbing. Prior to any big climb, I'd review the route in the guidebook and read the recommendations made by people who had visited the site before. But, no matter how good the guidebook, you need actual rock climbing experience before attempting a particularly challenging climb. Similarly, you can only learn how to write high-performance Web applications when you're faced with either fixing performance problems or running a high-throughput site.
My personal experience comes from having been an infrastructure Program Manager on the ASP.NET team at Microsoft, running and managing www.asp.net, and helping architect Community Server, which is the next version of several well-known ASP.NET applications (ASP.NET Forums, .Text, and nGallery combined into one platform). I'm sure that some of the tips that have helped me will help you as well.
You should think about the separation of your application into logical tiers. You might have heard of the term 3-tier (or n-tier) physical architecture. These are usually prescribed architecture patterns that physically divide functionality across processes and/or hardware. As the system needs to scale, more hardware can easily be added. There is, however, a performance hit associated with process and machine hopping, thus it should be avoided. So, whenever possible, run the ASP.NET pages and their associated components together in the same application.
Because of the separation of code and the boundaries between tiers, using Web services or remoting will decrease performance by 20 percent or more.
The data tier is a bit of a different beast since it is usually better to have dedicated hardware for your database. However, the cost of process hopping to the database is still high, thus performance on the data tier is the first place to look when optimizing your code.
Before diving in to fix performance problems in your applications, make sure you profile your applications to see exactly where the problems lie. Key performance counters (such as the one that indicates the percentage of time spent performing garbage collections) are also very useful for finding out where applications are spending the majority of their time. Yet the places where time is spent are often quite unintuitive.
There are two types of performance improvements described in this ..