用 ASP.NET 编写 Web 应用程序其轻松程度令人难以置信。它是如此的容易，以至于许多开发人员不用花费多少时间来构筑其应用便能获得非常好的性能。在本文中，我将给出10个编写高性能 Web 应用的技巧。我的评论不仅仅局限与 ASP.NET 应用，因为它们只是 Web 应用的一个子集。本文也不是 Web 应用性能调整的权威指南――这方面的内容可以写成一本书。相反，本文可以被视作一个好的起点。
在废寝忘食地工作之前，我常常要去攀岩。在攀岩之前，我总是要看一下指南手册中的线路并阅读以前来此一游的人留下的建议和忠告。但是，不管指南手册有多磨好，在尝试一次特定的具有挑战性的攀爬之前，你都必须付诸实际的行动。同样，在你面临解决的性能问题或者营运一个高吞吐量的站点之前，你只能想方设法编写高性能 Web 应用程序。
我们个人经验来自在微软 ASP.NET 团队从事底层架构程序经理，运行和管理 www.asp.net ,并协助架构 Community Server 过程中的经历，Community Server 是几个有名的 ASP.NET 应用程序的下一个版本（它将 ASP.NET Forums，.Text 和 nGallery 整合到一个平台）。我确信这些帮助过我的技巧也会对你有所裨益。
你应该考虑将应用程序分离成几个逻辑层。你可能听说过术语3-层（或n-层）物理体系结构。它们通常是跨进程和/或硬件对功能进行物理划分的规定的体系结构模式。当系统需要伸缩时，更多的硬件能被添加。然而，总是应该避免与进程和机器忙碌程度相关的性能问题。所以，不管什么时候，只要可能，都要在相同的应用中一起运行 ASP.NET 页面及其相关的组件。
本文所描述的性能改进有两种类型：大型优化，如使用 ASP.NET Cache，以及不断重复进行的微型优化。这些微型优化有时很有意思。对代码的小小改动便会引起很大的动静，产生成千次的调用。对于大型优化，你可能会看到整体性能的大跳跃。而对微型优化，给定请求可能只是毫秒级的调整，但按每天的请求总数计算，其结果的改进可能是巨大的。
数据层的性能 当调整某个应用程序的性能时，有一个简单的试金石，你可以用它按先后次序：检查代码是否存取数据库？如果是，多长时间存取一次？注意相同的测试也可以被应用于使用 Web 服务或远程调用的代码，但我们本文中不涉及这方面内容。
在 Community Server 中，我们编写了几个分页控件来完成数据分页。你将会看到，我使用了技巧 1 中讨论的思路，从一个存储过程中返回连个结果集：总记录数和请求的数据。
返回的总记录数依赖于所执行的查询不同而不同。例如，某个 WHERE 子句可被用于约束返回的数据。为了计算在分页用户界面显示的总页数，返回的总记录数必须是已知的。例如，如果有 1,000,000 条记录，用一个 WHERE 子句对之过滤后为 1,000 条记录，则分页逻辑必须要知道总记录数以便在分页用户界面中正确呈现。
技巧 3 ―― 连接池 建立 Web 应用程序与 SQL Server 之间的 TCP 连接是一项昂贵的操作。微软的开发人员利用连接池技术已经有好长一段时间了，这个技术使他们能重用到数据库的连接。而不是每次请求都建立新的 TCP 连接，新连接仅在连接池中得不到连接时才建立。当连接被关闭时，它被返回到连接池中，在那里它仍然保持与数据库的连接，与完全断开 TCP 连接相反。
当然，你需要提防泄漏的连接。当你处理完毕，一定要关闭连接。重申一次：不管人们怎么吹嘘微软 .NET 框架中的垃圾收集特性，每当你处理完毕，一定要显式地调用连接对象的 Close 或 Dispose 方法。不要指望公共语言运行时（CLR）来为你定时清除和关闭连接。CLR 最终将销毁类并强行关闭连接，但你无法保证该对象的垃圾收集届时会起作用。
设为主页
收藏本站
相关文章: