编写优秀的高性能web应用程序---------外文及其翻译.doc
约14页DOC格式手机打开展开
编写优秀的高性能web应用程序---------外文及其翻译,编写 web 应用程序其轻松程度令人难以置信。它是如此的容易，以至于许多开发人员不用花费多少时间来构筑其应用便能获得非常好的性能。在本文中，我将给出10个编写高性能 web 应用的技巧。我的评论不仅仅局限与 asp.net 应用，因为它们只是 web 应用的一个子集。本文也不是 web 应用性能调整的权威指南——这方面...
内容介绍
此文档由会员 wanli1988go 发布
编写 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 页面及其相关的组件。
由于代码和层之间的边界分离，使用 Web 服务或远程调用将降低20%以上的性能。
数据层则稍微有些不同，因为数据库通常都用专门的硬件。但是，数据库的处理成本仍然很高，因此最优化代码时，数据层的性能应该是首当其充要关注的地方。
在着手解决你的应用程序的性能问题之前，一定要剖析应用程序，确定问题之所在。获取关键的性能计数器值（如实现垃圾收集所花时间之百分比的性能计数器的值）对于查找应用程序在何处最耗时也是非常重要的。凭借直觉常常也能找到耗时所在。
本文所描述的性能改进有两种类型：大型优化，如使用 ASP.NET Cache，以及不断重复进行的微型优化。这些微型优化有时很有意思。对代码的小小改动便会引起很大的动静，产生成千次的调用。对于大型优化，你可能会看到整体性能的大跳跃。而对微型优化，给定请求可能只是毫秒级的调整，但按每天的请求总数计算，其结果的改进可能是巨大的。
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 ..
在废寝忘食地工作之前，我常常要去攀岩。在攀岩之前，我总是要看一下指南手册中的线路并阅读以前来此一游的人留下的建议和忠告。但是，不管指南手册有多磨好，在尝试一次特定的具有挑战性的攀爬之前，你都必须付诸实际的行动。同样，在你面临解决的性能问题或者营运一个高吞吐量的站点之前，你只能想方设法编写高性能 Web 应用程序。
我们个人经验来自在微软 ASP.NET 团队从事底层架构程序经理，运行和管理 www.asp.net ,并协助架构 Community Server 过程中的经历，Community Server 是几个有名的 ASP.NET 应用程序的下一个版本（它将 ASP.NET Forums，.Text 和 nGallery 整合到一个平台）。我确信这些帮助过我的技巧也会对你有所裨益。
你应该考虑将应用程序分离成几个逻辑层。你可能听说过术语3-层（或n-层）物理体系结构。它们通常是跨进程和/或硬件对功能进行物理划分的规定的体系结构模式。当系统需要伸缩时，更多的硬件能被添加。然而，总是应该避免与进程和机器忙碌程度相关的性能问题。所以，不管什么时候，只要可能，都要在相同的应用中一起运行 ASP.NET 页面及其相关的组件。
由于代码和层之间的边界分离，使用 Web 服务或远程调用将降低20%以上的性能。
数据层则稍微有些不同，因为数据库通常都用专门的硬件。但是，数据库的处理成本仍然很高，因此最优化代码时，数据层的性能应该是首当其充要关注的地方。
在着手解决你的应用程序的性能问题之前，一定要剖析应用程序，确定问题之所在。获取关键的性能计数器值（如实现垃圾收集所花时间之百分比的性能计数器的值）对于查找应用程序在何处最耗时也是非常重要的。凭借直觉常常也能找到耗时所在。
本文所描述的性能改进有两种类型：大型优化，如使用 ASP.NET Cache，以及不断重复进行的微型优化。这些微型优化有时很有意思。对代码的小小改动便会引起很大的动静，产生成千次的调用。对于大型优化，你可能会看到整体性能的大跳跃。而对微型优化，给定请求可能只是毫秒级的调整，但按每天的请求总数计算，其结果的改进可能是巨大的。
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 ..
