做网站设计方案怎么写,宣传册排版设计与制作,邢台做网站推广报价,爱站网在线全集私人影视http://www.microsoft.com/china/msdn/library/webservices/asp.net/us0501ASPNETPerformance.mspx本文讨论#xff1a;常见的 ASP.NET 性能神话 有用的 ASP.NET 性能技巧和诀窍 在 ASP.NET 中处理数据库的一些建议 缓冲以及用 ASP.NET 进行后台处理 本文使用下列技术#xf…http://www.microsoft.com/china/msdn/library/webservices/asp.net/us0501ASPNETPerformance.mspx本文讨论常见的 ASP.NET 性能神话 有用的 ASP.NET 性能技巧和诀窍 在 ASP.NET 中处理数据库的一些建议 缓冲以及用 ASP.NET 进行后台处理 本文使用下列技术ASP.NET.NET 框架IIS 用 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 页面及其相关的组件。 由于代码和层之间的边界分离使用 Web 服务或远程调用将降低20%以上的性能。 数据层则稍微有些不同因为数据库通常都用专门的硬件。但是数据库的处理成本仍然很高因此最优化代码时数据层的性能应该是首当其充要关注的地方。 在着手解决你的应用程序的性能问题之前一定要剖析应用程序确定问题之所在。获取关键的性能计数器值如实现垃圾收集所花时间之百分比的性能计数器的值对于查找应用程序在何处最耗时也是非常重要的。凭借直觉常常也能找到耗时所在。 本文所描述的性能改进有两种类型大型优化如使用 ASP.NET Cache以及不断重复进行的微型优化。这些微型优化有时很有意思。对代码的小小改动便会引起很大的动静产生成千次的调用。对于大型优化你可能会看到整体性能的大跳跃。而对微型优化给定请求可能只是毫秒级的调整但按每天的请求总数计算其结果的改进可能是巨大的。数据层的性能 当调整某个应用程序的性能时有一个简单的试金石你可以用它按先后次序检查代码是否存取数据库如果是多长时间存取一次注意相同的测试也可以被应用于使用 Web 服务或远程调用的代码但我们本文中不涉及这方面内容。 如果在特定的代码流程中必须具有对数据库的请求以及要考察其它方面如想对字符串处理进行优先优化那么暂且把它放一放先按照上面定好的优先次序来做。除非你有异乎寻常的性能问题否则你的时间应该用在尝试最优化与数据库的连接所花的时间返回的数据量以及多长时间往返一次和数据库的通讯上。 有了这些概括信息下面就让我们来看看能帮助你改善应用程序性能的十个技巧。我将从能获得最显著效果的改变开始。技巧 1 —— 返回多个结果集 复审你的数据库代码看看是否有多于一次的对数据库的访问请求。这样每次往返数据库都降低你的应用程序能处理的每秒请求数。通过在单个数据库请求中返回多结果集你能降低与数据库通信的总体时间。同时你也将使系统更具伸缩性因为你减少了数据库服务器处理请求的负担。 虽然你可以用动态 SQL 返回多结果集我更喜欢使用存储过过程。是否将业务逻辑驻留在存储过程当中是个有待争论的问题但我认为如果存储过程中的逻辑能约束返回的数据降低数据集的尺寸在网络上传输的时间以及逻辑层不必过虑数据这是一件好事情。 使用 SqlCommand 命令实例及其 ExecuteReader 方法来处理强类型的各个业务类你通过调用 NextResult 可以向前移动结果集指针。Figure 1 示范了处理几个带类型的 ArrayLists 例子会话。从数据库只返回你需要的数据还会降低服务器上内存的分配。技巧 2 —— 分页数据存取 ASP.NET DataGrid 提供了非常好的能力数据分页支持。当启用 DataGrid 中的分页功能则每次只显示固定数量的记录。此外分页用户界面也会显示在 DataGrid 底部用于导航记录。分页用户界面允许你向前向后导航所显示的记录一次显示固定数量的记录。 有一个美中不足的是用 DataGrid 分页需要将所有数据邦定到此栅格控件gird。例如你的数据层必须返回所有数据然后 DataGrid 将根据当前页过滤掉所有显示的记录。当你通过 DataGrid 进行分页时如果有 100,000 条记录被返回那么每个请求有 99,975 条记录将被废弃掉假设页尺寸为 25。当记录数不断增加此应用程序的性能便会遭受痛苦因为每次请求所要发送的数据会越来越多。 编写较好的分页代码的一个好的方法是用存储过程。Figure 2 示范了一个用 Northwind 数据库中 Orders 表通过存储过程分页的例子。很简单只要你在页面中传递索引以及页尺寸即可。相应的结果集先被计算然后被返回。 在 Community Server 中我们编写了几个分页控件来完成数据分页。你将会看到我使用了技巧 1 中讨论的思路从一个存储过程中返回连个结果集总记录数和请求的数据。 返回的总记录数依赖于所执行的查询不同而不同。例如某个 WHERE 子句可被用于约束返回的数据。为了计算在分页用户界面显示的总页数返回的总记录数必须是已知的。例如如果有 1,000,000 条记录用一个 WHERE 子句对之过滤后为 1,000 条记录则分页逻辑必须要知道总记录数以便在分页用户界面中正确呈现。技巧 3 —— 连接池 建立 Web 应用程序与 SQL Server 之间的 TCP 连接是一项昂贵的操作。微软的开发人员利用连接池技术已经有好长一段时间了这个技术使他们能重用到数据库的连接。而不是每次请求都建立新的 TCP 连接新连接仅在连接池中得不到连接时才建立。当连接被关闭时它被返回到连接池中在那里它仍然保持与数据库的连接与完全断开 TCP 连接相反。 当然你需要提防泄漏的连接。当你处理完毕一定要关闭连接。重申一次不管人们怎么吹嘘微软 .NET 框架中的垃圾收集特性每当你处理完毕一定要显式地调用连接对象的 Close 或 Dispose 方法。不要指望公共语言运行时CLR来为你定时清除和关闭连接。CLR 最终将销毁类并强行关闭连接但你无法保证该对象的垃圾收集届时会起作用。 为了充分用好连接池有几条规则必须了然于心。首先打开连接进行处理然后关闭连接。宁愿每个请求的连接打开和关闭多次也不要保持连接打开状态以及在不同的方法间将它传来传去。其次使用相同的连接串如果你使用集成身份检查那么也要用相同的线程身份。如果你不用相同的连接串例如根据登录用户来定制连接串你将无法得到连接池所提供的相同的最优化值。当模拟大用户量情形时如果你使用集成身份检查那么你的连接池将效力大减。.NET CLR 数据性能计数器在试图跟踪任何与连接池有关的性能问题时是非常有用的。 不管什么时候只要你的应用程序连接到运行在其它进程中的资源比如某个数据库你都应该针对连接到资源所耗时间发送和接收数据所耗时间以及往返次数进行优化。为了实现较好的性能应该首当其充优化应用程序中任何种类的忙碌进程。 应用层包含到数据层的连接以及将数据转换成有意义的类实例和业务处理的逻辑。以 Community Server 为例你要在其中处理 Forums 和 Threads 集合以及应用许可这样的业务规则尤其重要的是缓冲Caching逻辑也实现其中。技巧 4 —— ASP.NET Cache API 在编写代码之前要做的头等大事之一是最大限度地构建应用层并发掘 ASP.NET 的 Cache 特性。 如果你的组件在 ASP.NET 应用程序内运行那么你只需要在应用程序工程中引用 System.Web.dll 即可。当你需要访问 Cache 时用 HttpRuntime.Cache 属性相同的对象也可以通过 Page.Cache 和 HttpContext.Cache 访问。 缓冲数据有几个准则。首先如果数据能被使用多次缓冲是个好的后选方案。其次如果数据对给定请求或用户是一般的数据而非专用数据那么最好是选择缓冲。如果数据用户或请求专用如果需要保存期很长但可能不被经常使用那么仍然要用缓冲。第三常常被忽略的一个准则是有时缓冲太多的东西。一般来说在x86机器上为了降低内存不足错误的几率运行某个进程不要超过800MB私有字节。因此缓冲应该有个上限。换句话说你也许能重用某个计算的结果但如果该计算有10个参数你可能试图针对10个置换进行缓冲这样做可能会给你带来麻烦。ASP.NET 提供的最常见的容错是由覆盖缓冲导致的内存不足错误尤其是大型数据集。 Cache 有几个重要特性是必须要了解的。第一个是 Cache 实现了最近最少使用least-recently-used算法允许 ASP.NET 强制 Cache 清除操作 —— 如果可用内存下降到低水平 —— 则自动从 Cache 中删除不使用的项目。第二个是 Cache 支持依赖性到期特性它能强制包括时间键值文件失效。时间常常被使用但 ASP.NET 2.0 引入了具有更强大的失效类型数据库缓冲失效。也就是当数据库中的数据改变时缓冲中的条目会自动删除。有关数据库缓冲失效的更多信息参见 Dino Esposito 在 MSDN 杂志 2004 年七月刊的 Cutting Edge 专栏文章。该缓冲的体系结构参见 Figure 3。Figure 3 ASP.NET Cache技巧 5 —— 预请求缓冲Per-Request Caching 在本文前面我曾提到对频繁执行的代码块所做的小小改动可能产生很大的整体性能的提升。我把其中一个我特别中意的叫做预请求缓冲per-request caching。 由于 Cache API 被设计用来缓冲长期数据或直到某个条件被满足预请求缓冲意旨用于请求期间的缓冲该数据。特定的代码流程被每次请求频繁访问但是数据只需要被拾取应用修改或更新一次这样说太理论化还是让我们看一个具体的例子吧。在 Community Server 的 Forums 论坛应用中某个页面上使用的每个服务器控件需要个性化数据以确定使用那个皮肤和式样页以及其它的个性化数据其中有些数据可以被长时间缓冲但有些数据比如用于控件的皮肤在单个请求中只被拾取一次并在该请求执行期间被重用多次。 为了完成预请求缓冲用 ASP.NET HttpContext。HttpContext 的实例是随每个请求创建的并可以通过 HttpContext.Current 属性在那个请求执行期间的任何地方存取它。HttpContext 类具有一个特别的 Items 集合属性被添加到该 Items 集合的对象和数据只是在该请求期间被缓存。就像你可以使用 Cache 来保存频繁使用的数据一样你可以用 HttpContext.Items 来保存只在某个预请求中使用的数据。在此背景后的逻辑很简单当数据不存在时被添加到 HttpContext.Items 集合以及在随后的并发查找中简单地返回 HttpContext.Items 中发现的数据。技巧 6——后台处理 你的代码流程应该尽可能快对吧你自己可能多次发现要完成每个请求或每n个请求的任务代价很高。发出 e-mail 或解析并检查输入数据的有效性就是个例。 在重新生成 ASP.NET Forums 1.0 并把它整合到 Community Server 时我们发现添加新贴的代码流程非常慢。每次添加帖子应用程序首先要确保没有重复贴然后必须用“badword”过滤器解析该贴的表情图像记号并索引如果必要还要将帖子添加到相应的队列中对附件进行有效性检查最终完成发贴后给预订者发出 e-mail 通知。显然这里做的工作太多。 我们发现大多数时间都花在了索引逻辑和发送e-mail上。索引帖子是一个很耗时的操作此外内建的 System.Web.Mail 功能要与 SMTP 服务器连接并顺序发送邮件。当特定帖子或主题预定者数量增加时AddPost 函数的执行时间会越来越长。 并不是每个请求都需要索引邮件我们想最好是批量集中处理并且一次只索引25个帖子或每隔五分钟发送一次邮件。我们决定使用的代码与我曾在原型数据库缓冲失效中所使用的代码相同最终它也被纳入 Visual Studio 2005。 名字空间 System.Threading 中的 Timer 类非常有用但在.NET 框架中鲜为人知至少对 Web 开发者来说是这样。一旦创建Timer 将以可定制的间隔针对线程池中的某个线程调用指定的回调函数。这意味着你不用输入请求到 ASP.NET 应用程序便能让代码实行这是一种最合适后台处理的情形。你也可以在这种后台处理模式中进行例如索引或发送电子邮件这样的工作。 尽管如此这个技术存在几个问题如果你的应用程序域关闭该定时器实例将停止触发其事件。另外由于 CLR 有一个硬坎即每个进程的线程数是固定的你便可能陷入严重的服务器负荷当中此时可能就没有线程来处理定时器从而造成延时。为了让发生这种情况的几率最小化ASP.NET 通过在进程中预留一定数量的空闲线程并只使用部分线程来处理请求。然而如果你有许多异步处理这样做会有问题。 由于篇幅所限在此无法列出代码但你可以从 www.rob-howard.net 下载可消化的例子。其中有 Blackbelt TechEd 2004 展示的幻灯和 Demo。技巧 7——页面输出缓存和代理服务器 ASP.NET 是你的表示层或者说应该是它由页面用户控件服务器控件HttpHandlers and HttpModules以及它们生成的内容组成。如果你有一个产生输出的 ASP.NET 页面不管是输出 HTMLXML图像还是任何其它数据而且每个请求你都运行这个代码并产生相同的输出此时最好选择使用页面输出缓存。只要在页面顶部添加这一行代码即可% Page OutputCache VaryByParamsnone Duration60 % 你可以为此页面有效地产生一次输出并可以在60秒内多次重用它一到这个时间点该页面将重新执行并将再次将输出添加到 ASP.NET Cache。这个行为还能用某些低级编程 APIs 来完成。输出缓存有几个可以配置的设置比如VaryByParams 属性。VaryByParams 不是必须的但允许你指定 HTTP GET 或 HTTP POST 参数来改变缓存入口。例如default.aspx?Report1 或 default.aspx?Report2 可以简单地设置 VaryByParamReport 来对输出进行缓存。额外的参数被命名并用用分号分隔。 在使用输出缓存机制时许多人都不了解 ASP.NET 页还产生一组下游缓存服务器 HTTP 头比如 Microsoft Internet Security and Acceleration Server 或 Akamai 使用的 HTTP 头。当设置 HTTP 缓存头文档可以被缓存到这些网络资源从而响应客户端请求不必返回原服务器。 然而使用页面输出缓存并不会使你的应用程序更有效率但它能通过下游缓存技术缓存文档从而潜在地降低服务器的负载。当然这只能是异步内容一旦实施下游缓存你将无法看到任何请求也不能实现身份认证来防止对它的存取。技巧 8——运行 IIS 6.0 (如果仅用于内核缓存) 如果你不运行 IIS 6.OWindows Server 2003那么你将得不到微软 Web 服务器中一些重大的性能改进。在技巧 7 中我谈到了输出缓存。在 IIS 5.0 中请求到达 IIS然后到达 ASP.NET。当使用缓存时ASP.NET 中的 HttpModule 接受该请求并从该缓存中返回内容。 如果你用 IIS 6.0有一些巧妙的特性叫内核缓存它不需要将任何代码改成 ASP.NET。当 ASP.NET对请求进行缓存处理IIS 内核缓存便接收一份缓存数据的拷贝。当请求来自网络驱动器内核一级的驱动程序没有到用户模式的上下文转换接收该请求如果缓存则直接用缓存数据响应并完成执行。这意味着当你使用 IIS 内核模式缓存和 ASP.NET 缓存时你将看到无法置信的性能结果。在开发 Visual Studio 2005 的 ASP.NET 期间我是负责 ASP.NET 性能的程序经理。开发人员的工作做的真是棒极了而我基本上每天都在看报告。内核模式缓存结果总是最有趣的。典型的情况是请求/响应往往使网络饱和但 IIS 的运行仅占 CPU 的百分之五。真令人惊异当然使用 IIS 6.O 有其它一些原因但内核模式缓存是显而易见的理由。技巧 9——使用 Gzip 压缩 虽然使用 gzip 压缩不是一个必须的服务器性能技巧因为你可能看到 CUP 的使用率上升了但它能降低服务器发送字节的数量。从而感觉页面更快而且减少带宽的占用。其压缩的效果好坏取决于所发送的数据以及客户端浏览器是否支持这种压缩IIS 只会将数据发送到支持 gzip 的浏览器比如IE 6.0 和 Firefox从而使服务器可以在每秒钟里处理更多的请求。事实上只要你降低返回数据的数量便能提高每秒所处理的请求数。 有一个好消息是 gzip 压缩是 IIS 6.0 的内建特性并且比它在 IIS 5.0 中使用的效果更好。但是要想在 IIS 6.0 中启用 gzip 压缩可能没那么方便IIS 的属性对话框里找不到设置它的地方。IIS 团队将卓越的 gzip 压缩能力内建在服务器中但忽视了建立一个启用压缩特性的管理用户界面。要想启用 gzip 压缩机制你必须深入到 IIS 的 XML 配置设置内部必须对之相当熟悉才能配置。顺便提一下在此感谢 OrcsWeb 的 Scott Forsyth 帮我解决了在 OrcsWeb 数个 www.asp.net 服务器上的这个问题。 与其在本文中包含整个过程还不如阅读 Brad Wilson 在 IIS6 Compression 上的文章。微软知识库也有一篇关于为ASPX启用压缩特性的文章Enable ASPX Compression in IIS。但是还必须注意一点动态压缩与内核缓存由于某些实现细节的原因其在 IIS 6.0 中是相互排斥的。技巧 10——服务器控件的可视状态 可视状态View State对于 ASP.NET 来说是个奇特的名字它在所产生的页面中隐藏输入域以存储某些状态数据。当页面被发回服务器该服务器能解析检查其有效性并将这个状态数据应用到页面的控件树中。可视状态是一种非常强大的能力因为它允许状态被客户端持续化并且它不需要cookies 或 服务器内存来存储该状态。许多 ASP.NET 服务器控件使用可视状态来持续化与页面元素交互期间所作的设置例如对数据进行分页时保存当前页显示页。 然而使用可视状态有许多不利之处首先不论是在请求的时候还是提供服务的时候它都增加造成整个页面的负担。当序列化或反序列化被返回服务器的可视状态数据时还产生一些附加的开销。最终可视状态会增加服务器的内存分配。 最著名的服务器控件要数 DataGrid 了使用可视状态有过之而无不及即便是在不需要使用的时候也是如此。ViewState 属性默认是启用的但如果你不需要它可以在页面控件级或页面级关闭它。在某个控件中只要将 EnableViewState 设置为 false或者在页面里使用如下全局设置% Page EnableViewStatefalse % 如果在某页面中不进行回发或每次请求页面时总是重新产生控件那么你应该在页面级禁用可视状态。结论 我已经向你提供了一些我认为有用的编写高性能 ASP.NET 应用程序的技巧。正如我在本文开头时所讲的那样这是一些很初级的指南而不是 ASP.NET 性能方面的最终定论。更多有关改进 ASP.NET 应用程序性能方面的信息请参见Improving ASP.NET Performance.只有通过自己的经验方能找到最佳途径来解决具体的性能问题。不管怎样在你解决问题的过程中这些技巧多少会对你有所裨益的。在软件开发过程中每一个应用都有其独特的一面没有什么东西是绝对的。——常见的性能神话 最常见的神话之一是 C# 代码比 Visual Basic 代码快。这样的说法是站不住脚的虽然在 Visual Basic 中存在一些 C# 没有的性能阻碍行为比如显式地声明类型。但是如果遵循良好的编程实践没有理由说明 Visual Basic 和 C# 代码不能以几乎同样的性能执行。简单说来相同的代码产生相同的结果。 另一个神话是后台代码比内联代码快这是绝对不成立的。性能与你的 ASP.NET 应用程序代码在哪没有什么关系无论是后台代码文件还是内联在 ASP.NET 页面。有时我更喜欢使用内联代码因为变更不会产生后台代码那样的更新成本。例如使用后台代码必须更新整个后台 DLL那时一个可能引起惊慌的主张。 第三个神话是组件比页面要快。这在经典的 ASP 中是存在的因为编译的 COM 服务器要比 VBScript 快得多。但是对于页面和组件都是类的 ASP.NET 来说则不然。不论你的代码是以后台代码形式内联在页面还是分离的组件所产生的性能差别不大。只是这种组织形式能更好地从逻辑上对功能进行分组在性能上没有差别。 我想澄清的最后一个神话是用 Web 服务来实现两个应用程序之间各个功能。Web 服务应该被用于连接异构系统或提供系统功能及行为的远程访问。不应该将它用于两个相同系统的内部连接。虽然使用起来很容易但有很多其它更好的可选方法。最糟的事情莫过于将 Web 服务用于相同服务器上 ASP 和 ASP.NET 应用程序之间的通讯我已经不厌其烦地对之进行了说明。 作者简介 Rob Howard 是 Telligent Systems 创建者擅长于高性能 Web 应用以及知识管理和协作系统。此前 Rob 受雇于微软协助设计了 ASP.NET 1.01.1 和 2.0。你可以通过 rhowardtelligentsystems.com 与 Rob 联系。转载于:https://www.cnblogs.com/dagon007/archive/2005/03/10/116013.html
